3 Monitoramento de arquivos de log

Visão geral

O Zabbix pode ser usado para monitoramento centralizado e análise de arquivos de log com/sem suporte a rotação de log.

As notificações podem ser usadas para alertar os usuários quando um arquivo de log contém determinadas strings ou padrões de string.

Para monitorar um arquivo de log, você deve ter:

• Zabbix agent em execução no host
• item de monitoramento de log configurado

Configuração

Verificar parâmetros do agent

Certifique-se de que, no arquivo de configuração do agent:

• O parâmetro Hostname corresponde ao nome do host no frontend.
• Os servers no parâmetro ServerActive estão especificados para o processamento de verificações ativas.

Configuração do item

Configure um item de monitoramento de logs.

Todos os campos de entrada obrigatórios são marcados com um asterisco vermelho.

Especificamente para itens de monitoramento de logs, você informa:

Notas importantes

• O server e o agent mantêm o registro do tamanho de um log monitorado e do horário da última modificação (para logrt) em dois contadores. Além disso:
  • O agent também usa internamente números de inode (em UNIX/GNU/Linux), índices de arquivo (no Microsoft Windows) e somas MD5 dos primeiros 512 bytes do arquivo de log para melhorar as decisões quando os arquivos de log são truncados e rotacionados.
  • Em sistemas UNIX/GNU/Linux, assume-se que os sistemas de arquivos onde os arquivos de log estão armazenados informam números de inode, que podem ser usados para rastrear arquivos.
  • No Microsoft Windows, o Zabbix agent determina o tipo de sistema de arquivos no qual os arquivos de log residem e usa:
    • Em sistemas de arquivos NTFS, índices de arquivo de 64 bits.
    • Em sistemas de arquivos ReFS (somente a partir do Microsoft Windows Server 2012), IDs de arquivo de 128 bits.
    • Em sistemas de arquivos em que os índices de arquivo mudam (por exemplo, FAT32, exFAT), é usado um algoritmo de fallback para adotar uma abordagem sensata em condições incertas quando a rotação do arquivo de log resulta em vários arquivos de log com o mesmo horário da última modificação.
  • Os números de inode, índices de arquivo e somas MD5 são coletados internamente pelo Zabbix agent. Eles não são transmitidos ao Zabbix server e são perdidos quando o Zabbix agent é interrompido.
  • Não modifique o horário da última modificação de um arquivo de log (por exemplo, com touch) e não substitua um arquivo de log monitorado copiando um arquivo de volta para seu nome original (isso cria um novo inode). Em qualquer um dos casos, o Zabbix pode tratar o arquivo como um arquivo diferente e relê-lo desde o início, o que pode gerar alertas duplicados.
  • Se houver vários arquivos de log correspondentes para o item logrt[] e o Zabbix agent estiver acompanhando o mais recente deles e esse arquivo de log mais recente for excluído, uma mensagem de aviso "there are no files matching "<regexp mask>" in "<directory>" é registrada. O Zabbix agent ignora arquivos de log com horário de modificação menor que o horário de modificação mais recente visto pelo agent para o item logrt[] que está sendo verificado.
