El server realiza el sondeo y la captura de datos, calcula los triggers y envía notificaciones a los usuarios. Es el componente central al que los agentes y proxies de Zabbix informan sobre la disponibilidad e integridad de los sistemas. El server también puede comprobar de forma remota servicios en red (como servidores web y servidores de correo) mediante comprobaciones simples de servicios.

El server es el repositorio central en el que se almacenan todos los datos de configuración, estadísticos y operativos, y es la entidad de Zabbix que alertará activamente a los administradores cuando surjan problemas en cualquiera de los sistemas monitorizados.

El funcionamiento de un Zabbix server básico se divide en tres componentes distintos; estos son: Zabbix server, frontend web y almacenamiento de base de datos.

Toda la información de configuración de Zabbix se almacena en la base de datos, con la que interactúan tanto el server como el frontend web. Por ejemplo, cuando crea un nuevo item usando el frontend web (o la API), este se añade a la tabla de items en la base de datos. Luego, aproximadamente una vez por minuto, Zabbix server consultará la tabla de items para obtener una lista de los items activos, que después se almacena en una caché dentro de Zabbix server. Por eso, los cambios realizados en el frontend de Zabbix pueden tardar hasta dos minutos en aparecer en la sección de datos más recientes.

Ejecutando el servidor

Si se instala como paquete

El servidor Zabbix se ejecuta como un proceso demonio. El servidor puede iniciarse ejecutando:

systemctl start zabbix-server

Esto funcionará en la mayoría de los sistemas GNU/Linux. En otros sistemas puede que necesite ejecutar:

/etc/init.d/zabbix-server start

De manera similar, para detener/reiniciar/ver el estado, utilice los siguientes comandos:

systemctl stop zabbix-server
systemctl restart zabbix-server
systemctl status zabbix-server

Iniciar manualmente

Si lo anterior no funciona, debe iniciarlo manualmente. Busque la ruta del binario zabbix_server y ejecute:

zabbix_server

Puede usar los siguientes parámetros de línea de comandos con Zabbix server:

-c --config <file>              Ruta al archivo de configuración (el valor predeterminado es /usr/local/etc/zabbix_server.conf)
-f --foreground                 Ejecutar Zabbix server en primer plano
-R --runtime-control <option>   Realizar funciones administrativas
-T --test-config                Validar el archivo de configuración y salir
-h --help                       Mostrar esta ayuda
-V --version                    Mostrar el número de versión

Ejemplos de ejecución de Zabbix server con parámetros de línea de comandos:

zabbix_server -c /usr/local/etc/zabbix_server.conf
zabbix_server --help
zabbix_server -V

Control de ejecución

Opciones de control de ejecución:

Option	Description	Target
`config_cache_reload`	Recargar la caché de configuración. Se ignora si la caché se está cargando actualmente.
`history_cache_clear=target`	Vaciar la caché de historial para el item especificado por su ID. Afecta a todos los valores del item, excepto el primero y el último valor.	target - ID del item
`diaginfo[=<section>]`	Recopilar información de diagnóstico en el archivo de registro del server.	`historycache` - estadísticas de la caché de historial; `valuecache` - estadísticas de la caché de valores; `preprocessing` - estadísticas del gestor de preprocesamiento; `alerting` - estadísticas del gestor de alertas; `lld` - estadísticas del gestor de LLD; `locks` - lista de mutexes (está vacía en sistemas BSD); `connector` - estadísticas de los conectores con la cola más grande.
`ha_status`	Registrar el estado del clúster de alta disponibilidad (HA).
`ha_remove_node=target`	Eliminar el nodo de alta disponibilidad (HA) especificado por su nombre o ID. Tenga en cuenta que no se pueden eliminar nodos activos/en espera.	target - nombre o ID del nodo (se puede obtener ejecutando `ha_status`).
`ha_set_failover_delay=delay`	Establecer el retardo de conmutación por error de alta disponibilidad (HA). Se admiten sufijos de tiempo, por ejemplo 10s, 1m.
`proxy_config_cache_reload[=<target>]`	Recargar la caché de configuración del proxy.	target - lista de nombres de proxy delimitada por comas. Si no se especifica ningún target, se recarga la configuración de todos los proxy.
`secrets_reload`	Recargar los secretos desde Vault.
`service_cache_reload`	Recargar la caché del gestor de servicios.
`snmp_cache_reload`	Recargar la caché SNMP: borrar las propiedades del motor SNMP (tiempo del motor, arranques del motor, ID del motor, credenciales) para todos los hosts. Úselo para forzar un borrado global de la caché al solucionar problemas de SNMP.
`housekeeper_execute`	Iniciar el procedimiento de housekeeping. Se ignora si el procedimiento de housekeeping ya está en curso.
`trigger_housekeeper_execute`	Iniciar el procedimiento de housekeeping de trigger. Se ignora si el procedimiento de housekeeping de trigger ya está en curso.
`log_level_increase[=<target>]`	Aumentar el nivel de registro; afecta a todos los procesos si no se especifica target. No compatible con sistemas BSD.	process type - todos los procesos del tipo especificado (por ejemplo, `poller`). Consulte todos los tipos de procesos del server. process type,N - tipo de proceso y número (por ejemplo, `poller,3`). pid - identificador de proceso (`1` a `65535`). Para valores mayores, especifique el target como 'process type,N'.
`log_level_decrease[=<target>]`	Disminuir el nivel de registro; afecta a todos los procesos si no se especifica target. No compatible con sistemas BSD.
`prof_enable[=<target>]`	Habilitar el perfilado. Afecta a todos los procesos si no se especifica target. El perfilado habilitado proporciona detalles de todos los rwlocks/mutexes por nombre de función.	process type - todos los procesos del tipo especificado (por ejemplo, `history syncer`) Tipos de proceso admitidos como targets de perfilado: `alerter`, `alert manager`, `availability manager`, `configuration syncer`, `discovery manager`, `escalator`, `history poller`, `history syncer`, `housekeeper`, `http poller`, `icmp pinger`, `ipmi manager`, `ipmi poller`, `java poller`, `lld manager`, `lld worker`, `odbc poller`, `poller`, `preprocessing manager`, `preprocessing worker`, `proxy poller`, `self-monitoring`, `service manager`, `snmp trapper`, `task manager`, `timer`, `trapper`, `unreachable poller`, `vmware collector`. process type,N - tipo de proceso y número (por ejemplo, `history syncer,1`). pid - identificador de proceso (`1` a `65535`). Para valores mayores, especifique el target como 'process type,N'. scope - `rwlock`, `mutex`, `processing` se pueden usar con el tipo de proceso y número (por ejemplo, `history syncer,1,processing`) o con todos los procesos de un tipo (por ejemplo, `history syncer,rwlock`).
`prof_disable[=<target>]`	Deshabilitar el perfilado. Afecta a todos los procesos si no se especifica target.	process type - todos los procesos del tipo especificado (por ejemplo, `history syncer`). Tipos de proceso admitidos como targets de perfilado: consulte `prof_enable`. process type,N - tipo de proceso y número (por ejemplo, `history syncer,1`). pid - identificador de proceso (`1` a `65535`). Para valores mayores, especifique el target como 'process type,N'.

Ejemplo de uso del control en tiempo de ejecución para recargar la caché de configuración del servidor:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reload

Ejemplos de uso del control en tiempo de ejecución para recargar la configuración del proxy:

# Recargar la configuración de todos los proxies:
zabbix_server -R proxy_config_cache_reload

# Recargar la configuración de Proxy1 y Proxy2:
zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2

Ejemplo de uso del control en tiempo de ejecución para limpiar la caché de historial de un elemento:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R history_cache_clear=42243

Ejemplos de uso del control en tiempo de ejecución para recopilar información de diagnóstico:

# Recopilar toda la información de diagnóstico disponible en el archivo de registro del servidor:
zabbix_server -R diaginfo

