Se encuentra viendo la documentación de la versión en desarrollo, puede estar incompleta.
Esta página fue traducida automáticamente. Si detectas un error, selecciónalo y presiona Ctrl+Enter para informarlo a los editores.

1 Servidor

Descripción general

El servidor Zabbix es el proceso central del software Zabbix.

El servidor realiza la recopilación y captura de datos, calcula disparadores, envía notificaciones a los usuarios. Es el componente central al que los agentes y proxies de Zabbix informan datos 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 servicio 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 una nueva métrica utilizando la interfaz web (o API), se agrega a la tabla de métricas en la base de datos. Luego, aproximadamente una vez por minuto, el servidor Zabbix consultará la tabla de métricas para obtener una lista de las métricas que están activas y que luego se almacenan en una caché dentro del servidor Zabbix. Por eso puede tardar hasta dos minutos para que cualquier cambio realizado en la interfaz de Zabbix aparezca en la sección de últimos datos.

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:

Opción Descripción Destino
config_cache_reload Recargar la caché de configuración. Se ignora si la caché se está cargando actualmente.
history_cache_clear=destino Limpiar la caché de histórico para la métrica especificada por su ID.
Afecta a todos los valores de la métrica, excepto el primer y último valor.
destino - ID de la métrica
diaginfo[=<sección>] Recopilar información de diagnóstico en el archivo de registro del servidor. historycache - estadísticas de la caché de histórico
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=destino Eliminar el nodo de alta disponibilidad (HA) especificado por su nombre o ID.
Tenga en cuenta que los nodos activos/en espera no se pueden eliminar.
destino - nombre o ID del nodo (se puede obtener ejecutando ha_status)
ha_set_failover_delay=retardo 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[=<destino>] Recargar la caché de configuración del proxy. destino - lista de nombres de proxy separados por comas
Si no se especifica destino, se recarga 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, limpiar las propiedades SNMP (engine time, engine boots, engine id, credenciales) para todos los equipos.
housekeeper_execute Iniciar el procedimiento de mantenimiento.
Se ignora si el procedimiento de mantenimiento está actualmente en curso.
trigger_housekeeper_execute Iniciar el procedimiento de mantenimiento de disparadores para servicios para eliminar problemas causados por disparadores que han sido eliminados, incluidos los problemas de servicio generados por dichos problemas (considerados como resueltos en el momento del mantenimiento).
Tenga en cuenta que, hasta que se inicie el procedimiento de mantenimiento, los problemas causados por disparadores 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 disparadores descubiertos/no descubiertos con frecuencia, considere aumentar la frecuencia del procedimiento de mantenimiento de disparadores ajustando el parámetro de configuración del servidor ProblemHousekeepingFrequency.

Se ignora si el procedimiento de mantenimiento de disparadores está actualmente en curso.
log_level_increase[=<destino>] Aumentar el nivel de registro, afecta a todos los procesos si no se especifica destino.
No soportado en sistemas BSD.
tipo de proceso - Todos los procesos del tipo especificado (por ejemplo, poller)
Vea todos los tipos de procesos del servidor.
tipo de proceso,N - Tipo de proceso y número (por ejemplo, poller,3)
pid - Identificador de proceso (1 a 65535). Para valores mayores especifique el destino como 'tipo de proceso,N'.
log_level_decrease[=<destino>] Disminuir el nivel de registro, afecta a todos los procesos si no se especifica destino.
No soportado en sistemas BSD.
prof_enable[=<destino>] Habilitar el perfilado.
Afecta a todos los procesos si no se especifica destino.
El perfilado habilitado proporciona detalles de todos los rwlocks/mutexes por nombre de función.
tipo de proceso - Todos los procesos del tipo especificado (por ejemplo, history syncer)
Tipos de proceso soportados 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
tipo de proceso,N - Tipo de proceso y número (por ejemplo, history syncer,1)
pid - Identificador de proceso (1 a 65535). Para valores mayores especifique el destino como 'tipo de proceso,N'.
scope - rwlock, mutex, processing pueden usarse con el tipo de proceso y número (por ejemplo, history syncer,1,processing) o todos los procesos del tipo (por ejemplo, history syncer,rwlock)
prof_disable[=<destino>] Deshabilitar el perfilado.
Afecta a todos los procesos si no se especifica destino.
tipo de proceso - Todos los procesos del tipo especificado (por ejemplo, history syncer)
Tipos de proceso soportados como destinos de perfilado: ver prof_enable
tipo de proceso,N - Tipo de proceso y número (por ejemplo, history syncer,1)
pid - Identificador de proceso (1 a 65535). Para valores mayores especifique el destino como 'tipo de proceso,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 una métrica:

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 sin privilegios de root. Se ejecutará como cualquier usuario sin privilegios de root con el que se inicie. Por lo tanto, puede ejecutar el servidor como cualquier usuario sin privilegios de root sin ningún problema.

Si intenta ejecutarlo como 'root', cambiará a un usuario 'zabbix' predefinido, 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 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 inicio/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 equipos
  • browser poller - sondeador para comprobaciones de métricas 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 nombres de métricas
  • 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 gestor de descubrimiento
  • 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 la eliminación de datos históricos antiguos
  • http agent poller - proceso de sondeo asíncrono para comprobaciones HTTP con un subproceso de trabajo
  • http poller - sondeador de 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 métricas walk[OID] y get[OID])
  • snmp trapper - receptor de 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 métrica ahora, funcionalidad de comando remoto)
  • timer - temporizador para el procesamiento de mantenimientos
  • trapper - receptor para comprobaciones activas, traps, comunicación con proxies
  • trigger housekeeper - proceso para eliminar problemas generados por disparadores que han sido eliminados
  • unreachable poller - sondeador para dispositivos inaccesibles
  • vmware collector - recolector de datos de VMware responsable de recopilar datos de servicios VMware

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

Se pueden monitorizar varios tipos de procesos del servidor Zabbix utilizando la métrica interna zabbix[process,<type>,<mode>,<state>] métrica.

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.

Plataformas soportadas

Debido a los requisitos de seguridad y la naturaleza crítica de la operación de servidores, UNIX es el único sistema operativo que puede ofrecer de manera consistente el rendimiento, tolerancia a fallos y 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 también puede funcionar en otros sistemas operativos tipo Unix.

Configuración regional

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