• O agent começa a ler o arquivo de log a partir do ponto em que parou da vez anterior.
• O número de bytes já analisados (o contador de tamanho) e o horário da última modificação (o contador de tempo) são armazenados no banco de dados do Zabbix e são enviados ao agent para garantir que o agent comece a ler o arquivo de log a partir desse ponto nos casos em que o agent acabou de ser iniciado ou recebeu items que estavam anteriormente desabilitados ou não suportados. No entanto, se o agent recebeu um contador de tamanho diferente de zero do server, mas o item logrt[] ou logrt.count[] não consegue encontrar arquivos correspondentes, o contador de tamanho é redefinido para 0 para analisar desde o início se os arquivos aparecerem mais tarde.
• Sempre que o arquivo de log se torna menor do que o contador de tamanho do log conhecido pelo agent, o contador é redefinido para zero e o agent começa a ler o arquivo de log desde o início, levando em conta o contador de tempo.
• Se houver vários arquivos correspondentes com o mesmo horário da última modificação no diretório, então o agent tenta analisar corretamente todos os arquivos de log com o mesmo horário de modificação e evitar pular dados ou analisar os mesmos dados duas vezes, embora isso não possa ser garantido em todas as situações. O agent não assume nenhum esquema específico de rotação de arquivos de log nem determina um. Quando apresentados vários arquivos de log com o mesmo horário da última modificação, o agent os processará em ordem lexicograficamente decrescente. Assim, para alguns esquemas de rotação, os arquivos de log serão analisados e reportados em sua ordem original. Para outros esquemas de rotação, a ordem original dos arquivos de log não será respeitada, o que pode levar ao reporte de registros de arquivos de log correspondentes em ordem alterada (o problema não ocorre se os arquivos de log tiverem horários de última modificação diferentes).
• O Zabbix agent processa novos registros de um arquivo de log uma vez a cada Update interval segundos.
• O Zabbix agent não envia mais do que maxlines de um arquivo de log por segundo. O limite evita sobrecarga dos recursos de rede e CPU e substitui o valor padrão fornecido pelo parâmetro MaxLinesPerSecond no arquivo de configuração do agent.
• Para encontrar a string necessária, o Zabbix processará 10 vezes mais novas linhas do que o definido em MaxLinesPerSecond. Assim, por exemplo, se um item log[] ou logrt[] tiver Update interval de 1 segundo, por padrão o agent analisará no máximo 200 registros de arquivo de log e enviará no máximo 20 registros correspondentes ao Zabbix server em uma verificação. Ao aumentar MaxLinesPerSecond no arquivo de configuração do agent ou definir o parâmetro maxlines na chave do item, o limite pode ser aumentado para até 10000 registros de arquivo de log analisados e 1000 registros correspondentes enviados ao Zabbix server em uma verificação. Se o Update interval estiver definido como 2 segundos, os limites para uma verificação serão definidos 2 vezes mais altos do que com Update interval de 1 segundo.
• Além disso, os valores de log e log.count são sempre limitados a 50% do tamanho do buffer de envio do agent, mesmo que não haja valores não relacionados a log nele. Portanto, para que os valores de maxlines sejam enviados em uma única conexão (e não em várias conexões), o parâmetro BufferSize do agent deve ser pelo menos maxlines x 2. O Zabbix agent pode enviar dados durante a coleta de log e, assim, liberar o buffer, enquanto o Zabbix agent 2 interromperá a coleta de log até que os dados sejam enviados e o buffer seja liberado, o que é feito de forma assíncrona.
• Na ausência de items de log, todo o tamanho do buffer do agent é usado para valores não relacionados a log. Quando valores de log chegam, eles substituem os valores não relacionados a log mais antigos conforme necessário, até o limite designado de 50%.
• Para registros de arquivo de log maiores que 256kB, apenas os primeiros 256kB são comparados com a expressão regular e o restante do registro é ignorado. No entanto, se o Zabbix agent for interrompido enquanto estiver lidando com um registro longo, o estado interno do agent será perdido e o registro longo poderá ser analisado novamente e de forma diferente após o agent ser iniciado novamente.
• Observação especial para separadores de caminho "\": se file_format for "file\.log", então não deve haver um diretório "file", pois não é possível definir de forma inequívoca se "." está escapado ou se é o primeiro símbolo do nome do arquivo.
• Expressões regulares para logrt são suportadas apenas no nome do arquivo; a correspondência por expressão regular no diretório não é suportada.
• Em plataformas UNIX, um item logrt[] torna-se NOTSUPPORTED se um diretório onde se espera encontrar os arquivos de log não existir.
• No Microsoft Windows, se um diretório não existir, o item não se tornará NOTSUPPORTED (por exemplo, se o diretório estiver escrito incorretamente na chave do item).
• A ausência de arquivos de log para o item logrt[] não o torna NOTSUPPORTED. Erros de leitura de arquivos de log para o item logrt[] são registrados como avisos no arquivo de log do Zabbix agent, mas não tornam o item NOTSUPPORTED.
• O arquivo de log do Zabbix agent pode ser útil para descobrir por que um item log[] ou logrt[] se tornou NOTSUPPORTED. O Zabbix pode monitorar o arquivo de log do seu agent, exceto quando estiver em DebugLevel=4 ou DebugLevel=5.
• A busca por um ponto de interrogação usando uma expressão regular, por exemplo \?, pode resultar em falsos positivos se o arquivo de texto contiver símbolos NUL, pois eles são substituídos por "?" pelo Zabbix para continuar processando a linha até o caractere de nova linha.

Extraindo a parte correspondente da expressão regular

Às vezes, podemos querer extrair apenas o valor de interesse de um arquivo de destino, em vez de retornar a linha inteira quando uma correspondência de expressão regular é encontrada.

Os itens de log têm a capacidade de extrair os valores desejados das linhas correspondentes. Isso é feito por meio do parâmetro adicional output nos itens log e logrt.

O uso do parâmetro output permite indicar o "grupo de captura" da correspondência que pode ser de nosso interesse.

