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 agent y proxy de Zabbix informan sobre la disponibilidad e integridad de los sistemas. El server 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 server básico de Zabbix 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 items de la base de datos. Después, aproximadamente una vez por minuto, Zabbix server consultará la tabla items para obtener una lista de los items activos, que luego 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 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 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 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.
`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 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: limpia 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 ya se hayan eliminado podrían seguir generando problemas de servicio y asignándolos 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 es 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 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 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

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 en 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

El servidor Zabbix está diseñado para ejecutarse como un usuario que no sea root. Se ejecutará como cualquier usuario que no sea root con el que se inicie. Por lo tanto, puede ejecutar el servidor como cualquier usuario que no sea 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 el parámetro 'AllowRoot' en el archivo de configuración del servidor en consecuencia.

Si el servidor Zabbix y el agente 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 cualquier usuario con nivel de Administrador en Zabbix puede 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.

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 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 history;
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 proxy;
report manager- gestor de tareas de generación programada de informes;
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 (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 el valor de item ahora, 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 VMware.

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

Desde Zabbix 7.0.22, 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.

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

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 las 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 Clúster de alta disponibilidad

Docs

1 Servidor

Resumen