De quem são os logs do OpenVPN: do daemon, do rsyslog ou do logrotate?

A rotação de logs quebra de forma previsível: três componentes acham cada um que é dono do arquivo, e o resultado é um log rodado que continua crescendo enquanto o novo fica vazio. O daemon mantém um descritor, o logrotate renomeia o caminho e o rsyslog escreve num lugar completamente diferente. Escolha um escritor e um rotador antes de acrescentar outra regra à pilha. A lista de verificação abaixo segue essa ordem porque cada passo posterior depende dela.

Decida quem escreve o arquivo

Dois desenhos são legítimos. No primeiro, o processo VPN escreve ele mesmo um arquivo através da sua própria opção log ou log-append. No segundo, envia os registros para o logger do sistema e o rsyslog ou o journald decide onde eles caem.

São alternativas, não camadas. Um host que ativa os dois acaba com dois arquivos que discordam, e o que você está lendo costuma ser o desatualizado. Escolha o caminho de propósito e depois remova o outro escritor.

Leia a configuração efetiva do serviço antes de mudar qualquer coisa, incluindo os drop-ins que podem substituir o arquivo de unit. Uma diretiva presente no perfil que você editou não prova que seja a que o processo em execução carregou. Compare a unit com os argumentos do processo e depois com os arquivos que ele realmente abriu.

Nomeie o daemon para que o filtro seja estreito

No caminho do syslog, dê ao daemon uma identidade distinta e filtre por ela. Uma regra que casa com o nome de programa desta instância VPN mantém os registros dela fora de um arquivo compartilhado cuja política de retenção pertence a outra coisa.

Regras estreitas também tornam a próxima pergunta respondível: qual serviço produziu esta linha? Um filtro que casa com tudo o que contém a palavra VPN vai recolher de bom grado o tráfego de um segundo túnel e borrar ambos. Case com o identificador exato que a unit passa ao logger.

Feche a regra depois da ação para que os registros não caiam também no destino padrão. Linhas duplicadas em dois arquivos parecem um defeito de logging e na verdade são uma parada ausente. Essa única omissão também duplica o custo de disco da política de retenção.

Rode sem perder o descritor

Quando o daemon escreve o arquivo, o logrotate renomeia o caminho, mas o processo mantém o seu descritor aberto. Novos registros continuam a entrar no arquivo renomeado até que algo force o processo a reabrir o caminho original; por isso uma rotação pode parecer funcionar enquanto o arquivo novo continua vazio.

A solução é uma ação postrotate que dispare o comportamento documentado de recarga ou reinício do serviço. Enviar um sinal ao logger é uma ação completamente diferente e não faz nada por um daemon que mantém o próprio arquivo.

Onde a reabertura é impossível, o copytruncate é o recurso: copie o arquivo e depois trunque-o no lugar. Ele mantém o descritor válido ao custo de perder tudo o que for escrito entre a cópia e o truncamento, portanto é uma troca e não uma solução. Sob carga, essa lacuna pode engolir exatamente a falha que você tenta capturar.

Escolha uma das duas por arquivo e registre a escolha, porque misturá-las no mesmo caminho produz lacunas muito difíceis de atribuir depois. Um leitor que encontre os dois padrões num mesmo diretório não consegue dizer qual é o autoritativo.

Defina a retenção a partir da janela do incidente

Retenção, compressão e tamanho máximo devem decorrer de até onde você realmente investiga. Uma janela de sete dias com compressão e um teto de tamanho é um ponto de partida razoável para muitas implantações; um número copiado de um tutorial não é.

Mantenha a política num único lugar. Se o logrotate roda o arquivo e o rsyslog também o roda, a segunda rotação vence e o esquema de nomes da primeira sobrevive como desordem. Escolha o dono, desative a outra rotação e anote essa decisão ao lado da política.

A documentação do rsyslog cobre o modelo de roteamento e de ações, enquanto a documentação do serviço OpenVPN continua sendo a autoridade para as opções de logging do próprio daemon. Nenhuma das duas decide a sua política de retenção por você.

Teste uma rotação e um evento novo

Force uma única rotação e depois gere um evento novo, como uma autenticação falhada. Confirme que o registro novo aparece no arquivo novo e que o arquivo antigo parou de crescer.

Verifique também as permissões do arquivo novo, porque uma rotação que o recria com outro dono quebra o escritor na escrita seguinte e produz uma lacuna que parece um crash. Compare o dono e o modo com a conta do serviço antes de sair. Em seguida confirme que o arquivo comprimido é legível, pois um arquivo que ninguém consegue abrir não é retenção. Uma leitura rápida do registro mais recente no arquivo antigo prova tanto a compressão quanto as permissões.

Termine registrando o dono de cada passo: qual componente escreve, qual roda e onde vive a política de retenção. É esse registro que transforma o próximo incidente de logging numa verificação de cinco minutos em vez de uma tarde adivinhando qual camada perdeu a linha.