Então, por exemplo

log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

deve permitir retornar a contagem de entradas encontrada no conteúdo de:

Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result
buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement

Somente o número será retornado porque \1 se refere ao primeiro e único grupo de captura: ([0-9]+).

E, com a capacidade de extrair e retornar um número, o valor pode ser usado para definir triggers.

Usando o parâmetro maxdelay

O parâmetro maxdelay em itens de log permite ignorar algumas linhas mais antigas de arquivos de log para que as linhas mais recentes sejam analisadas dentro dos maxdelay segundos.

Por padrão, os itens de monitoramento de log seguem todas as novas linhas que aparecem nos arquivos de log. No entanto, há aplicações que, em algumas situações, começam a gravar um número enorme de mensagens em seus arquivos de log. Por exemplo, se um banco de dados ou um server DNS estiver indisponível, essas aplicações inundam os arquivos de log com milhares de mensagens de erro quase idênticas até que a operação normal seja restaurada. Por padrão, todas essas mensagens serão analisadas diligentemente e as linhas correspondentes serão enviadas ao server conforme configurado nos itens log e logrt.

A proteção integrada contra sobrecarga consiste em um parâmetro configurável maxlines (protege o server contra muitas linhas de log correspondentes recebidas) e um limite de 10*'maxlines' (protege a CPU e a E/S do host contra sobrecarga pelo agent em uma única verificação). Ainda assim, há 2 problemas com a proteção integrada. Primeiro, um grande número de mensagens potencialmente pouco informativas é reportado ao server e consome espaço no banco de dados. Segundo, devido ao número limitado de linhas analisadas por segundo, o agent pode ficar atrasado em relação aos registros de log mais recentes por horas. Muito provavelmente, você preferirá ser informado mais cedo sobre a situação atual nos arquivos de log em vez de vasculhar registros antigos por horas.

A solução para ambos os problemas é usar o parâmetro maxdelay. Se maxdelay > 0 for especificado, durante cada verificação o número de bytes processados, o número de bytes restantes e o tempo de processamento são medidos. A partir desses números, o agent calcula um atraso estimado - quantos segundos levaria para analisar todos os registros restantes em um arquivo de log.

Se o atraso não exceder maxdelay, então o agent prossegue com a análise do arquivo de log normalmente.

Se o atraso for maior que maxdelay, então o agent ignora um trecho de um arquivo de log "saltando" sobre ele para uma nova posição estimada, de modo que as linhas restantes possam ser analisadas dentro de maxdelay segundos.

Observe que o agent nem sequer lê as linhas ignoradas para o buffer, mas calcula uma posição aproximada para saltar no arquivo.

O fato de pular linhas do arquivo de log é registrado no arquivo de log do agent assim:

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
(from byte 75653115 to byte 76332973) to meet maxdelay

O número "to byte" é aproximado porque, após o "jump", o agent ajusta a posição no arquivo para o início de uma linha de log, que pode estar mais adiante no arquivo ou antes.

Dependendo de como a velocidade de crescimento se compara com a velocidade de análise do arquivo de log, você pode não ver "jumps", ver "jumps" raros ou frequentes, "jumps" grandes ou pequenos, ou até mesmo um "jump" pequeno em cada verificação. Flutuações na carga do sistema e na latência da rede também afetam o cálculo do atraso e, portanto, o "jump" para frente para acompanhar o parâmetro maxdelay.

Não é recomendável definir maxdelay < update interval (isso pode resultar em "jumps" pequenos e frequentes).

Notas sobre o tratamento da rotação de arquivos de log com 'copytruncate'

logrt com a opção copytruncate pressupõe que arquivos de log diferentes tenham registros diferentes (pelo menos seus timestamps sejam diferentes), portanto os somatórios MD5 dos blocos iniciais (até os primeiros 512 bytes) serão diferentes. Dois arquivos com os mesmos somatórios MD5 dos blocos iniciais significam que um deles é o original e o outro é uma cópia.

logrt com a opção copytruncate faz um esforço para processar corretamente cópias de arquivos de log sem relatar duplicatas. No entanto, situações como gerar várias cópias do arquivo de log com o mesmo timestamp, rotação de arquivo de log com mais frequência do que o intervalo de atualização do item logrt[], ou reinicializações frequentes do agent não são recomendadas. O agent tenta lidar com todas essas situações de forma razoável, mas bons resultados não podem ser garantidos em todas as circunstâncias.

Notas sobre arquivos persistentes para itens de log*[]

Finalidade dos arquivos persistentes