# Recopilar estadísticas de la caché de historial en el archivo de registro del servidor:
zabbix_server -R diaginfo=historycache

Ejemplo de uso del control en tiempo de ejecución para recargar la caché SNMP:

zabbix_server -R snmp_cache_reload

Cuando se actualiza una interfaz SNMPv3 a través de la interfaz web de Zabbix, Zabbix recargará automáticamente las nuevas credenciales SNMPv3 para esa interfaz en la mayoría de los casos; utilice -R snmp_cache_reload solo si la consulta sigue fallando después de los cambios de credenciales (por ejemplo, debido a inconsistencias de engineBoots/engineID o dispositivos que no cumplen con RFC), o cuando necesite forzar un borrado global de la caché SNMP para la resolución de problemas.

Ejemplo de uso del control en tiempo de ejecución para activar la ejecución del housekeeper:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_execute

Ejemplos de uso del control en tiempo de ejecución para cambiar el nivel de registro:

# Aumentar el nivel de registro de todos los procesos:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase

# Aumentar el nivel de registro del segundo proceso poller:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2

# Aumentar el nivel de registro del proceso con PID 1234:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234

# Disminuir el nivel de registro de todos los procesos http poller:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

Ejemplo de establecer el retardo de conmutación por error de HA al mínimo de 10 segundos:

zabbix_server -R ha_set_failover_delay=10s

Usuario del proceso

Zabbix server está diseñado para ejecutarse como un usuario no root. Se ejecutará como cualquier usuario no root con el que se inicie. Por lo tanto, puede ejecutar el server como cualquier usuario no root sin ningún problema.

Si intenta ejecutarlo como 'root', cambiará a un usuario 'zabbix' codificado de forma fija, que debe estar presente en su sistema. Solo puede ejecutar el server como 'root' si modifica el parámetro 'AllowRoot' en el archivo de configuración del server según corresponda.

Si Zabbix server y el agent se ejecutan en la misma máquina, se recomienda usar un usuario distinto para ejecutar el server y otro para ejecutar el agent. De lo contrario, si ambos se ejecutan con el mismo usuario, el agent puede acceder al archivo de configuración del server y cualquier usuario con nivel Admin en Zabbix puede recuperar con bastante facilidad, por ejemplo, la contraseña de la base de datos.

Archivo de configuración

Consulte las opciones del archivo de configuración para obtener más detalles sobre la configuración de zabbix_server.

Scripts de inicio

Los scripts se utilizan para iniciar/detener automáticamente los procesos de Zabbix durante el arranque/apagado del sistema. Los scripts se encuentran en el directorio misc/init.d.

Tipos de procesos y hilos del server

