Nossa equipe está muito feliz em compartilhar a notícia de que foi lançado um sistema de monitoramento de código aberto. !
A versão 4.2 é a resposta à pergunta fundamental sobre a vida, o universo e o monitoramento em geral? Vamos descobrir!
Lembrando que o Zabbix é um sistema abrangente para monitorar o desempenho e a disponibilidade de servidores, equipamentos de engenharia e rede, aplicativos, bancos de dados, sistemas de virtualização, contêineres, serviços de TI e serviços web.
O Zabbix implementa todo o ciclo desde a coleta de dados, seu processamento e transformação, análise das informações obtidas, até o armazenamento desses dados, visualização e envio de alertas utilizando regras de escalonamento. O sistema também oferece flexíveis opções de extensão dos métodos de coleta de dados e alertas, assim como possibilidades de automação através da API. A interface web única proporciona gerenciamento centralizado das configurações de monitoramento e distribuição de permissões a diferentes grupos de usuários. O código do projeto é distribuído livremente sob licenciamento. .
O Zabbix 4.2 é uma nova versão não LTS com prazo de suporte oficial reduzido. Para usuários que buscam um ciclo de vida mais longo para produtos de software, recomendamos utilizar versões LTS, como 3.0 e 4.0.
Então, vamos falar sobre as novidades e principais melhorias da versão 4.2:
Mais plataformas oficiais
Além dos pacotes oficiais já existentes, também oferecemos novas compilações para:
- RaspberryPi, Mac OS/X, SUSE Enterprise Linux Server 12
- MSI para agente Windows
- Imagens Docker
Suporte embutido ao Prometheus para monitoramento de aplicativos
O Zabbix pode coletar dados de várias maneiras (push/pull) de diferentes fontes de dados. Isso inclui JMX, SNMP, WMI, HTTP/HTTPS, RestAPI, XML Soap, SSH, Telnet, agentes e scripts, entre outras fontes. E agora, conheça o suporte ao Prometheus!
Strictamente falando, a coleta de dados de exportadores do Prometheus já era possível anteriormente graças ao tipo de item de dados HTTP/HTTPS e expressões regulares.
No entanto, a nova versão permite trabalhar com o Prometheus de forma mais eficiente, graças ao suporte embutido à linguagem de consulta PromQL. O uso de métricas dependentes permite coletar e processar dados de maneira otimizada: uma única chamada para obter dados e, em seguida, organizá-los conforme as métricas necessárias.
Obtemos o valor de uma métrica específica
É importante notar que atualmente a detecção de baixo nível pode usar os dados coletados para criar métricas automaticamente. Nesse caso, o Zabbix transforma os dados recebidos em formato JSON, que é muito conveniente para trabalhar.
Encontramos métricas usando um filtro na linguagem de consultas PromQL
Atualmente, existem mais de de serviços e aplicativos de terceiros usando o Zabbix. O suporte ao Prometheus permitirá adicionar um conjunto inteiro de aplicativos que possuem exportadores Prometheus oficiais ou suportados pela comunidade. Isso inclui o monitoramento de serviços populares, contêineres e recursos em nuvem.
Monitoramento eficaz de alta frequência
Queremos detectar problemas o mais rápido possível? Claro, sem dúvidas! Na maioria das vezes, essa abordagem leva a necessidade de consultar dispositivos e coletar dados com muita frequência, o que resulta em uma carga maior sobre o sistema de monitoramento. Como evitar isso?
Implementamos um mecanismo de throttling nas regras de pré-processamento. O throttling, essencialmente, nos permite ignorar valores iguais.
Vamos supor que estamos monitorando o estado de um aplicativo crítico. A cada segundo, verificamos se nosso aplicativo está funcionando ou não. Nesse processo, o Zabbix recebe um fluxo contínuo de dados de 1 (funcionando) e 0 (não funcionando). Por exemplo: 1111111111110001111111111111…
Quando tudo está bem com nosso aplicativo, o Zabbix recebe um fluxo de apenas uns. Precisamos processá-los? Em geral, não, já que só nos interessa a mudança de estado do aplicativo, não queremos coletar e armazenar tantos dados. O throttling permite ignorar um valor se ele for idêntico ao anterior. Assim, teremos apenas dados sobre a mudança de estado, por exemplo, 01010101… Informações suficientes para detectar problemas!
Valores ignorados são simplesmente desconsiderados pelo Zabbix, não são registrados na história e não influenciam os gatilhos. Do ponto de vista do Zabbix, valores ignorados não existem.
Ignorando valores repetidos
Ótimo! Agora podemos consultar dispositivos com muita frequência, detectando problemas instantaneamente sem armazenar informações desnecessárias no banco de dados.
E quanto aos gráficos? Eles ficarão vazios devido à falta de dados! E como saber se o Zabbix está coletando dados, se a maioria desses dados será ignorada?
Nós também pensamos nisso! O Zabbix oferece outro tipo de throttling, o throttling com pontos de verificação (throttling with heartbeat).
Checamos uma vez por minuto se a métrica está ativa
Nesse caso, o Zabbix, apesar do fluxo de dados repetido, vai manter pelo menos um valor no intervalo de tempo especificado. Se os dados são coletados uma vez por segundo e o intervalo está definido em um minuto, o Zabbix transformará o fluxo de unidades por segundo em um fluxo por minuto. É fácil perceber que isso resulta em uma compressão de 60 vezes dos dados coletados.
Agora estamos seguros de que os dados estão sendo coletados, a função de trigger nodata() está funcionando e os gráficos estão em ordem!
Validação de dados coletados e tratamento de erros
Nenhum de nós quer coletar dados incorretos ou não confiáveis. Por exemplo, sabemos que um sensor de temperatura deve retornar dados entre 0°C e 100°C, e qualquer outro valor deve ser considerado como erro e/ou ignorado.
Agora isso é possível com as regras de validação de dados integradas no pré-processamento, que se verificam em conformidade ou não com expressões regulares, faixa de valores, JSONPath e XMLPath.
Agora podemos gerenciar a resposta a um erro. Se a temperatura estiver fora da faixa, podemos simplesmente ignorar esse valor, definir um valor padrão (por exemplo, 0°C) ou definir nossa própria mensagem de erro, como "Sensor danificado" ou "Substitua a bateria."
A temperatura deve estar entre 0 e 100, o restante ignoramos
Um bom exemplo de validação é a capacidade de verificar os dados de entrada em busca de mensagens de erro e atribuir esse erro a toda a métrica. Isso é uma funcionalidade muito útil ao obter dados de APIs externas.
Qualquer transformação de dados usando JavaScript
Se as regras de pré-processamento integradas não forem suficientes, agora oferecemos total liberdade com o uso de scripts arbitrários em JavaScript!
Apenas uma linha de código para converter graus Fahrenheit em graus Celsius
Isso abre possibilidades ilimitadas para o processamento de dados de entrada. A vantagem prática dessa funcionalidade é que agora não precisamos mais de scripts externos que usávamos para qualquer operação com dados. Agora, tudo isso pode ser feito com JavaScript.
Agora, transformação de dados, agregação, filtros, operações aritméticas e lógicas e muito mais são possíveis!
Extraindo informações úteis da saída do Apache mod_status!
Testando o pré-processamento
Agora não precisamos nos questionar sobre como funcionam nossos complexos scripts de pré-processamento. Temos uma verificação conveniente da eficácia do pré-processamento diretamente da interface!
Processando milhões de métricas por segundo!
Até o Zabbix 4.2, o pré-processamento era realizado exclusivamente pelo servidor Zabbix, o que limitava as possibilidades de uso de proxies para distribuir a carga.
Com a versão Zabbix 4.2, conseguimos uma escalabilidade de carga incrivelmente eficiente com o suporte ao pré-processamento no lado do proxy. Agora, isso é feito pelos proxies!
Em combinação com o throttling, essa abordagem permite realizar monitoramento em larga escala em alta frequência, realizando milhões de verificações por segundo, sem sobrecarregar o servidor central do Zabbix. Os proxies processam enormes volumes de dados, com apenas uma pequena parte chegando ao servidor Zabbix devido ao throttling, em um ou dois ordens de magnitude menor.
Detecção de baixo nível mais simples
Vale lembrar que a detecção de baixo nível (LLD) é um mecanismo muito poderoso para a detecção automática de qualquer tipo de recurso para monitoramento (sistemas de arquivos, processos, aplicativos, serviços, etc.) e criação automática de elementos de dados, gatilhos, nós de rede e outros objetos com base neles. Isso economiza um tempo incrível, simplifica a configuração e permite o uso de um único modelo para nós de rede com recursos de monitoramento variados.
A detecção de baixo nível exigia como entrada um JSON especialmente formatado. Isso não será mais necessário!
O Zabbix 4.2 permite que a detecção de nível inferior (LLD) utilize dados formatados em JSON de maneira arbitrária. Por que isso é importante? Isso permite que, sem o uso de scripts, se comunique, por exemplo, com APIs externas e use as informações obtidas para criar automaticamente nós de rede, elementos de dados e gatilhos.
Em combinação com o suporte a JavaScript, isso cria oportunidades fantásticas para criar modelos de trabalho com várias fontes de dados, como, por exemplo, APIs de nuvem, APIs de aplicativos, dados em formatos XML, CSV e outros.
Conectando JSON com informações de processos usando LLD
As possibilidades são verdadeiramente ilimitadas!
Suporte ao TimescaleDB
O que é o TimescaleDB? É um PostgreSQL comum mais um módulo de extensão da equipe do TimescaleDB. O TimescaleDB promete melhor desempenho devido a algoritmos e estruturas de dados mais eficientes.
Além disso, outra vantagem do TimescaleDB é a partição automática de tabelas históricas. TimescaleDB é velocidade e facilidade de manutenção! Embora eu deva observar que nossa equipe ainda não realizou uma comparação séria de desempenho com o PostgreSQL comum.
Atualmente, o TimescaleDB é um produto relativamente jovem e em rápido desenvolvimento. Use com cautela!
Gerenciamento fácil de tags
Se antes os tags podiam ser gerenciados apenas em nível de gatilhos, agora o gerenciamento de tags é muito mais flexível. O Zabbix suporta tags para modelos e nós de rede!
Todos os problemas detectados recebem tags não apenas do gatilho, mas também do nó de rede e dos modelos desse nó de rede.
Definindo tags para o nó de rede
Auto-registro mais flexível
O Zabbix 4.2 permite filtrar nós de rede por nome usando expressões regulares. Isso possibilita criar diferentes cenários de descoberta para diferentes grupos de nós de rede. Especialmente conveniente se tivermos regras de nomenclatura complexas para dispositivos.
Descoberta de rede mais flexível
Outra melhoria está relacionada à nomeação de nós de rede. Houve uma oportunidade de gerenciar nomes de dispositivos durante a descoberta de rede e obter o nome do dispositivo a partir do valor da métrica.
Essa é uma funcionalidade muito necessária, especialmente na descoberta de rede usando SNMP e o agente Zabbix.
Nome do nó de rede automaticamente atribuído como o nome visível
Verificação do funcionamento dos métodos de notificação
Agora, diretamente da interface da web, é possível enviar uma mensagem de teste para si mesmo e verificar se o método de notificação está funcionando. Essa funcionalidade é especialmente útil para testar scripts de integração do Zabbix com vários sistemas de notificação, sistemas de tarefas e outros programas externos e APIs.
Monitoramento remoto de componentes da infraestrutura Zabbix
Foi adicionada a capacidade de monitoramento remoto das métricas internas do servidor e proxy Zabbix (métricas de desempenho e operacionais dos componentes Zabbix).
Para que isso é necessário? A funcionalidade permite acompanhar métricas internas de servidores e proxies, possibilitando a detecção rápida e notificação de problemas, mesmo que os próprios componentes estejam sobrecarregados ou, por exemplo, o proxy tenha um grande volume de dados não enviados.
Suporte ao formato HTML para mensagens de email
Agora não estamos limitados ao texto simples e podemos criar mensagens de e-mail atraentes, graças ao suporte ao formato HTML. É hora de aprender HTML + CSS!
As mensagens são mais fáceis de serem compreendidas, mesmo com um uso mínimo de HTML
Acesso a sistemas externos a partir de mapas de rede
O suporte a um conjunto de novos macros em URLs personalizados para melhor integração de mapas com sistemas externos foi adicionado. Isso permite abrir, com um ou dois cliques no ícone do nó da rede, por exemplo, um ticket no sistema de tarefas.
Abrimos um ticket no Jira com um clique
A regra de detecção pode ser um elemento de dados dependente
Por que isso é necessário? Isso permite usar os dados da métrica principal tanto para detecção quanto para a coleta direta de dados. Por exemplo, ao coletar dados de um exportador Prometheus, o Zabbix fará uma solicitação HTTP e usará imediatamente as informações recebidas para todos os elementos de dados dependentes: valores das métricas e regras de detecção de baixo nível.
Nova maneira de visualizar problemas em mapas
Foi adicionado suporte a imagens GIF animadas nos mapas para uma visualização mais destacada dos problemas.
Dispositivos problemáticos tornaram-se mais visíveis
Extraímos dados dos cabeçalhos HTTP na monitorização da web
Na monitorização da web, foi adicionada a capacidade de selecionar dados do cabeçalho HTTP recebido.
Isto permite criar roteiros de monitoramento web em múltiplas etapas ou para APIs de terceiros, usando um token de autorização obtido em uma das etapas.
Extraímos o AuthID do cabeçalho HTTP
Zabbix Sender utiliza todos os endereços IP
Zabbix Sender agora envia dados a todos os endereços IP do parâmetro ServerActive no arquivo de configuração do agente.
Novo filtro conveniente na configuração de gatilhos
A página de configuração de gatilhos agora possui um filtro avançado para seleção rápida e conveniente de gatilhos com base em critérios especificados.
Selecionando gatilhos relacionados ao serviço K8S
Mostrando o horário exato
Aqui é simples, agora o Zabbix mostra o horário exato ao passar o mouse sobre o gráfico.
Outras novas funcionalidades
- Implementado um algoritmo mais previsível para alterar a ordem de posicionamento dos widgets no painel.
- Possibilidade de alteração em massa dos parâmetros dos protótipos de elementos de dados
- Suporte a IPv6 para checagens DNS: 'net.dns' e 'new.dns.record'
- Adicionado o parâmetro 'skip' para checagens 'vmware.eventlog'
- Erro de execução da etapa de pré-processamento inclui o número da etapa
Como atualizar?
Para a transição de versões anteriores, é necessário apenas instalar (servidores e proxies) e uma nova interface. O Zabbix realizará automaticamente o procedimento de atualização do banco de dados. Não será necessário instalar novos agentes.
Estamos realizando webinars gratuitos para aqueles que desejam saber mais sobre o Zabbix 4.2 e ter a oportunidade de fazer perguntas à equipe Zabbix.
Não esqueçamos do popular da comunidade Zabbix, onde você pode sempre obter consultoria e respostas a suas perguntas em russo de colegas mais experientes, e, se tiver sorte, até mesmo dos próprios desenvolvedores do Zabbix. Para iniciantes, recomendamos .
Links Úteis
—
—
—
Fonte: habr.com