Quando o Zabbix agent é iniciado, ele recebe uma lista de verificações ativas do Zabbix server ou proxy. Para métricas log*[], ele recebe o tamanho do log processado e o horário de modificação para determinar onde iniciar o monitoramento do arquivo de log. Dependendo do tamanho real do arquivo de log e do horário de modificação informados pelo sistema de arquivos, o agent decide se deve continuar o monitoramento do arquivo de log a partir do tamanho do log processado ou reanalisar o arquivo de log desde o início.

Um agent em execução mantém um conjunto maior de atributos para rastrear todos os arquivos de log monitorados entre verificações. Esse estado em memória é perdido quando o agent é interrompido.

O novo parâmetro opcional persistent_dir especifica um diretório para armazenar esse estado do item log[], log.count[], logrt[] ou logrt.count[] em um arquivo. O estado do item log é restaurado a partir do arquivo persistente após a reinicialização do Zabbix agent.

O principal caso de uso é o monitoramento de um arquivo de log localizado em um sistema de arquivos espelhado. Até certo momento, o arquivo de log é gravado em ambos os espelhos. Depois, os espelhos são separados. Na cópia ativa, o arquivo de log continua crescendo, recebendo novos registros. O Zabbix agent o analisa e envia o tamanho do log processado e o horário de modificação para o server. Na cópia passiva, o arquivo de log permanece inalterado, bem atrás da cópia ativa. Mais tarde, o sistema operacional e o Zabbix agent são reinicializados a partir da cópia passiva. O tamanho do log processado e o horário de modificação que o Zabbix agent recebe do server podem não ser válidos para a situação na cópia passiva. Para continuar o monitoramento do arquivo de log a partir do ponto em que o agent parou no momento da separação do espelho do sistema de arquivos, o agent restaura seu estado a partir do arquivo persistente.

Operação do agent com arquivo persistente

Na inicialização, o agent do Zabbix não sabe nada sobre arquivos persistentes. Somente após receber uma lista de verificações ativas do Zabbix server (proxy), o agent vê que alguns itens de log devem ser respaldados por arquivos persistentes em diretórios especificados.

Durante a operação do agent, os arquivos persistentes são abertos para gravação (com fopen(filename, "w")) e sobrescritos com os dados mais recentes. A chance de perder dados do arquivo persistente se a sobrescrita e a divisão do espelhamento do sistema de arquivos acontecerem ao mesmo tempo é muito pequena, sem tratamento especial para isso. A gravação no arquivo persistente NÃO é seguida por sincronização forçada com a mídia de armazenamento (fsync() não é chamado).

A sobrescrita com os dados mais recentes é feita após o envio bem-sucedido do registro correspondente do arquivo de log ou dos metadados (tamanho do log processado e tempo de modificação) ao Zabbix server. Isso pode acontecer com a mesma frequência de cada verificação do item, se o arquivo de log continuar mudando.

Nenhuma ação especial durante o encerramento do agent.

Após receber uma lista de verificações ativas, o agent marca arquivos persistentes obsoletos para remoção. Um arquivo persistente se torna obsoleto se:

1. O item de log correspondente não estiver mais sendo monitorado.
2. Um item de log for reconfigurado com um local persistent_dir diferente do anterior.

A remoção é feita com atraso de 24 horas porque os arquivos de log no estado NOTSUPPORTED não são incluídos na lista de verificações ativas, mas eles podem se tornar SUPPORTED posteriormente e seus arquivos persistentes serão úteis.

Se o agent for interrompido antes de 24 horas expirarem, então os arquivos obsoletos não serão excluídos, pois o Zabbix agent não estará mais recebendo informações sobre sua localização do Zabbix server.

Nomeação e localização de arquivos persistentes

O Zabbix agent distingue verificações ativas pelas suas chaves. Por exemplo, logrt[/home/zabbix/test.log] e logrt[/home/zabbix/test.log,] são items diferentes. Modificar o item logrt[/home/zabbix/test.log,,,10] no frontend para logrt[/home/zabbix/test.log,,,20] resultará na exclusão do item logrt[/home/zabbix/test.log,,,10] da lista de verificações ativas do agent e na criação do item logrt[/home/zabbix/test.log,,,20] (alguns atributos são переносados na modificação no frontend/server, mas não no agent).

O nome do arquivo é composto pela soma MD5 da chave do item com o comprimento da chave do item anexado, para reduzir a possibilidade de colisões. Por exemplo, o estado do item logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] será mantido no arquivo persistente c963ade4008054813bbc0a650bb8e09266.

Vários items de log podem usar o mesmo valor de persistent_dir.