agent poller - proceso poller asíncrono para comprobaciones pasivas con un hilo de trabajo;
alert manager - gestor de la cola de alertas;
alert syncer - escritor de alertas en la base de datos;
alerter - proceso para enviar notificaciones;
availability manager - proceso para actualizar la disponibilidad del host;
browser poller - poller para comprobaciones de items de navegador;
configuration syncer - proceso para gestionar la caché en memoria de los datos de configuración;
configuration syncer worker - proceso para resolver y sincronizar los valores de macros de usuario en los nombres de item;
connector manager - proceso gestor de conectores;
connector worker - proceso para gestionar solicitudes del connector manager;
discovery manager - proceso gestor para el descubrimiento de dispositivos;
discovery worker - proceso para gestionar tareas de descubrimiento del discovery manager;
escalator - proceso para la escalada de acciones;
ha manager - proceso para gestionar la alta disponibilidad;
history poller - proceso para gestionar comprobaciones calculadas que requieren una conexión a la base de datos;
history syncer - escritor de history en la base de datos;
housekeeper - proceso para eliminar datos obsoletos (historial y tendencias de item, sesiones de usuario, eventos, etc.), así como los datos residuales de objetos eliminados;
http agent poller - proceso poller asíncrono para comprobaciones HTTP con un hilo de trabajo;
http poller - poller de monitorización web;
icmp pinger - poller para comprobaciones icmpping;
internal poller - poller para comprobaciones internas;
ipmi manager - gestor de pollers IPMI;
ipmi poller - poller para comprobaciones IPMI;
java poller - poller para comprobaciones Java;
lld manager - proceso gestor de tareas de descubrimiento de bajo nivel;
lld worker - proceso de trabajo de tareas de descubrimiento de bajo nivel;
odbc poller - poller para comprobaciones ODBC;
poller - poller normal para comprobaciones pasivas;
preprocessing manager - gestor de tareas de preprocesamiento con hilos de trabajo de preprocesamiento;
preprocessing worker - hilo para el preprocesamiento de datos;
proxy poller - poller para proxies pasivos;
proxy group manager - gestor del balanceo de carga y la alta disponibilidad de proxy;
report manager- gestor de tareas de generación de informes programados;
report writer - proceso para generar informes programados;
self-monitoring - proceso para recopilar estadísticas internas del server;
service manager - proceso para gestionar servicios mediante la recepción de información sobre problemas, etiquetas de problema y recuperación de problemas desde history syncer, task manager y alert manager;
snmp poller - proceso poller asíncrono para comprobaciones SNMP con un hilo de trabajo (walk[OID] y get[OID] items solo);
snmp trapper - trapper para traps SNMP;
task manager - proceso para la ejecución remota de tareas solicitadas por otros componentes (por ejemplo, cerrar un problema, reconocer un problema, comprobar ahora el valor de un item, funcionalidad de comando remoto);
timer - temporizador para procesar mantenimientos;
trapper - trapper para comprobaciones activas, traps y comunicación con proxy;
trigger housekeeper - proceso para eliminar problemas y eventos generados por triggers que posteriormente han sido eliminados;
unreachable poller - poller para dispositivos inalcanzables;
vmware collector - recopilador de datos de VMware responsable de obtener datos de los servicios de VMware.

El archivo de registro del server puede utilizarse para observar estos tipos de procesos.

El archivo de registro del server se crea con permisos de lectura y escritura solo para el propietario del archivo. Además, el archivo es legible por el grupo propietario. Se deniegan todos los demás permisos.

Se pueden supervisar varios tipos de procesos del server de Zabbix mediante el internal zabbix[process,<type>,<mode>,<state>] item.

Estadísticas de transacciones del history syncer

El título del proceso history syncer muestra estadísticas detalladas sobre las transacciones de history syncer:

205182 ?        S      0:00  zabbix_server: history syncer #2 [processed 0 values, 0+0 triggers in 0.000021 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]
205183 ?        S      0:00  zabbix_server: history syncer #3 [processed 18 values, 7+0 triggers in 0.002612 (0.001108,0.000000,0.000000,0.001208,0.000014) sec, idle 1 sec]
205184 ?        S      0:00  zabbix_server: history syncer #4 [processed 0 values, 0+0 triggers in 0.000027 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]

En "A+B triggers":

A - triggers procesados debido a valores de history;
B - triggers procesados debido a temporizadores.

Los tiempos, en processed...in N (<timings>) sec, son:

Tiempo dedicado a escribir los valores de item en la base de datos;
Tiempo dedicado a actualizar los datos del item (estado, errores, inventario del host, etc.);
Tiempo dedicado a vaciar los trends en la base de datos;
Tiempo dedicado a calcular triggers;
Tiempo dedicado a procesar eventos y acciones.

Procedimiento de housekeeping

El proceso housekeeper elimina periódicamente los datos obsoletos (historial y tendencias de item, sesiones de usuario, eventos, etc.), así como los datos que quedan tras eliminar objetos. Se ejecuta en ciclos, con una frecuencia y un límite de eliminación por ciclo determinados por HousekeepingFrequency y MaxHousekeeperDelete. Cualquier dato que no se elimine en un ciclo se переносa al siguiente. El housekeeping automático puede habilitarse y configurarse en Administration > Housekeeping.

Para eliminar los datos que quedan tras borrar objetos, el proceso housekeeper se basa en tareas de la tabla housekeeper, que se rellena cada vez que se elimina un objeto. Por ejemplo, cuando elimina un host, Zabbix también elimina sus items, pero no su historial, tendencias ni problemas. En su lugar, los triggers de base de datos rellenan la tabla housekeeper con tareas compuestas por estos campos:

housekeeperid - ID de la tarea
object - tipo de objeto (0 - item; 1 - trigger; 2 - servicio; 3 - host descubierto; 4 - servicio descubierto)
objectid - ID del objeto (ayuda a housekeeper a encontrar los datos relacionados con el objeto)

Por ejemplo, al eliminar un host con dos items y un trigger, la tabla housekeeper se rellena de la siguiente manera:

+---------------+--------+----------+
| housekeeperid | object | objectid |
+---------------+--------+----------+
|             1 |      1 |    28724 |
|             2 |      0 |    59396 |
|             3 |      0 |    59397 |
+---------------+--------+----------+

Los triggers de base de datos rellenan la tabla housekeeper sin comprobar si existen datos relacionados con el objeto; esa comprobación la realiza el proceso housekeeper.

Cada tarea da lugar a una o varias operaciones de housekeeper que dependen del tipo de objeto:

Para items (incluidas las reglas LLD) - elimina datos de todas las tablas de historial y tendencias (history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint) que contienen valores de esos items. Además, comprueba la tabla problems y elimina eventos internos obsoletos asociados a esos items.
Para triggers - comprueba las tablas relacionadas con eventos (problem, event_symptom, event_recovery, events) y elimina los eventos obsoletos asociados a esos triggers, además de notificar al proceso service manager sobre los eventos eliminados.

Un proceso independiente trigger housekeeper se encarga de una tarea más limitada: eliminar problemas y eventos que no tienen un trigger de origen conocido. Su frecuencia de ejecución está controlada por ProblemHousekeepingFrequency.

Hasta que se inicie el procedimiento de housekeeping de triggers, los problemas causados por triggers que desde entonces hayan sido eliminados podrían seguir generando problemas de servicio y asignándolos a servicios. Si su entorno incluye muchas reglas de cálculo de estado de servicio basadas en triggers descubiertos o no descubiertos con frecuencia, considere aumentar la frecuencia del procedimiento de housekeeping ajustando el parámetro de configuración del server ProblemHousekeepingFrequency.

Para servicios - comprueba la tabla problems y elimina eventos de servicio obsoletos, así como problemas de servicio obsoletos, resolviéndolos en el momento del housekeeping.
Para el descubrimiento de red - elimina eventos de descubrimiento obsoletos de la tabla problems.

El housekeeper elimina solo aquellos eventos que no están asociados con problemas. Por ejemplo, un evento obsoleto de problema/recuperación no se eliminará si está asociado a un problema abierto. Cuando el housekeeper elimina entidades obsoletas, primero elimina los problemas y después los eventos.

Las tablas que usan el modo partition (tablas particionadas de TimescaleDB) se omiten; solo se procesan las tablas que usan el modo regular.

Plataformas compatibles

Debido a los requisitos de seguridad y la naturaleza crítica de la operación del servidor, UNIX es el único sistema operativo que puede ofrecer de manera constante el rendimiento, la tolerancia a fallos y la resiliencia necesarios. Zabbix funciona en versiones líderes del mercado.

El servidor Zabbix se prueba en las siguientes plataformas:

Linux
Solaris
AIX
HP-UX
Mac OS X
FreeBSD
OpenBSD
NetBSD
SCO Open Server

Zabbix también puede funcionar en otros sistemas operativos similares a Unix.

Configuración regional

Tenga en cuenta que el servidor requiere una configuración regional UTF-8 para que algunos elementos de texto puedan interpretarse correctamente. La mayoría de los sistemas modernos similares a Unix tienen una configuración regional UTF-8 por defecto, sin embargo, hay algunos sistemas en los que esto puede necesitar configurarse específicamente.

What’s next?

1 Alta disponibilidad

Docs

1 Servidor

Overview