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. Después, aproximadamente una vez por minuto, Zabbix server consultará la tabla de items para obtener una lista de los items que están activos, la cual se almacena después en una caché dentro de Zabbix server. Por eso, los cambios realizados en el frontend de Zabbix pueden tardar hasta dos minutos en mostrarse 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 daemon. El servidor puede ser iniciado 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

Del mismo modo, para detener/reiniciar/ver el estado del servidor Zabbix, use 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 primer 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 separada 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 — limpiar las propiedades del motor SNMP (tiempo del motor, arranques del motor, ID del motor, credenciales) para todos los host. Úselo para forzar una limpieza 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. Hasta que se inicie el procedimiento de housekeeping de trigger, los problemas causados por triggers que hayan sido eliminados posteriormente aún podrían generar problemas de servicio y asignárselos a los servicios. Si su entorno incluye muchas reglas de cálculo de estado de servicios basadas en triggers descubiertos/no descubiertos con frecuencia, considere aumentar la frecuencia del procedimiento de housekeeping ajustando el parámetro de configuración del server `ProblemHousekeepingFrequency`.
`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`). Vea 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: vea `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

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

El servidor Zabbix está diseñado para ejecutarse como un usuario no root. Se ejecutará como sea cual sea el usuario no root con el que se inicie. Así que puede ejecutar el servidor como cualquier usuario no root sin ningún problema.

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

Si el servidor y el agente Zabbix se ejecutan en la misma máquina, se recomienda utilizar un usuario diferente para ejecutar el servidor que para ejecutar el agente. De lo contrario, si ambos se ejecutan como el mismo usuario, el agente puede acceder al archivo de configuración del servidor y a cualquier usuario de nivel de administrador en Zabbix podría recuperar fácilmente, 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.

Guiones de inicio

Los scripts se utilizan para iniciar/detener automáticamente los procesos de Zabbix durante encendido/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 la base de datos de alertas;
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 la base de datos de historial;
housekeeper - proceso para eliminar datos obsoletos (historial y tendencias de item, sesiones de usuario, eventos, etc.), así como 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 proxies;
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] 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 la obtención de datos de servicios de VMware.

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

Desde Zabbix 7.4.6, el archivo de log 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.

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

Estadísticas de transacciones del sincronizador de historial

El título del proceso del sincronizador de historial muestra estadísticas detalladas sobre las transacciones del sincronizador de historial:

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 historial;
B - triggers procesados debido a temporizadores.

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

Tiempo empleado escribiendo valores de item en la base de datos;
Tiempo empleado actualizando datos del item (estado, errores, inventario del host, etc.);
Tiempo empleado vaciando tendencias en la base de datos;
Tiempo empleado calculando triggers;
Tiempo empleado procesando eventos y acciones.

Plataformas compatibles

Debido a los requisitos de seguridad y la naturaleza de misión crítica de la operativa del servidor, UNIX es el único sistema operativo que puede ofrecer el rendimiento consistentemente, la tolerancia a fallos y la resiliencia necesarios. Zabbix opera 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 puede funcionar en otros sistemas operativos similares a Unix igual de bien.

Configuración regional

Tenga en cuenta que el servidor requiere una configuración regional UTF-8 para que algunas métricas de texto se puedan interpretar correctamente. La mayoría de los sistemas modernos tipo Unix tienen la configuración regional UTF-8 como predeterminada, sin embargo, hay algunos sistemas en los que es posible que sea necesario configurarla específicamente.

What’s next?

1 Clúster de alta disponibilidad

Docs

1 Servidor

Resumen