Módulos carregáveis oferecem uma opção voltada para o desempenho para estender o Zabbix funcionalidade.
Já existem maneiras de estender a funcionalidade do Zabbix por meio de:
system.run[]
Zabbix agente item.Eles funcionam muito bem, mas têm uma grande desvantagem, ou seja, fork(). Zabbix tem que bifurcar um novo processo toda vez que lida com uma métrica de usuário, que é não é bom para o desempenho. Normalmente não é grande coisa, mas pode ser um problema sério ao monitorar sistemas embarcados, tendo um grande número de parâmetros monitorados ou scripts pesados com lógica complexa ou tempo de inicialização longo.
O suporte de módulos carregáveis oferece maneiras de estender o agente Zabbix, servidor e proxy sem sacrificar o desempenho.
Um módulo carregável é basicamente uma biblioteca compartilhada usada pelo daemon do Zabbix e carregado na inicialização. A biblioteca deve conter certas funções, então que um processo Zabbix pode detectar que o arquivo é de fato um módulo que pode carregar e trabalhar.
Os módulos carregáveis têm vários benefícios. Ótimo desempenho e capacidade de implementar qualquer lógica são muito importantes, mas talvez o mais vantagem importante é a capacidade de desenvolver, usar e compartilhar Zabbix módulos. Contribui para uma manutenção sem problemas e ajuda a fornecer nova funcionalidade mais fácil e independente da base de código central do Zabbix.
O licenciamento e distribuição de módulos em formato binário são regidos pela GPL licença (os módulos estão se conectando com o Zabbix em tempo de execução e estão usando o Zabbix cabeçalhos; atualmente todo o código Zabbix está licenciado sob licença GPL). A compatibilidade binária não é garantida pelo Zabbix.
A estabilidade da API do módulo é garantida durante um Zabbix LTS (Long Term Suporte) lançamento ciclo. A estabilidade da API Zabbix não é garantida (tecnicamente é possível chamar funções internas do Zabbix a partir de um módulo, mas há nenhuma garantia de que tais módulos funcionarão).
Para que uma biblioteca compartilhada seja tratada como um módulo Zabbix, é deve implementar e exportar várias funções. Atualmente existem seis funções na API do módulo Zabbix, sendo apenas uma obrigatória e os outros cinco são opcionais.
A única função obrigatória é zbx_module_api_version():
Esta função deve retornar a versão da API implementada por este módulo e para que o módulo seja carregado esta versão deve corresponder ao módulo Versão da API suportada pelo Zabbix. Versão da API do módulo suportada por Zabbix é ZBX_MODULE_API_VERSION. Então esta função deve retornar isso constante. Constante antiga ZBX_MODULE_API_VERSION_ONE usada para isso O objetivo agora está definido para igualar ZBX_MODULE_API_VERSION para preservar compatibilidade de fonte, mas seu uso não é recomendado.
As funções opcionais são zbx_module_init(), zbx_module_item_list(), zbx_module_item_timeout(), zbx_module_history_write_cbs() e zbx_module_uninit():
Esta função deve realizar a inicialização necessária para o módulo (caso existam). Se for bem-sucedido, deve retornar ZBX_MODULE_OK. Caso contrário isto deve retornar ZBX_MODULE_FAIL. Neste último caso, o Zabbix não começar.
Esta função deve retornar uma lista de itens suportados pelo módulo. Cada item é definido em uma estrutura ZBX_METRIC, veja a seção abaixo para detalhes. A lista é terminada por uma estrutura ZBX_METRIC com campo "chave" de NULL.
Se o módulo exportar zbx_module_item_list() então esta função é usado pelo Zabbix para especificar as configurações de tempo limite na configuração do Zabbix arquivo que as verificações de itens implementadas pelo módulo devem obedecer. Aqui, o parâmetro "timeout" está em segundos.
Esta função deve retornar funções de callback que o servidor Zabbix usará para histórico de exportação de diferentes tipos de dados. As funções de retorno de chamada são fornecidas como campos da estrutura ZBX_HISTORY_WRITE_CBS, os campos podem ser NULL se módulo não está interessado na história de determinado tipo.
Esta função deve realizar a desinicialização necessária (se houver) como liberar recursos alocados, fechar descritores de arquivos, etc.
Todas as funções são chamadas uma vez na inicialização do Zabbix quando o módulo é carregado, com exceção de zbx_module_uninit(), que é chamado uma vez no desligamento do Zabbix quando o módulo é descarregado.
Cada item é definido em uma estrutura ZBX_METRIC:
estrutura typedef
{
caractere *chave;
bandeiras não assinadas;
int(*função)();
char *test_param;
}
ZBX_METRIC;
Aqui, key é a chave do item (por exemplo, "dummy.random"), flags é CF_HAVEPARAMS ou 0 (dependendo se o item aceita parâmetros ou não), função é uma função C que implementa o item (por exemplo, "zbx_module_dummy_random") e test_param é o lista de parâmetros a ser usada quando o agente Zabbix é iniciado com o "-p" sinalizador (por exemplo, "1,1000", pode ser NULL). Uma definição de exemplo pode parecer esta:
chaves ZBX_METRIC estáticas[] =
{
{ "dummy.random", CF_HAVEPARAMS, zbx_module_dummy_random, "1.1000" },
{ NULO }
}
Cada função que implementa um item deve aceitar dois ponteiros parâmetros, o primeiro do tipo AGENT_REQUEST e o segundo do tipo digite AGENTE_RESULTADO:
int zbx_module_dummy_random(AGENT_REQUEST *solicitação, AGENT_RESULT *resultado)
{
...
SET_UI64_RESULT(resultado, de + rand() % (para - de + 1));
retornar SYSINFO_RET_OK;
}
Essas funções devem retornar SYSINFO_RET_OK, se o valor do item foi obtido com sucesso. Caso contrário, eles devem retornar SYSINFO_RET_FAIL. Veja o exemplo de módulo "dummy" abaixo para obter detalhes sobre como obter informações de AGENT_REQUEST e como definir informações em AGENTE_RESULT.
::: não importante A exportação de histórico via módulo não é mais suportada pelo proxy Zabbix desde o Zabbix 4.0.0. :::
O módulo pode especificar funções para exportar dados de histórico por tipo: Numérico (float), Numérico (sem sinal), Caractere, Texto e Log:
estrutura typedef
{
void (*history_float_cb)(const ZBX_HISTORY_FLOAT *history, int history_num);
void (*history_integer_cb)(const ZBX_HISTORY_INTEGER *history, int history_num);
void (*history_string_cb)(const ZBX_HISTORY_STRING *history, int history_num);
void (*history_text_cb)(const ZBX_HISTORY_TEXT *history, int history_num);
void (*history_log_cb)(const ZBX_HISTORY_LOG *history, int history_num);
}
ZBX_HISTORY_WRITE_CBS;
Cada um deles deve ter o array "history" de elementos "history_num" como argumentos. Dependendo do tipo de dados do histórico a ser exportado, "histórico" é uma matriz das seguintes estruturas, respectivamente:
estrutura typedef
{
zbx_uint64_t itemid;
relógio interno;
int ns;
valor duplo;
}
ZBX_HISTORY_FLOAT;
estrutura typedef
{
zbx_uint64_t itemid;
relógio interno;
int ns;
valor zbx_uint64_t;
}
ZBX_HISTORY_INTEGER;
estrutura typedef
{
zbx_uint64_t itemid;
relógio interno;
int ns;
const char *valor;
}
ZBX_HISTORY_STRING;
estrutura typedef
{
zbx_uint64_t itemid;
relógio interno;
int ns;
const char *valor;
}
ZBX_HISTORY_TEXT;
estrutura typedef
{
zbx_uint64_t itemid;
relógio interno;
int ns;
const char *valor;
const char *fonte;
int timestamp;
int logeventid;
gravidade int;
}
ZBX_HISTORY_LOG;
Callbacks serão usados pelos processos de sincronização de histórico do servidor Zabbix no fim do procedimento de sincronização do histórico após os dados serem gravados no banco de dados Zabbix e salvo no cache de valor.
Atualmente, os módulos devem ser construídos dentro da árvore de origem do Zabbix, porque a API do módulo depende de algumas estruturas de dados que são definidas nos cabeçalhos do Zabbix.
O cabeçalho mais importante para módulos carregáveis é include/module.h, que define essas estruturas de dados. Outros cabeçalhos de sistema necessários que ajudar include/module.h a funcionar corretamente são stdlib.h e stdint.h.
Com essas informações em mente, está tudo pronto para que o módulo seja construído. O módulo deve incluir stdlib.h, stdint.h e module.h, e o script de compilação deve garantir que esses arquivos sejam no caminho de inclusão. Veja o exemplo de módulo "fictício" abaixo para obter detalhes.
Outro cabeçalho útil é include/log.h, que define zabbix_log() função, que pode ser usada para registro e depuração propósitos.
Agent, servidor e proxy Zabbix suportam dois parâmetros para lidar com módulos:
Por exemplo, para estender o agente Zabbix, podemos adicionar o seguinte parâmetros:
LoadModulePath=/usr/local/lib/zabbix/agent/
LoadModule=mariadb.so
LoadModule=apache.so
LoadModule=kernel.so
LoadModule=/usr/local/lib/zabbix/dummy.so
Após a inicialização do agent, ele carregará o mariadb.so, apache.so e kernel.so módulos do diretório /usr/local/lib/zabbix/agent enquanto dummy.so será carregado de /usr/local/lib/zabbix. Ele falhará se um módulo for ausente, em caso de permissões ruins ou se uma biblioteca compartilhada não for um Módulo Zabbix.
Módulos carregáveis são suportados pelo agente Zabbix, servidor e proxy. Portanto, o tipo de item no frontend do Zabbix depende de onde o módulo está carregado. Se o módulo estiver carregado no agente, o tipo de item deve ser "agente Zabbix" ou "agente Zabbix (ativo)". Se o módulo estiver carregado no servidor ou proxy, então o tipo de item deve ser "Simple Verifica".
A exportação de histórico através dos módulos Zabbix não precisa de nenhum frontend configuração. Se o módulo for carregado com sucesso pelo servidor e fornece a função zbx_module_history_write_cbs() que retorna pelo menos uma função de retorno de chamada não NULL, a exportação do histórico será habilitado automaticamente.
O Zabbix inclui um módulo de exemplo escrito em linguagem C. O módulo é localizado em src/modules/dummy:
alex@alex:~trunk/src/modules/dummy$ ls -l
-rw-rw-r-- 1 alex alex 9019 24 de abril 17:54 dummy.c
-rw-rw-r-- 1 alex alex 67 de abril 24 17:54 Makefile
-rw-rw-r-- 1 alex alex 245 24 de abril 17:54 README
O módulo está bem documentado, pode ser usado como modelo para o seu próprio módulos.
Depois que ./configure foi executado na raiz da árvore de origem do Zabbix como descrito acima, basta executar make para compilar dummy.so.
``` {.c} /* Zabbix Copyright (C) 2001-2020 Zabbix SIA Este programa é um software livre; você pode redistribuí-lo e/ou modificá-lo sob os termos da GNU General Public License conforme publicada por a Fundação do Software Livre; quer a versão 2 da Licença, ou (a seu critério) qualquer versão posterior. Este programa é distribuído na esperança de que seja útil, mas SEM QUALQUER GARANTIA; sem mesmo a garantia implícita de COMERCIALIZAÇÃO ou ADEQUAÇÃO A UM DETERMINADO FIM. Veja o Licença Pública Geral GNU para mais detalhes. Você deve ter recebido uma cópia da GNU General Public License junto com este programa; se não, escreva para o Software Livre Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, EUA. **/
#include <stdlib.h> #include <string.h> #include <hora.h> #include <stdint.h>
#include "módulo.h"
/* a variável mantém a configuração de tempo limite para processamento de itens */ static int item_timeout = 0;
/* módulo DEVE definir funções internas como estáticas e usar um padrão de nomenclatura diferente do interno do Zabbix / / símbolos (zbx_) e funções da API do módulo carregável (zbx_module_) para evitar conflitos / static int dummy_ping(AGENT_REQUEST solicitação, AGENT_RESULT resultado); static int dummy_echo(AGENT_REQUEST solicitação, AGENT_RESULT resultado); static int dummy_random(AGENT_REQUEST solicitação, AGENT_RESULT *resultado);
chaves ZBX_METRIC estáticas[] = /* PARÂMETROS DE TESTE DE FUNÇÃO DE SINALIZADOR DE CHAVE */ { {"dummy.ping", 0, dummy_ping, NULL}, {"dummy.echo", CF_HAVEPARAMS, dummy_echo, "uma mensagem"}, {"dummy.random", CF_HAVEPARAMS, dummy_random, "1.1000"}, {NULO} };
/**************************************************** ******************************** * Função: zbx_module_api_version Finalidade: retorna o número da versão da interface do módulo Valor de retorno: ZBX_MODULE_API_VERSION - versão do módulo module.h é compilado com, para carregar o módulo Zabbix com sucesso DEVE ser compilado com a mesma versão deste arquivo de cabeçalho *************************************************** ****************************/ int zbx_module_api_version(void) { retornar ZBX_MODULE_API_VERSION; }
/**************************************************** ******************************** * Função: zbx_module_item_timeout Objetivo: definir valor de tempo limite para processamento de itens Parâmetros: timeout - timeout em segundos, 0 - nenhum timeout definido *************************************************** ****************************/ void zbx_module_item_timeout(int timeout) { item_timeout = tempo limite; }
/**************************************************** ******************************** * Função: zbx_module_item_list Finalidade: retorna lista de chaves de item suportadas pelo módulo Valor de retorno: lista de chaves de itens *************************************************** ****************************/ ZBX_METRIC *zbx_module_item_list(void) { teclas de retorno; }
static int dummy_ping(AGENT_REQUEST solicitação, AGENT_RESULT resultado) { SET_UI64_RESULT(resultado, 1);
}
static int dummy_echo(AGENT_REQUEST solicitação, AGENT_RESULT resultado) { Caracteres
O suporte de módulos carregáveis é implementado apenas para a plataforma Unix. Isso significa que não funciona para agentes do Windows.
Em alguns casos, um módulo pode precisar ler a configuração relacionada ao módulo parâmetros de zabbix_agentd.conf. Não é suportado atualmente. Se você precisa que seu módulo use alguns parâmetros de configuração que você deve provavelmente implementa a análise de um arquivo de configuração específico do módulo.