El servidor realiza la recopilación y captura de datos, calcula disparadores 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 servidor puede comprobar remotamente los servicios en red (como servidores web y servidores de correo) utilizando comprobaciones de servicios simples.

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

El funcionamiento de un servidor Zabbix básico se divide en tres componentes distintos; estos son: servidor Zabbix, interfaz web y almacenamiento en 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 servidor como la interfaz web. Por ejemplo, cuando crea un nuevo elemento utilizando la interfaz web (o la API), se añade a la tabla de elementos en la base de datos. Luego, aproximadamente una vez por minuto, el servidor Zabbix consultará la tabla de elementos para obtener una lista de los elementos que están activos, que luego se almacena en una caché dentro del servidor Zabbix. Por eso puede tardar hasta dos minutos en que los cambios realizados en la interfaz de Zabbix aparezcan 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 al binario zabbix_server y ejecute:

zabbix_server

Puede utilizar los siguientes parámetros de línea de comandos con el servidor Zabbix:

-c --config <archivo>              ruta al archivo de configuración (por defecto es /usr/local/etc/zabbix_server.conf)
-f --foreground                    ejecutar el servidor Zabbix en primer plano
-R --runtime-control <opción>      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 del servidor Zabbix 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 tiempo de ejecución

Opciones de control de tiempo 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	Borrar la caché de historial del item especificado por su ID. Afecta a todos los valores del item, excepto el primero y el último.	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 los nodos activos/en espera no pueden eliminarse.	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 separados por comas Si no se especifica ningún target, se recargará la configuración de todos los proxies
secrets_reload	Recargar 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, reinicios del motor, ID del motor, credenciales) para todos los hosts. Úselo para forzar una limpieza global de la caché al solucionar problemas de SNMP.
housekeeper_execute	Iniciar el procedimiento de limpieza. Se ignora si el procedimiento de limpieza está actualmente en curso.
trigger_housekeeper_execute	Iniciar el procedimiento de limpieza de trigger. Se ignora si el procedimiento de limpieza de trigger está actualmente en curso.
log_level_increase[=<target>]	Aumentar el nivel de registro; afecta a todos los procesos si no se especifica target. No es compatible con sistemas BSD.	process type - Todos los procesos del tipo especificado (por ejemplo, poller) Vea todos los tipos de proceso del server. process type,N - Tipo y número de proceso (por ejemplo, poller,3) pid - Identificador de proceso (1 a 65535). Para valores mayores, especifique 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 es 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 compatibles como destinos 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 y número de proceso (por ejemplo, history syncer,1) pid - Identificador de proceso (1 a 65535). Para valores mayores, especifique target como 'process type,N'. scope - `rwlock`, `mutex`, `processing` pueden usarse con el tipo y número de proceso (por ejemplo, history syncer,1,processing) o con todos los procesos del 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 compatibles como destinos de perfilado: vea `prof_enable` process type,N - Tipo y número de proceso (por ejemplo, history syncer,1) pid - Identificador de proceso (1 a 65535). Para valores mayores, especifique 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 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 subprocesos del servidor

