2 Organización y funcionamiento

2.1 Un proceso, un hilo por monitor#

Databbix se ejecuta como un único proceso, databbix, que atiende todas las fuentes de datos de la máquina. Dentro del proceso, cada fuente de datos se atiende en su propio hilo, llamado monitor:

Hilo principal.: Lee la configuración global, recorre el directorio de monitores y lanza un hilo por cada fichero .conf. Después se queda esperando: reabre los ficheros de log cuando recibe SIGHUP y ordena la parada de todos los monitores cuando recibe SIGTERM o SIGINT.
Hilo de monitor.: Hay uno por fichero .conf. Cada monitor tiene su propia conexión con la fuente de datos, su propia conexión con Zabbix y su propio fichero de log.
Hilo pasivo.: Si el monitor tiene PassivePort distinto de 0, lanza un hilo adicional que escucha en ese puerto y responde a las comprobaciones pasivas de Zabbix.
Hilos del motor.: Algunos motores necesitan hilos propios. El motor MQTT, por ejemplo, tiene un hilo que recibe continuamente los mensajes del broker.

Los monitores son independientes entre sí:

Si una fuente de datos falla o está parada, solo se ve afectado su monitor. El resto sigue funcionando.
Si un monitor no puede arrancar (por ejemplo, por un error en su .conf o en un XML), ese monitor termina y lo registra en su log, pero el proceso sigue atendiendo a los demás. El monitor no se vuelve a lanzar hasta que se reinicia el servicio.
Un monitor también termina si supera MaxErrors ejecuciones fallidas seguidas.
Cuando terminan todos los monitores, el proceso termina.

Atención. Como un monitor que falla no detiene el proceso, systemctl status puede mostrar el servicio activo aunque alguno de los monitores no esté funcionando. Para vigilarlo, use el ítem pasivo agent.ping o compruebe en Zabbix que llegan datos de cada host.

2.2 Ficheros de configuración#

La configuración se reparte en tres niveles:

Fichero	Formato	Contenido
`databbix.conf` (uno)	INI	Configuración del proceso: usuario y grupo del demonio, directorio de monitores, módulos y valores por defecto de logs, ficheros de consultas y variables de entorno para todos los monitores.
`dbs/*.conf` (uno por monitor)	INI	Todo lo propio de una fuente de datos: nombre del host en Zabbix, servidor Zabbix, motor, datos de conexión (driver, cadena de conexión, usuario, URL, autenticación…), ficheros de consultas y variables de entorno propias.
`query*.xml`	XML	Qué datos se obtienen y cómo: consultas SQL o llamadas a servicios, los ítems de Zabbix que produce cada una, contextos, scripts y autenticaciones. No contienen datos de conexión, así que un mismo XML sirve para todas las fuentes del mismo tipo.
`tnsnames.ora`, `odbc.ini`	propios	Definición de las conexiones de Oracle y ODBC a las que se refieren los ficheros de monitor.
`/etc/sysconfig/ databbix`	variables de shell	Entorno del servicio (`TNS_ADMIN`, `ODBCINI`…).
`AuthPersistFile` (opcional)	JSON	Estado de la autenticación de un webservice (por ejemplo, el token), para no tener que volver a autenticarse tras un reinicio. Lo escribe Databbix.

2.2.1 Herencia de valores#

Algunos parámetros se pueden poner en los dos primeros niveles. En ese caso, el valor del fichero de monitor tiene prioridad sobre el de databbix.conf:

Los parámetros de la sección [Log] se heredan uno a uno. Un monitor puede, por ejemplo, subir solo su LogLevel.
QueryFile: si el monitor define alguno, su lista sustituye por completo a la global.
Environment: el monitor ve las variables globales y las suyas. Si una variable está en ambos sitios, gana la del monitor. Las dos tienen prioridad sobre los valores por defecto del XML.

2.3 Ciclo de vida de un monitor#

Al arrancar, cada monitor hace lo siguiente:

Lee su fichero .conf y comprueba que están los parámetros obligatorios.
Carga la colección de consultas de sus ficheros XML. Si hay un error de sintaxis, el monitor termina.
Se conecta a la fuente de datos. Si no puede, lo reintenta más tarde.
Pide al servidor Zabbix la lista de ítems activos del host (active checks).
Si está configurado, lanza el hilo pasivo.

Después entra en un bucle. En cada vuelta elige la primera tarea que corresponda y duerme hasta que llegue su momento:

Si aún no tiene la lista de ítems, la pide a Zabbix.
Si no hay conexión con la fuente de datos, vuelve a conectar.
Si quedaron valores sin enviar por un fallo de Zabbix, los reenvía.
Si toca actualizar la lista de ítems (cada Zabbix.Refresh segundos), la pide de nuevo.
Si no, ejecuta las consultas de los ítems que han cumplido su intervalo y envía los resultados.

Cuando falla la conexión con la fuente o con Zabbix, el monitor espera General.RetryOnError segundos antes de reintentar. Si se pierde la conexión con Zabbix, los valores obtenidos se guardan y se envían cuando vuelve la conexión.