Soluciones

Los Módulos en el Zabbix Agent ofrecen una funcionalidad extendida, pensada para mejorar el rendimiento.

En otras palabras, adaptar Zabbix a nuestras necesidades y monitorear exactamente lo que queremos.

En Zabbix Agent ya existen algunas utilidades que contribuyen a esto:

• Userparameters (métricas de Zabbix Agent, que utilizan Items)
• External checks (métricas en las que no se utiliza el Zabbix Agent, por ejemplo, chequeos por SNMP)
• El Item system.run[] de Zabbix Agent (permite ejecutar determinado comando en el Host)

Normalmente, éstas funcionalidades son muy eficaces, pero tenemos que tener en cuenta que, Zabbix va a inicar un nuevo proceso por cada métrica que necesita ejecutar.

Esto puede bajar mucho el rendimiento de Zabbix, si tenemos muchos comandos, scripts pesados o sistemas embebidos (embedded systems, diseñados para realizar funciones en específico).

Un Módulo permite extender las funcionalidades de Zabbix sin sacrificar el rendimiento del Zabbix Server o Zabbix Proxy.

Pueden implementarse con todo tipo de lógica y son librerías compartidas utilizadas por el proceso de Zabbix que inician junto con el servicio de Zabbix.

Sin embargo, lo más importante es que permite el desarrollo.

Es decir, se pueden desarrollar, compartir y usar estos módulos.

API de Módulos en Zabbix

Con el objetivo de hacer que una librería compartida sea considerada un Módulo en Zabbix, deberán implementarse y exportarse varias funciones.

Actualmente hay seis funciones en la API de Módulos de Zabbix y obligatoriamente se debe definir la versión de la API, mientras el resto de las interfaces son opcionales.

Versión (Obligatoria)

int	zbx_module_api_version(void);

Esta función devolverá la versión implementada en el módulo.

Inicialización (Opcional)

int	zbx_module_init(void);

Realizará lo necesario para la inicialización del módulo, Devolverá OK / FAIL según el resultado, en el caso de que Zabbix no inicie.

Lista de Items (Opcional)

ZBX_METRIC	*zbx_module_item_list(void);

Retornará la lista de Items soportados por el módulo. Cada uno está definido en una estructura de tipo ZBX_METRIC, y el valor de la «key» por defecto es NULL.

Configuración del Timeout (Opcional)

void	zbx_module_item_timeout(int timeout);

Si el módulo exporta zbx_module_item_list(), esta función es utilizada por Zabbix para especificar las configuraciones del Timeout en el archivo de configuración de Zabbix, el cual será respetado por los chequeos especificados en el módulo.

Callback de funciones (Opcional)

ZBX_HISTORY_WRITE_CBS	zbx_module_history_write_cbs(void);

Esta función retornará la lista de funciones: callback (funciones que son utilizadas como argumento) que Zabbix usará para exportar la historia de diferentes tipos de datos.

Los valores pueden ser NULL si el módulo no está intereado en la historia de un determinado tipo de datos.

Cierre (Opcional)

int	zbx_module_uninit(void);

Dicha función se encarga de cerrar, es decir, realizar lo opuesto a la inicialización.

Libera recursos ocupados, etc.

Recordemos que todas las funciones son llamadas una vez al momento en el que se carga el módulo, a excepción de ésta.

Definición de Items

Cada Item está definido en una estructura ZBX_METRIC, como se ve a continuación:

typedef struct
{
	char		*key;
	unsigned	flags;
	int		(*function)();
	char		*test_param;
}
ZBX_METRIC;

Se define la «key» la cual será la key del Item, y las Banderas.

static ZBX_METRIC keys[] =
{
	{ "dummy.random", CF_HAVEPARAMS, zbx_module_dummy_random, "1,1000" },
	{ NULL }
}

Cada función que implementa un Item debe aceptar dos Parámetros, siendo el primero de tipo AGENT_REQUEST y el segundo de tipo AGENT_RESULT.

int	zbx_module_dummy_random(AGENT_REQUEST *request, AGENT_RESULT *result)
{
	...
 
	SET_UI64_RESULT(result, from + rand() % (to - from + 1));
 
	return SYSINFO_RET_OK;

Estas funciones devolverán SYSINFO_RET_OK si el Parámetro fue obtenido con éxito, de lo contrario retornarán SYSINFO_RET_FAIL.

Historia del Item

Se pueden definir dentro del módulo, ciertas funciones para exportar los datos de la Historia del Item según el tipo de dato.

typedef struct
{
	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 uno de ellos seleccionará el array «history» de «history_num», cuantas veces éste último exista como argumento.

En este caso por ejemplo, estamos queriendo obtener la Historia filtrando por tipo de dato FLOAT.

typedef struct
{
	zbx_uint64_t	itemid;
	int		clock;
	int		ns;
	double		value;
}
ZBX_HISTORY_FLOAT;

Construyendo módulos

El encabezado (header) más importante para los módulos es el include/module.h, el cual define la estructura de los datos.

Otro encabezado útil es el include/sysinc.h, el cual realiza la inclusión de todos los encabezados necesarios por el sistema.

Entre ellos, también incluye el include/module.h el cual es necesario para trabajar correctamente.

Para que, tanto include/module.h como include/syninc.h sean incluidos, el comando ./configure (sin argumentos) debería ser ejecutado primeramente en el directorio raíz de los recursos de Zabbix.

Esto creará el archivo include/config.h, del cual depende include/sysinc.h.

Parámetros de configuración

El Zabbix Agent, Zabbix Server y Proxy, soportan dos parámetros para lidiar con los módulos.

• LoadModulePath
  • La ruta completa donde están los módulos
• LoadModule
  • Los módulos que se cargarán al inicio de Zabbix. Estos deben estar ubicados en el directorio que estará especificado en el primer parámetro. Es posible definir un LoadModule=nombre_modulo.so.

Configuración del Frontend

Ya que los módulos son soportados por el Zabbix Agent, el Zabbix Server y el Zabbix Proxy, el tipo de Item en el Zabbix Frontend dependerá de dónde se carga el módulo.

Si el módulo es cargado en el Agente, entonces el tipo de chequeo deberá ser Passive Check o Active Check.

Si el módulo es cargado en el Server o en el Proxy, deberá ser de tipo «Simple Check».


?Más info aquí

+Leer