agent poller - proceso de sondeo asíncrono para comprobaciones pasivas con un subproceso de trabajo
alert manager - gestor de la cola de alertas
alert syncer - escritor de alertas en la base de datos
alerter - proceso para el envío de notificaciones
availability manager - proceso para actualizaciones de disponibilidad de host
browser poller - sondeador 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 valores de macros de usuario en los nombres de items
connector manager - proceso gestor de conectores
connector worker - proceso para gestionar solicitudes del gestor de conectores
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 la gestión de alta disponibilidad
history poller - proceso para gestionar comprobaciones calculadas que requieren conexión a la base de datos
history syncer - escritor de histórico en la base de datos
housekeeper - proceso para eliminar datos obsoletos (histórico y tendencias de items, sesiones de usuario, eventos, etc.), así como datos dejados por objetos eliminados
http agent poller - proceso de sondeo asíncrono para comprobaciones HTTP con un subproceso de trabajo
http poller - sondeador para monitorización web
icmp pinger - sondeador para comprobaciones icmpping
internal poller - sondeador para comprobaciones internas
ipmi manager - gestor de sondeadores IPMI
ipmi poller - sondeador para comprobaciones IPMI
java poller - sondeador 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 - sondeador para comprobaciones ODBC
poller - sondeador normal para comprobaciones pasivas
preprocessing manager - gestor de tareas de preprocesamiento con subprocesos de trabajo de preprocesamiento
preprocessing worker - subproceso para el preprocesamiento de datos
proxy poller - sondeador para proxies pasivos
proxy group manager - gestor de balanceo de carga y alta disponibilidad de proxies
report manager- gestor de tareas de generación de informes programados
report writer - proceso para la generación de informes programados
self-monitoring - proceso para recopilar estadísticas internas del servidor
service manager - proceso para la gestión de servicios recibiendo información sobre problemas, etiquetas de problemas y recuperación de problemas desde history syncer, task manager y alert manager
snmp poller - proceso de sondeo asíncrono para comprobaciones SNMP con un subproceso de trabajo (solo items walk[OID] y get[OID])
snmp trapper - trapper para traps SNMP
task manager - proceso para la ejecución remota de tareas solicitadas por otros componentes (por ejemplo, cerrar problema, reconocer problema, comprobar valor de item ahora, funcionalidad de comando remoto)
timer - temporizador para el procesamiento de mantenimientos
trapper - trapper para comprobaciones activas, traps, comunicación con proxy
trigger housekeeper - proceso para eliminar problemas y eventos generados por triggers que han sido eliminados
unreachable poller - sondeador para dispositivos inalcanzables
vmware collector - recolector de datos de VMware responsable de recopilar datos de servicios VMware

El archivo de log del servidor puede utilizarse para observar estos tipos de procesos.

El archivo de log del servidor se crea con permisos de lectura y escritura solo para el propietario del archivo. Además, el archivo es legible por el grupo propietario. Todos los demás permisos están denegados.

Se pueden monitorizar varios tipos de procesos del servidor Zabbix utilizando el item interno zabbix[process,<type>,<mode>,<state>].

Estadísticas de transacciones del history syncer

El título del proceso history syncer muestra estadísticas detalladas sobre las transacciones del 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 - disparadores procesados debido a valores históricos;
B - disparadores procesados debido a temporizadores.

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

Tiempo dedicado a escribir valores de métricas en la base de datos;
Tiempo dedicado a actualizar datos de métricas (estado, errores, inventario de equipos, etc);
Tiempo dedicado a volcar tendencias a la base de datos;
Tiempo dedicado a calcular disparadores;
Tiempo dedicado a procesar eventos y acciones.

Procedimiento de housekeeping

El proceso housekeeper elimina periódicamente datos obsoletos (histórico y tendencias de items, sesiones de usuario, eventos, etc.), así como datos dejados por objetos eliminados. Se ejecuta en ciclos, con una frecuencia y un límite de eliminación por ciclo determinados por HousekeepingFrequency y MaxHousekeeperDelete. Cualquier dato no eliminado en un ciclo se traslada al siguiente. El housekeeping automático puede habilitarse y configurarse en Administración > Housekeeping.

Para eliminar los datos dejados por objetos eliminados, el proceso housekeeper se basa en tareas de la tabla housekeeper, que se rellena cada vez que se elimina un objeto. Por ejemplo, cuando se elimina un host, Zabbix también elimina sus items, pero no su histórico, tendencias o problemas. En su lugar, los triggers de la base de datos rellenan la tabla housekeeper con tareas que constan de 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 al housekeeper a encontrar los datos relacionados con el objeto)

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

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

Los triggers de la 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 housekeeper que dependen del tipo de objeto:

Para items (incluidas reglas LLD): elimina los datos de todas las tablas de histórico y tendencias (history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint) que contengan valores para esos items. Además, comprueba la tabla problems y elimina los 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, y también notifica al proceso service manager sobre los eventos eliminados.

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

Hasta que se inicie el procedimiento de housekeeping de triggers, los problemas causados por triggers que hayan sido eliminados pueden seguir generando problemas de servicio y asignándolos a servicios. Si su configuración implica muchas reglas de cálculo de estado de servicio basadas en triggers descubiertos/no descubiertos con frecuencia, considere aumentar la frecuencia del procedimiento de housekeeping ajustando el parámetro de configuración del servidor ProblemHousekeepingFrequency.

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

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

Las tablas que utilizan el modo partition (tablas particionadas de TimescaleDB) se omiten; sólo se procesan las tablas que utilizan 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

Descripción general