persistent_dir é especificado levando em conta layouts específicos do sistema de arquivos, pontos de montagem e opções de montagem, além da configuração de espelhamento de armazenamento - o arquivo persistente deve estar no mesmo sistema de arquivos espelhado que o arquivo de log monitorado.

Se o diretório persistent_dir não puder ser criado ou não existir, ou se as permissões de acesso para o Zabbix agent não permitirem criar/gravar/ler/excluir arquivos, o item de log se torna NOTSUPPORTED.

Se os direitos de acesso aos arquivos de armazenamento persistente forem removidos durante a operação do agent ou ocorrerem outros erros (por exemplo, disco cheio), os erros serão registrados no arquivo de log do agent, mas o item de log não se tornará NOTSUPPORTED.

Carga em I/O

O arquivo persistente do item é atualizado após o envio bem-sucedido de cada lote de dados (contendo os dados do item) para o server. Por exemplo, o BufferSize padrão é 100. Se um item de log encontrou 70 registros correspondentes, então os primeiros 50 registros serão enviados em um lote, o arquivo persistente será atualizado, depois os 20 registros restantes serão enviados (talvez com algum atraso, quando mais dados forem acumulados) no 2º lote, e o arquivo persistente será atualizado novamente.

Ações se a comunicação falhar entre agent e server

Cada linha correspondente de um item log[] e logrt[] e o resultado de cada verificação de item log.count[] e logrt.count[] requer um slot livre na área designada de 50% no buffer de envio do agent. Os elementos do buffer são enviados regularmente para o server (ou proxy) e os slots do buffer ficam livres novamente.

Enquanto houver slots livres na área designada de log no buffer de envio do agent e a comunicação falhar entre agent e server (ou proxy), os resultados do monitoramento de log são acumulados no buffer de envio. Isso ajuda a atenuar falhas de comunicação de curta duração.

Durante falhas de comunicação mais longas, todos os slots de log ficam ocupados e as seguintes ações são tomadas:

• As verificações dos itens log[] e logrt[] são interrompidas. Quando a comunicação for restaurada e houver slots livres disponíveis no buffer, as verificações serão retomadas a partir da posição anterior. Nenhuma linha correspondente é perdida; elas apenas serão reportadas mais tarde.
• As verificações log.count[] e logrt.count[] são interrompidas se maxdelay = 0 (padrão). O comportamento é semelhante ao dos itens log[] e logrt[] descritos acima. Observe que isso pode afetar os resultados de log.count[] e logrt.count[]: por exemplo, uma verificação conta 100 linhas correspondentes em um arquivo de log, mas como não há slots livres no buffer, a verificação é interrompida. Quando a comunicação for restaurada, o agent conta as mesmas 100 linhas correspondentes e também 70 novas linhas correspondentes. Agora o agent envia count = 170 como se elas tivessem sido encontradas em uma única verificação.
• As verificações log.count[] e logrt.count[] com maxdelay > 0: se não houve "jump" durante a verificação, o comportamento é semelhante ao descrito acima. Se ocorreu um "jump" sobre linhas do arquivo de log, então a posição após o "jump" é mantida e o resultado contado é descartado. Assim, o agent tenta acompanhar um arquivo de log em crescimento mesmo em caso de falha de comunicação.

Tratamento de erros de compilação e de execução de expressões regulares

Se uma expressão regular usada em um item log[], logrt[], log.count[] ou logrt.count[] não puder ser compilada pela biblioteca PCRE ou PCRE2, o item entra no estado NOTSUPPORTED com uma mensagem de erro. Para continuar monitorando o item de log, a expressão regular deve ser corrigida.

Se a expressão regular for compilada com sucesso, mas falhar em tempo de execução (em alguns ou em todos os registros de log), então o item de log permanece suportado e o monitoramento continua. O erro de tempo de execução é registrado no arquivo de log do Zabbix agent (sem o registro do arquivo de log).

A taxa de registro é limitada a um erro de tempo de execução por verificação para permitir que o Zabbix agent monitore seu próprio arquivo de log. Por exemplo, se 10 registros forem analisados e 3 registros falharem com um erro de tempo de execução de regexp, um registro é produzido no log do agent.

Exceção: se MaxLinesPerSecond=1 e o intervalo de atualização=1 (apenas 1 registro é permitido para análise por verificação), então os erros de tempo de execução de regexp não são registrados.

zabbix_agentd registra a chave do item em caso de erro de tempo de execução, e o zabbix_agent2 registra o ID do item para ajudar a identificar qual item de log apresenta erros de tempo de execução. Recomenda-se redesenhar a expressão regular em caso de erros de tempo de execução.