Como funciona a descoberta de baixo nível (LLD) no Zabbix?

Como funciona a descoberta de baixo nível (LLD) no Zabbix?

Descoberta de baixo nível, ou Low-level discovery (LLD), é um processo que automatiza o registro e monitoramento de recursos pelo Zabbix, ele pode fazer a identificação de métricas em sistemas de arquivos e interfaces de rede que são exemplos de LLD nativos dos agentes Zabbix.

A descoberta de baixo nível pode ser configurada em um único host ou a partir de um template. Alguns dos templates padrões do Zabbix já vêm configurados para receber informações de LLD pelos agentes, por exemplo o Template OS Linux: na área Discovery do template temos duas regras de descoberta prontas: Mounted filesystem discovery e Network interface discovery, observe:

A seguir, temos o script em Perl, uma linguagem de programação, que já vem compilado no Zabbix Agent, usado para coletar os dados da descoberta de baixo nível para sistemas de arquivos.

#!/usr/bin/perl
$first = 1;

print "{\n";
print "\t\"data\":[\n\n";

for (`cat /proc/mounts`)
{
    ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
    $fsname =~ s!/!\\/!g;

    print "\t,\n" if not $first;
    $first = 0;

    print "\t{\n";
    print "\t\t\"{#FSNAME}\":\"$fsname\",\n";
    print "\t\t\"{#FSTYPE}\":\"$fstype\"\n";
    print "\t}\n";
}

print "\n\t]\n";
print "}\n";

Mesmo não conhecendo Perl, podemos reparar que o script lê os dados do arquivo /proc/mounts, um arquivo no sistema linux que contém informações sobre os sistemas de arquivos montados no sistema, a partir desse arquivo ele pega o nome e o tipo do ponto de montagem e formata essas informações em JSON.

Veja o conteúdo do arquivo /proc/mounts do host que vamos aplicar o LLD:

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=10240k,nr_inodes=61164,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=50632k,mode=755 0 0
/dev/sda1 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
pstore /sys/fs/pstore pstore rw,relatime 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=179680k 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
rpc_pipefs /run/rpc_pipefs rpc_pipefs rw,relatime 0 0
cgroup /sys/fs/cgroup tmpfs rw,relatime,size=12k 0 0
cgmfs /run/cgmanager/fs tmpfs rw,relatime,size=100k,mode=755 0 0
systemd /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/x86_64-linux-gnu/systemd-shim-cgroup-release-agent,name=systemd 0 0
tmpfs /run/user/115 tmpfs rw,nosuid,nodev,relatime,size=50632k,mode=700,uid=115,gid=121 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=50632k,mode=700,uid=1000,gid=1000 0 0

A seguir, veja o resultado da execução do script Perl:

