Descomplicando Macros do Zabbix e conhecendo Macros de Contexto
Usuários avançados podem já conhecer e utilizar, porem vejo muitos que estão começando no mundo Zabbix, desconhecendo ou podem nem ter ouvido falar sobre Macros. Talvez por falta de interesse, sem prazo para estudo ou desconhecimento, acabam não usando este recurso bastante importante para automatização e gerenciamento do monitoramento. Sendo assim, resolvi escrever este pequeno artigo focando apenas em Macros, passando o básico e um pouco avançado de como podemos usufruir no nosso ambiente.
Começarei dando um exemplo, digamos que você monitora partições/discos dos seus servidores utilizando elementos padrões LLD (descoberta de baixo nível). Normalmente no nosso template criamos nossas triggers para disparar quando um limite específico é atingido, no Zabbix isso é conhecido como thresholds. É de costume utilizar a seguinte estrutura para construir a sintaxe de trigger nesse exemplo.
{Nome_Template:vfs.fs.size[{#FSNAME},chave].last(0)}<VALOR
{Nome_Template:vfs.fs.size[{#FSNAME},pfree].last(0)}<20 (Menor que 20% é ativado)Porem você acaba utilizando este template para todo o seu ambiente de hosts Linux. Muitos desses hosts podem possuir tamanhos diferentes nos seus sistemas de arquivos e a análise de thresholds é acaba sendo diferente entre eles. Desta forma não podemos aplicar o mesmo valor de 20% para todos eles. Para casos como este que podemos utilizar as macros.
De forma geral, macros são variáveis que indicam um valor especifico dependendo do contexto ou nível aplicado.
MACROS
Antes de tudo, precisamos entender o conceito básico de macro, atualmente podemos ter 3 tipos de macros, são elas.
Macros Default: {HOST.NAME} — Macros já inclusas no Zabbix (Link)
Macros de LLD -> {#FSNAME} — Todas macros de LLD utilizam #
Macro de usuário {$CUSTOM} — Todas macros de usuários possuem $Cuidado com a sintaxe, todo o conteúdo é maiúsculo e fica dentro de colchetes, se colocar de outra maneira, poderá dar “Item not supported” ou “Unknown Trigger”.
Digamos que queira definir os 20% daquela primeira trigger do nosso artigo, logo podemos utilizar como exemplo a macro {$MINDISCO} = 20. Mas poderá surgir necessidade de definir outros limites seja para o template ou um host. Neste caso, as macros de usuário são definidas em 3 níveis:
HOST {$MACRO} = (Configuração > Hosts > Nome do Host > Macros)
TEMPLATE {$MACRO} = (Configuração > Templates > Nome do Template > Macros)
GLOBAL {$MACRO} = (Administração > Geral > Macros)Quando utilizamos estes níveis de macros, precisamos entender como o Zabbix interpreta os valores. Quando uma macro é definida a nível de host, ela irá prevalecer sobre as demais macros, já a definida a nível no template, prevalece a global.
Um exemplo prático de como aplicar esse conceito.
Digamos que queria criar um limite para uma trigger de um template que verifica a latência da rede de um determinado host. É comum para estes casos criar triggers com a seguinte sintaxe:
{Template_exemplo:icmppingsec.avg(5m)}>0.15Porem para um host em especifico, precisaremos utilizar outro limite na trigger. Então podemos criar uma trigger com esta macro. Iremos chamar de LATENCIAREDE.
{Template_exemplo:icmppingsec.avg(5m)}>{$LATENCIAREDE}
Cadastre neste momento a macro de nível global.
E por fim, no host onde possui este template associado, incluí esta macro e troque para o valor que desejar. Obs: Repare no lado direito, que é informado que a macro alterada é do tipo global.
Desta forma a trigger deste host irá considerar o valor de 0.25 ao invés de 0.15 definido no nível de global. Já que o nível de host tem uma prioridade mais alta sobre as demais.
Podemos também aplicar macros em outros casos interessantes. Como por exemplo:
· Há alguns tipos de checagens que possam ser necessários passar Login e Senha, como Telnet, SSH, VMWare, JMX entre outros, nesses casos, podemos usar macros de níveis globais. Onde somente os usuários com permissões de Zabbix Super Admin terão acesso, usuários com permissões de Zabbix Admin e Zabbix User só terão permissões para visualizar as macros, sejam de níveis de template ou de host. Este recurso é muito útil em ambientes grandes e complexos, e que acaba tornando um ótimo aliado para segurança.
· Outra forma de aplicarmos as macros, pode ser para definir intervalos customizáveis de coletas para diferentes itens, desta forma será possível centralizar em um único local toda a configuração de horário de trabalho. Bastante útil quando se trabalha com contratos com diferentes horários de coletas.
Agora que já sabemos o básico de macros e como aplica-las em nossos templates, podemos subir um pouco mais a complexidade e também trabalhar com as macros de contexto.
MACROS DE CONTEXTO
As macros de contexto só são utilizadas em regras de LLD. Digamos que tenha uma regra de descoberta para sistema de arquivo, onde descobre todas as partições de disco de um host, seguindo a lógica do nosso primeiro exemplo, podemos ter diferentes casos em um mesmo ambientes, onde um host X pode ter necessidade de ter um limite de 5% e já um host Y ter 10% de espaço livre para uma partição em especial. Para não precisar criar diferentes templates e modificar somente este protótipo de trigger, podemos trabalhar com os níveis de macros e as macros de contexto.
Você pode criar uma trigger para alarmar quando todas as partições estiverem menor que 10%, mas somente a partição /boot, usará um limite de 90%, ao invés dos 10%. Como estaremos usando um protótipo de trigger em um LLD, não teríamos como criar uma para cada partição, já que será utilizado a mesma sintaxe de trigger para todas as partições descobertas.
Crie uma macro de nível global.
{$MINHD} = 20 (mínimo de 20%)
E posteriormente crie uma regra padrão de descoberta de sistema de arquivo, com a chave vfs.fs.size, um protótipo de item com a chave vfs.fs.size[{#FSNAME},pfree], onde o tipo de item pfree, é a porcentagem livre no disco. Ao invés de utilizarmos na trigger o limite de 20, ou somente a macro {$MINHD}, podemos customizar utilizando o FSNAME como parte do gatilho. Desta forma o {$MINHD: ”{# FSNAME}”} será interpretado como algo do tipo {$MINHD: /boot”}. Repare que podemos usar a mesma sintaxe no Nome da trigger também.
Crie um host e vincule este template a este host, no cadastro do host, inclue a seguinte macro.
{$MINHD:”/boot”} = 90 (mínimo de 90% para unidade boot)
Sendo assim, todas as partições descobertas, entraram na regra dos 20%, mas somente a partição /boot do host CLI-LINUX-04, ficará com a trigger de 90%. A macro {$MINHD} continuará sendo herdada do nível global, porem para este host, será considerado a macro de nível host configurada {$MINHD:”/boot”}.
Para podermos verificar se a trigger foi configurada corretamente, podemos forçar a checagem da regra de descoberta (somente disponível nas versões 4.x +, no host e na regra de descoberta botão “check now”).
Após a trigger ser reconhecida pelo host, podemos verificar se ela ativará conforme o limite definido na tela de Problems.
Somente em Problems que podemos verificar este valor, na guia de triggers do host e no template somente será apresentado a trigger com a macro.
Esse recuso não é um recurso lançado recentemente, foi introduzido na versão 3.x se não me engano. Porem vejo na comunicada que é muito pouco utilizado ou até desconhecidos por muitos que costumam apenas reaproveitar templates.
A partir deste momento podemos customizar bastante nossos templates, poupar tempo, facilitar toda a administração e configuração de todo nosso ambiente. Como não é um assunto tão comentado, resolvi criar este artigo. Lembre-se de testar bastante e verificar mais detalhes sobre o assunto na documentação oficial.
Bons testes.
Referencias:
