Para garantir que os templates aplicados no seu ambiente de monitoramento seguem boas práticas, é importante entender as recomendações para cada um dos itens. Esse documento ajudará a revisar os itens indicados pelo Validador de Templates e otimizá-los.
As boas práticas consistem na observância das seguintes regras principais:
1. Nomenclatura dos templates: a estrutura dos nomes de templates deve consistir no seguinte modelo:
Template <Tecnologia> <versão/modelo> , onde:
<Tecnologia> trata-se do equipamento / solução ou processo, cujos itens serão monitorados;
<versão/modelo> se aplicável, definindo a versão do ambiente / equipamento que está sendo monitorado nesse ambiente.
2. Tempos de coleta: configurar, por padrão, nos tempos de coletas de itens, pelo menos 5 min. Sabe-se que os tempos de coleta necessários são variados, no entanto, deve-se considerar um entendimento macro a ser considerado na criação dos itens, a saber:
– Itens que não se alteram sem intervenção: podem ter o tempo de coleta setado para 7 dias. Exemplos de itens de tal natureza: hostname, tamanho total do disco, total de memória, etc;
– Itens cuja alteração é crítica e sensível ao negócio: devem resguardar tempos de coleta mais curtos – idealmente, coletar a cada 5 minutos. Exemplo: %uso de disco, %uso CPU, %uso memória, conectividade, etc. Os itens, cuja necessidade de coleta é menor do que 5 min, devem ter o tempo de coleta menor configurado nos hosts em que isso for aplicável, mantendo o template como padrão.
Utilizar intervalo de coleta mínimo de 5 minutos. Obs.: fazer essas alterações sempre usando macros.
Somente reduzir o intervalo de coleta para abaixo de 5m se houver extrema necessidade.
3. Histórico de item:
Utilizar histórico do item padrão 7 dias e estatísticas 365 dias (sempre usando macros):
4. Uso massivo de throttling na criação dos monitoramentos, para evitar armazenamento desnecessário de métricas:
Porquê throttling no preprocessing do Zabbix é um ponto chave para monitoramento de alta frequência Documentação sobre Thorttling
Porquê throttling no preprocessing do Zabbix é um ponto chave para monitoramento de alta frequência
Documentação sobre Thorttling
5. Uso de macros (de contexto e LLD): na construção de templates, é imprescindível que sejam usadas macros nos itens e triggers, de forma a possibilitar que o template seja genérico e reaproveitado em quaisquer ambientes. Todas as customizações específicas de clientes devem ser feitas a nível de macro e/ou host. O template deve ser resguardado como padrão genérico;
Todos os temas que tiverem valores fixos setados, e que possam ser alterados em algum momento, devem ser substituídos por macro – como nos seguintes pontos principais do template:
– Key / formula;
– Update interval:
– History storage period
– Trend storage period
Referência: Macros. Macros context. Macros for Time Periods.
Referência:
Macros.
Macros context.
Macros for Time Periods.
6.
7. Preenchimento dos campos “Descrição” para Templates, Itens e Macros: o preenchimento do campo de Descrição dos Templates, Itens e Macros, permite que possam ser geradas, de forma automatizada, as documentações explicativas das suas funcionalidades, regras e aplicações. Idealmente, a explicação da descrição deve fornecer ao usuário da solução uma forma fácil de entendimento para alteração, inclusão e otimização das configurações aplicadas, de forma autônoma.
Formato da descrição do template: deve seguir um padrão, para que as documentações sejam geradas de acordo com as informações desse campo, conforme exemplo:
Formato da descrição do item: deve ser autoexplicativa e refletir o objetivo e uso dessa métrica – com as considerações relevantes para que o usuário da ferramenta possa aplica-la de forma autônoma, conforme exemplo:
Formato da descrição das macros: idealmente deve recomendar como usa-la e forma de separação (quando aceitar múltiplos valores), para que os usuários possam incrementar / alterar de forma dinâmica.
8. Funções usadas nas triggers: evitar usar na função last() como primeira alternativa. Compreender o comportamento da métrica, para então definir a função (ex.: min, max, avg, count, etc).
Material de consulta e referência.
Exemplo: Função last(): para os casos mais sensíveis em que a coleta de cada item importa, deve-se ter, obrigatoriamente, critérios de validação do problema (ex.: últimas 3 coletas com problema, gerar alarme), com critérios de recover setados, para esses casos, igualmente.
9. Evitar uso de scripts: na nova versão do Zabbix, é possível fazer a coleta de dados da forma mais nativa possível, que é o caminho mais fácil, evitando a criação de scripts para busca e coleta de dados. Caso seja necessária a criação de scripts, deve-se colocar no repositório com o README, descrendo um overview, como aplica-lo, o que ele faz, e o que precisa para que funcione, bem como os itens que gera e para que servem as coletas;
10. Monitoramento de Banco de Dados: A coleta de itens de banco de dados deve ser feita através de UNIXODBC. No caso de coleta de dados de banco, onde haja necessidade de tratamento de itens provenientes de queries, a recomendação é executar uma query única mais ampla (em termos de amplitude de informações), com item ODBC discovery (e geração de item prototype, fazendo REGEXP para gerar os itens)
Referências: UNIXODBC. DB.ODBC.Discovery. REGEXP e REGEX 101. JSON e JSON.
Referências:
UNIXODBC.
DB.ODBC.Discovery.
REGEXP e REGEX 101.
JSON e JSON.
11. Regras para autodescoberta de ativos: Requisitos para que o monitoramento funcione conforme boas práticas:
12. Range de IPs: fornecimento do segmento de IPs (range) que detêm os equipamentos a serem monitorados, para que sejam automaticamente detectados. Caso não haja segmentação de redes, fornecer a lista de IPs dos equipamentos a serem monitorados, conforme padrão de CSV:
13. Descoberta de ativos de rede: colocar filtros sempre, para que seja possível o monitoramento somente das interfaces que estiverem sendo, de fato, utilizadas pelos clientes, considerando as duas regras principais:
– Interfaces com Admin Status UP: não deixar somente esse critério, pois há situações em que os clientes deixam todas as interfaces UP. Nesse caso, usar também a regra abaixo;
– Filtro por TAG / Description da interface, considerando somente as que estiverem de fato sendo utilizadas;
14. Descobertas de serviços: incluir somente os serviços que estiverem com inicialização automática nos servidores;
15. Monitoramento de Queries / APIs: em caso de monitoramento de dados provenientes de queries e/ou chamadas de API, ter em mente alguns aspectos importantes antes de começar:
– Entender quais são os dados que serão coletados – é importante ter em mente quais são os indicadores que precisarão ser guardados no Zabbix;
– Revisar qual / quais chamadas trazem já, em uma única chamada, boa parte desses dados de uma vez só – para tentar diminuir o número de vezes em que se faz chamada ao Banco ou API (não martelando nesses ambientes);
– Após a visão da chamada macro, aplicar no Zabbix os filtros e pre-processamentos necessários para o estabelecimento dos itens – através da criação de itens dependentes daquele já criado (para que não seja feita mais de uma consulta ao banco ou query), utilizando jsonpath/expressões regulares (vide item 7 desse documento);
Essas foram as boas práticas na criação de templates Zabbix, para saber mais sobre Repositório de Templates, navegue por essa funcionalidade na faq.
Powered by BetterDocs