{
“data”:[
{
“{#FSNAME}”:”\/sys”,
“{#FSTYPE}”:”sysfs”
}
,
{
“{#FSNAME}”:”\/proc”,
“{#FSTYPE}”:”proc”
}
,
{
“{#FSNAME}”:”\/dev”,
“{#FSTYPE}”:”devtmpfs”
}
,
{
“{#FSNAME}”:”\/dev\/pts”,
“{#FSTYPE}”:”devpts”
}
,
{
“{#FSNAME}”:”\/run”,
“{#FSTYPE}”:”tmpfs”
}
,
{
“{#FSNAME}”:”\/”,
“{#FSTYPE}”:”ext4″
}
,
{
“{#FSNAME}”:”\/sys\/fs\/cgroup”,
“{#FSTYPE}”:”tmpfs”
}
,
{
“{#FSNAME}”:”\/sys\/fs\/fuse\/connections”,
“{#FSTYPE}”:”fusectl”
}
,
{
“{#FSNAME}”:”\/sys\/kernel\/debug”,
“{#FSTYPE}”:”debugfs”
}
,
{
“{#FSNAME}”:”\/sys\/kernel\/security”,
“{#FSTYPE}”:”securityfs”
}
,
{
“{#FSNAME}”:”\/run\/lock”,
“{#FSTYPE}”:”tmpfs”
}
,
{
“{#FSNAME}”:”\/run\/shm”,
“{#FSTYPE}”:”tmpfs”
}
,
{
“{#FSNAME}”:”\/run\/user”,
“{#FSTYPE}”:”tmpfs”
}
,
{
“{#FSNAME}”:”\/sys\/fs\/pstore”,
“{#FSTYPE}”:”pstore”
}
,
{
“{#FSNAME}”:”\/boot”,
“{#FSTYPE}”:”ext2″
}
]
}

Pode não parecer mas o formato JSON não é complexo, é exibida uma série declarativa para as variáveis {#FSNAME} e {#FSTYPE}, que no Zabbix chamamos de Macros, que vai indicar o nome e o tipo do sistema de arquivos, consequentemente. É dessa forma que o Zabbix recebe os dados e cria todo o conjunto de monitoramento indicado no template.

Repare que o Template OS Linux indica a Macro {#FSNAME} nas configurações item para descoberta, que chamada de item prototypes , eles correspondem para o item:

Nome de identificação do item Chave

Free disk space on {#FSNAME}

vfs.fs.size[{#FSNAME},free]

Free disk space on {#FSNAME} (percentage)

vfs.fs.size[{#FSNAME},pfree]

Free inodes on {#FSNAME} (percentage)

vfs.fs.inode[{#FSNAME},pfree]

Total disk space on {#FSNAME}

vfs.fs.size[{#FSNAME},total]

Used disk space on {#FSNAME}

vfs.fs.size[{#FSNAME},used]

Os itens indicam quais os valores que serão coletados do agente pelo Zabbix Server, neste caso são informações sobre o consumo de armazenamento nos sistemas de arquivos: tamanho livre, valor de inodes e tamanho total do disco.

O objetivo do item é capturar os dados que podem ser mensurados para que possamos gerar disparos quando um valor anormal for coletado e a partir disto notificar o administrador para avaliação do incidente, no caso do LLD de sistemas de arquivos os triggers indicam quando algum sistema de arquivos está com pouco espaço.

Veja uma relação dos triggers prototypes, nome dado aos disparos criados automaticamente pelo LLD, do Template OS Linux:

Nome de identificação de trigger Expressões

Free disk space is less than 20% on volume {#FSNAME}

{Template OS Linux:vfs.fs.size[{#FSNAME},pfree].last(0)}<20

Free inodes is less than 20% on volume {#FSNAME}

{Template OS Linux:vfs.fs.inode[{#FSNAME},pfree].last(0)}<20

Além de itens e triggers prototypes podemos ter gráficos e hosts prototypes vinculados ao LLD. Os valores das macros são substituídos pelo correspondente no JSON e os recursos gerados pelo LLD ficam nos seus correspondentes do host, como na imagem a seguir:

Repare que cada item referencia a regra de descoberta que o gerou, outro detalhe que podemos destacar é que apenas a métrica do sistema de arquivos raiz ( / ) e /boot foram consideradas. Isto acontece porque o tipo de sistema de arquivos, correspondente à macro {#FSTYPE} passa por um filtro, podemos observá-lo e personalizá-lo em Administration > General > Regular expressions, que indica:

Nome de identificação da expressão Expressão
File systems for discovery ^(btrfs|ext2|ext3|ext4|jfs|reiser|xfs|ffs|ufs|jfs|jfs2|vxfs|hfs|refs|ntfs|fat32|zfs)$ [Result is TRUE]

A expressão indica que só serão monitorados os sistemas de arquivos com os tipos definidos entre parênteses, no JSON enviado ao Zabbix, apenas raiz ( / ) e /boot se encaixam como verdadeiro com os tipos ext4 e ext2 respectivamente, por esse motivo apenas esses serão monitorados.

Com o conhecimento adquirido neste post sobre como funciona o processo de descoberta automática de baixo nível do Zabbix, basta aplicar seus conhecimentos em programação e Linux para desenvolver um script que formate algum dado em JSON para você começar a coletar as demandas de monitoramento dos seus servidores, mas isso já é assunto para outro post.

Anterior MongoDB: como gerenciar dados com noSQL
Próxima Certificações Linux - Um passo a frente nos processos seletivos

About author

Jonathan Alves
Jonathan Alves 3 posts

Jonathan Dantas Alves, atua como Analista de Infraestrutura em Software Livre, formado em Redes de Computadores pela Faculdade de Tecnologia IBTA. Possui experiência em ferramentas voltadas para aplicação da cultura Devops, com ênfase em monitoramento. Detém expertise como instrutir de cursos voltados ao Sistema Operacional Linux, possui Certificação Zabbix e LPIC2

View all posts by this author →

Você pode gostar também

Infraestrutura

Backup PITR centralizado com Barman

O backup PITR(Point-In-Time-Recovery) que é uma ferramenta que permite um arquivamento contínuo das transações ocorridas no banco, para que seja possível a recuperação de qualquer posição dos dados desde o

Infraestrutura

Engenheiro de Dados: nova oportunidade em TI

Profissões tendem a desaparecer e surgir com outras roupagens em um mundo onde a quantidade de conhecimento cresce exponencialmente. Embora esse fenômeno cause crises em algumas áreas, ele pode ser

Infraestrutura

Acessos remoto centralizado com Apache Guacamole

Neste post falo sobre uma ferramenta bastante interessante do projeto Apache chamado Guacamole que irá resolver problemas de acessos remotos a servidores em sua empresa. É uma mão na roda.