El servidor Zabbix es el proceso central del software Zabbix.
El servidor realiza el sondeo y captura de datos, calcula los iniciadores y envía notificaciones a los usuarios. Es el componente central al que los agentes y servidores proxy de Zabbix informan datos sobre la disponibilidad e integridad de los sistemas. El servidor puede comprobar de forma remota los servicios en red (como servidores web y servidores de correo) mediante comprobaciones de servicio sencillas.
El servidor es el repositorio central en el que se almacenan todos los datos de configuración, estadísticos y operativos, y es la entidad en Zabbix que alertará activamente a los administradores cuando surjan problemas en cualquiera de los sistemas monitoreados.
El funcionamiento de un servidor Zabbix básico se divide en tres componentes distintos: servidor Zabbix, interfaz 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 servidor como la interfaz web. Por ejemplo, cuando creas una nueva métrica usando la interfaz web (o API), esta 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, que luego se almacena en un caché dentro del servidor Zabbix. Este es el motivo por el cual los cambios realizados en la interfaz de Zabbix pueden tardar hasta dos minutos en aparecer en la sección de datos más recientes.
El servidor Zabbix se ejecuta como un proceso daemon. El servidor puede ser iniciado ejecutando:
Esto funcionará en la mayoría de los sistemas GNU/Linux. En otros sistemas, puede que necesite ejecutar:
Del mismo modo, para detener/reiniciar/ver el estado del servidor Zabbix, use los siguientes comandos:
Si lo anterior no funciona, debe iniciarlo manualmente. Encuentre la ruta al binario zabbix_server y ejecute:
Puede usar los siguientes parámetros de línea de comando con el servidor Zabbix:
-c --config <archivo> ruta al archivo de configuración (el predeterminado es /usr/local/etc/zabbix_server.conf)
-f --foreground ejecuta el server Zabbix en primer plano
-R --runtime-control <opción> ejecuta funciones administrativas
-T --test-config. valida el archivo de configuración y sale
-h --help ofrece esta ayuda
-V --version muestra el número de versión
Ejemplos de ejecución del servidor Zabbix con parámetros de línea de comandos:
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 historial para el elemento especificado por su ID. Afecta a todos los valores del elemento, excepto el primer y último valor. |
destino - ID del elemento |
diaginfo[=<sección>] | Recopilar información de diagnóstico en el archivo de registro del servidor. | 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=destino | Eliminar el nodo de alta disponibilidad (HA) especificado por su nombre o ID. Tenga en cuenta que los nodos activo/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, borrar las propiedades SNMP (engine time, engine boots, engine id, credenciales) para todos los hosts. | |
housekeeper_execute | Iniciar el procedimiento de mantenimiento. Se ignora si el procedimiento de mantenimiento está 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á en curso. |
|
log_level_increase[=<destino>] | Aumentar el nivel de registro, afecta a todos los procesos si no se especifica destino. No es compatible en sistemas BSD. |
tipo de proceso - Todos los procesos del tipo especificado (por ejemplo, poller) Consulte 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 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 es compatible 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 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 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 destino como 'tipo de proceso,N'. ámbito - rwlock , mutex , processing se pueden usar con el tipo de proceso y número (por ejemplo, history syncer,1,processing) o todos los procesos de un 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 compatibles 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 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:
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:
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:
Ejemplo de uso del control en tiempo de ejecución para activar la ejecución del housekeeper:
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:
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.
Consulte el archivo de configuración opciones para obtener detalles sobre la configuración de zabbix_proxy.
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.
agent poller
- proceso de sondeo asíncrono para comprobaciones pasivas con un subproceso de trabajoalert manager
- gestor de la cola de alertasalert syncer
- escritor de alertas en la base de datosalerter
- proceso para el envío de notificacionesavailability manager
- proceso para actualizaciones de disponibilidad de equiposbrowser poller
- sondeador para comprobaciones de elementos de navegadorconfiguration syncer
- proceso para gestionar la caché en memoria de los datos de configuraciónconfiguration syncer worker
- proceso para resolver y sincronizar valores de macros de usuario en nombres de elementosconnector manager
- proceso gestor de conectoresconnector worker
- proceso para gestionar solicitudes del gestor de conectoresdiscovery manager
- proceso gestor para el descubrimiento de dispositivosdiscovery worker
- proceso para gestionar tareas de descubrimiento del gestor de descubrimientoescalator
- proceso para la escalada de accionesha manager
- proceso para la gestión de alta disponibilidadhistory poller
- proceso para gestionar comprobaciones calculadas que requieren conexión a la base de datoshistory syncer
- escritor de historial en la base de datoshousekeeper
- proceso para la eliminación de datos históricos antiguoshttp agent poller
- proceso de sondeo asíncrono para comprobaciones HTTP con un subproceso de trabajohttp poller
- sondeador para monitorización webicmp pinger
- sondeador para comprobaciones icmppinginternal poller
- sondeador para comprobaciones internasipmi manager
- gestor de sondeadores IPMIipmi poller
- sondeador para comprobaciones IPMIjava poller
- sondeador para comprobaciones Javalld manager
- proceso gestor de tareas de descubrimiento de bajo nivellld worker
- proceso de trabajo de tareas de descubrimiento de bajo nivelodbc poller
- sondeador para comprobaciones ODBCpoller
- sondeador normal para comprobaciones pasivaspreprocessing manager
- gestor de tareas de preprocesamiento con subprocesos de trabajo de preprocesamientopreprocessing worker
- subproceso para el preprocesamiento de datosproxy poller
- sondeador para proxies pasivosproxy group manager
- gestor de balanceo de carga y alta disponibilidad de proxiesreport manager
- gestor de tareas de generación de informes programadosreport writer
- proceso para generar informes programadosself-monitoring
- proceso para recopilar estadísticas internas del servidorservice manager
- proceso para gestionar servicios recibiendo información sobre problemas, etiquetas de problemas y recuperación de problemas desde history syncer, task manager y alert managersnmp poller
- proceso de sondeo asíncrono para comprobaciones SNMP con un subproceso de trabajo (solo elementos walk[OID]
y get[OID]
)snmp trapper
- receptor de traps SNMPtask manager
- proceso para la ejecución remota de tareas solicitadas por otros componentes (por ejemplo, cerrar problema, reconocer problema, comprobar valor de elemento ahora, funcionalidad de comando remoto)timer
- temporizador para el procesamiento de mantenimientostrapper
- receptor para comprobaciones activas, traps, comunicación con proxiestrigger housekeeper
- proceso para eliminar problemas generados por disparadores que han sido eliminadosunreachable poller
- sondeador para dispositivos inalcanzablesvmware collector
- recolector de datos VMware responsable de recopilar datos de servicios VMwareEl archivo de registro del servidor puede utilizarse para observar estos tipos de procesos.
Se pueden monitorizar varios tipos de procesos del servidor Zabbix utilizando el elemento interno zabbix[process,<tipo>,<modo>,<estado>]
item.
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":
Los tiempos, en "processed...in N (<timings>) sec", son:
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:
Zabbix puede funcionar en otros sistemas operativos similares a Unix igual de bien.
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.