Uno de los componentes de Zabbixes elZabbix Agent, que, aunque es opcional su instalación (no es esencial para monitorear, podemos hacerlo mediante SNMP entre otros), nos abre la «puerta mas grande» para monitorear un dispositivo.
Para poder instalar el Agent, es necesario que exista un Sistema Operativo. Zabbix provee Pre Compiled Agents para muchos Sistemas Operativos tales como Ubuntu, Red Hat, Centos, Suse, Raspbian (Sistema Operativo de la raspberry), etc.
En caso de que no exista un agente precompilado, si el Sistema Operativo tiene un compilador C, alcanza con bajar los fuentes y compilarlo. Zabbix y nosotros ofrecemos ayuda para esto.
Configuración mínima de Zabbix Agent.
Lo mínimo que tenemos que decirle al Agente es cuál Zabbix Server o Proxy puede preguntarle datos (Passive Checks Chequeos Pasivos) y/o a quien tiene que ir a consultar por Chequeos Activos (Active Checks).
La configuración del agente se hace en un archivo de configuración en texto plano «zabbix_agentd.conf«, generalmente (y recomendablemente) se encuentra en el directorio /etc/zabbix/.
La mínima configuración (luego la podemos recortar un poco más) es:
Como puede verse en Tipos de Chequeos hay chequeos activos y pasivos, nombrados así por como los ve el agente.
El Server va a ser el sevidor que se va «a encargar» de los chequeos pasivos y el ServerActive, de los chequeos activos.
Server
Todas las IP (y/o DNS) listadas en Server son las IP del Zabbix Server o Proxy de las que el agente va a aceptar preguntas, es decir Chequeos Pasivos. Si alguien que no esta en la lista le pregunta, lo va a ignorar.
ServerActive/Hostname
El ServerActive lista las IP (y/o DNS) del Zabbix Server o Proxy a donde el agente va a ir a preguntar periódicamente «¿qué información querés que te mande?». El agente se va a identificar con el valor de Hostname, y es por eso que ese valor debe coincidir con el nombre que se le dio al host cuando se dió de alta en el FrontEnd. En síntesis, el agente le va a preguntar a cada IP listada, «soy Hostname, ¿qué ítems tienes configurados para mi?»
Recortando un poco más.
Si nuestro Agent se encuentra inaccesible desde el Server, es decir, no tenemos posibilidad de hacerle preguntas, solo vamos a poder cosechar Chequeos Activos, por lo que podríamos obviar configurar el Server. Dicho de otra manera, si no se configura el Server, los chequeos pasivos están deshabilitados.
Si por el contrario, el Agente es incapaz de establecer la comunicación con el Zabbix Server, solo vamos a cosechar Chequeos Pasivos, carece de importancia configurar ServerActive y Hostname. Dicho de otra manera, si no se configura el ServerActive y Hostname, los chequeos activos están deshabilitados
Tips: Al limitar los servidores en la configuración, impido que un servidor externo pregunte datos al agente. Esto va a evitar que múltiples servidores «molesten» al agente y se filtren datos. Es conveniente mantener al mínimo los servidores configurados.
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.
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:
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
NOTA: En el caso de que el script ./configure no exista aún, se debe ejecutar primero el comando ./bootstrap.sh para generarlo. Esto puede darse porque se obtuvo Zabbix desde otro repositorio siendo una sub-versión.
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.
NOTA: En el caso de que el script ./configure no exista aún, se debe ejecutar primero el comando ./bootstrap.sh para generarlo. Esto puede darse porque se obtuvo Zabbix desde otro repositorio siendo una sub-versión.
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.
Ahora que ya conocemos las configuraciones básicas y necesarias del Zabbix Agent, podemos descubrir otras configuraciones. Con esto definiremos nuevas funcionalidades y tendremos mayor control sobre nuestros equipos.
Autoregister en Zabbix
El Autoregister es una opción la cual permite que se registre automáticamente en el equipo quede monitoreado. Siempre y cuando esté bien instalado y funcionando el Zabbix Agent en un equipo
Esto ahorra tiempo si tenemos que hacer una instalación masiva en muchos equipos. De esta manera no tenemos que ir agregando cada equipo manualmente.
Tener en cuenta que ésta funcionalidad está implementada desde Zabbix 2.0, pero a partir de las versiones 4.0. La acción de Autoregister se realiza cada vez que el Zabbix Agent intenta hacer un chequeo de tipo Active Check.
En estas versiones esto ocurre cada 60s, lo cual favorece la rapidez para detectar nuevos equipos.
Crear un Action
Para configurar dicha funcionalidad, debemos ir a la sección «Configuration». Luego a «Action» en nuestro Zabbix Frontend y seleccionar el tipo de Acción. Debemos elegir en el menú desplegable «Event source: Autoregister» y finalmente hacer clic en el botón «Create Action».
Allí, estableceremos condiciones para que la Acción de Autoregister ocurra cuando dichas condiciones se cumplan; o por el contrario, no se cumplan. Es decir, hacer que dicha Acción se ejecute con una negación referente al contenido del Metadata.
De esta manera podemos, por ejemplo, establecer que la Acción sea ejecutada si el Metadata contiene una palabra que definiremos. O bien, si es exactamente dicha palabra o sentencia.
En este caso, definimos que, si el Metadata es equivalente a la frase «oficina-central», se va a ejecutar dicha Acción.
Definir Operaciones en Action
Ahora bien, si vamos a agregar a Zabbix los nuevos Zabbix Agent que se detecten, entonces necesitamos definir una Operación y definir más datos. Es posible configurar el HostGroup a donde irá este nuevo Host y que Templates se les asignarán.
Esto lo hacemos al cambiar a la pestaña «Operations» y clic en «New».
Se desplegarán opciones para que podamos crear una nueva Operación. En este caso, queremos que el nuevo Host que se reporte sea agregado, en el HostGroup «Equipos Oficina Central».
Para eso debemos configurar las Operaciones de la Acción definiendo una Operación para cada característica que queramos especificar.
Primero, debemos especificar que cuando se ejecute la Acción, se agregue el Host en cuestión (que cumpla las condiciones que establecimos al principio). Elegiremos entonces, «Operation type: Add Host», y haremos clic en Add para añadir la Operación a la Acción.
En segundo lugar, añadiremos otra Operación haciendo clic en el botón «New» y luego elegiremos «Operation type: Add to host group»
Finalmente daremos clic en el botón azul «Add» que está abajo, para crear la Acción. Recordemos que se puede deshabilitar la Acción y también editar o eliminar tanto la Acción como sus Operaciones.
Como mencionamos anteriormente, también es posible determinar condiciones más complejas. Con el uso de Regular Expressions podemos indicar que la condición se cumpla si el Metadata equivale a «nada». Es decir, no se define o está vacío.
Configuración del Metadata y ServerActive en Zabbix Agent
Ahora bien, ¿cómo configuramos el Metadata en el Zabbix Agent? Para acceder a esta configuración, tenemos que modificar el parámetro «Metadata». El mismo está en el archivo de configuración del Zabbix Agent, donde podemos descomentar el parámetro. Esto sería quitar el # que está delante de «Metadata» y modificar el valor para hacerlo coincidir con lo establecido en la condición del Action.
También es necesario especificar el parámetro ServerActive en el archivo de configuración del Zabbix Agent. Esto lo hacemos para definir que los chequeos de tipo Active Checks sean dirigidos a la IP que definimos en el parámetro.
En este punto iniciamos o reiniciamos el Zabbix Agent, y podemos echar un vistazo al Log de Zabbix Server. Podemos ver que el equipo en cuestión intentó hacer un chequeo de tipo Active Check y dio error (ya que el mismo no esta agregado en Zabbix).
Sin embargo, al tener el Action de Autoregister, dicho error solo ocurre esa vez, ya que es el momento en cuando se toman los datos para poder darse de alta él mismo.
Tener en cuenta que, añadir equipos mediante la función Autoregister, se rige bajo las mismas reglas que añadir un equipo manualmente. Es decir, esto solamente podrá funcionar si no existe un Host con el mismo Hostname.
Por tanto es necesario cambiar siempre el Hostname en el archivo de configuración del Zabbix Agent. O bien asegurarse que el nombre de Host del equipo sea diferente y único a los que ya existen.
Asignación de nuevas Keys en Zabbix
Para asignar nuevas Keys en Zabbix, tenemos que comprender primero qué son las Keys y que es el archivo Userparameters. El uso de este archivo, permite una funcionalidad extendida para mejorar el desempeño de Zabbix. Puedes ver más información en el artículo Zabbix Agent: Uso de Módulos
Key
Es un atributo del Item el cual se refiere a una solicitud, comando o query para obtener determinados datos recolectados por Zabbix. Recordemos que un Item es un elemento que podemos agregar en Zabbix para configurar un nuevo chequeo, y la query es una solicitud o consulta al Zabbix Database, una vez ya se recolectó dicho dato (gracias a un comando).
Userparameters
Dicho archivo sirve para especificar nuevas Keys en él. Es muy útil cuando queremos consultar por algún chequeo que no está comprendido por las Keys que tiene por defecto el Zabbix Agent. De esta manera, podemos agregar un nuevo Item a Zabbix, con esta nueva Key que creamos, y tener monitoreo en el Zabbix Frontend, ver el histórico, verlo en Grafana, etc.
Editar el archivo Userparameters en Zabbix Agent
Es necesario que dicho archivo este configurado en todos los equipos en los que necesitamos que funcionen las Keys que queremos establecer. Por ejemplo, si queremos configurar un archivo Userparameters donde se definan las Keys que utilizaremos para realizar consultas a la Zabbix Database, deberíamos crearlo en el Zabbix Agent del Zabbix Database.
Para que funcione el archivo Userparamenters, también es necesario indicarle dónde está éste archivo al Zabbix Agent.
Esto se puede hacer editando el archivo de configuración del Zabbix Agent, y agregar la siguiente línea. Podemos realizar la búsqueda del término «include» en el archivo de configuración de Zabbix Agent para ubicarnos rápidamente y encontrar el lugar donde debemos configurar que, Zabbix Agent incluya también las Keys que se encuentran en dicho directorio y que terminen con .conf.
Include=/etc/zabbix/zabbix_agentd.d/*.conf
Vamos a crear el archivo userparameters.mysql en la ruta que especificamos y lo editaremos para continuar con las Keys.
Ahora, se debe seguir determinada sintaxis para que las nuevas Keys sean reconocidas y funcionen como tal.
Userparameters=<key>,<command>
La <key> será de nuestra elección, que sea referente al propósito de dicha consulta. Debe ser única dentro del Host, es decir que en el Host, no puede existir otra Key con el mismo nombre. Ésta, será la misma Key que vamos a introducir cuando creemos el Item y debamos especificar la Key del mismo.
*insertar captura de pantalla al cr4ar un item
El <command> es el script o la función mediante la cual recolectaremos esos datos que serán guardados en el Zabbix Database. Puede ser la ejecución de un archivo con un script mucho más complejo que hayamos definido.
Mysql.ping como ejemplo para Key
En el siguiente ejemplo tenemos un Userparameter con <key> = mysql.ping y un <command> = mysqladmin -uroot ping | grep -c alive
La <key> mysql.ping es simplemente el nombre de la Key para poder hacer referencia a la misma y la que vamos a utilizar al crear el Item.
El <comand> mysqladmin -uroot ping | grep -c alive, intenta conectarse y hacer un ping con el usuario root. Existe una separación con «|», esto hace que lo que está después del pipeline se ejecute luego de haber ejecutado lo que está antes del mismo.
Entonces, la ejecución de mysqladmin -uroot ping dará un resultado donde veremos la información del ping que realizamos, en definitiva si se puede o no conectar a la Base de Datos.
Esto imprimirá un resultado en pantalla, en el cual buscamos y contamos con un grep, si existe el término «alive». De esta manera, si la ejecución de este UserParameter da como resultado «1», significa que encontró una vez el término «alive» y por tanto, la conexión a mysql está disponible.
Tener en cuenta que, si queremos utilizar comandos más complejos, y realizar consultas al Zabbix Database, lo más probable es que debamos utilizar un usuario con una contraseña que tenga los permisos suficientes para acceder a la Database en cuestión. Tendremos que definir un archivo y especificar en el mismo, los datos para conectarnos a MySQL.
Este mismo archivo será el que Userparameters tomará como referencia para hacer la conexión y la consulta. Para que lo encuentre, es necesario especificar que el directorio donde se encuentra este archivo .my.cnf, sea el HOME.
Join the conversation