Se encuentra viendo la documentación de la versión en desarrollo, puede estar incompleta.
Únase a nuestro proyecto de traducción y ayude a traducir la documentación de Zabbix a su lengua materna.

1 Servidor

Visión general

El servidor Zabbix es el proceso central del software Zabbix.

El servidor realiza el sondeo y captura de datos, calcula los iniciadores, envía notificaciones a los usuarios. Es el componente central al que los agentes y proxies de Zabbix reportan datos sobre disponibilidad e integridad de los sistemas. El servidor puede comprobar remotamente servicios en red (como servidores web y servidores de correo) usando una comprobación simple de servicio.

El servidor es el repositorio central en el que se almacena toda la configuración, los 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 monitoreados.

El funcionamiento básico de un servidor Zabbix se divide en tres componentes distintos; que son: 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 crea una nueva métrica usando 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 que serán almacenadas en una caché dentro del servidor Zabbix. Este es el motivo por el que cualquier cambio realizado en la interfaz web de Zabbix puede demorar hasta dos minutos para aparecer en la sección de últimos datos.

Ejecutando el servidor

Si se instala como paquete

El servidor Zabbix se ejecuta como un proceso daemon. El servidor puede ser iniciado ejecutando:

service zabbix-server start

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:

service zabbix-server stop
       service zabbix-server restart
       service zabbix-server status
Iniciar manualmente

Si lo anterior no funciona, debe iniciarlo manualmente. Encuentre la ruta al binario zabbix_server y ejecute:

zabbix_server

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:

zabbix_server -c /usr/local/etc/zabbix_server.conf
       zabbix_server --help
       zabbix_server -V
Control en tiempo de ejecución

Opciones de control en tiempo de ejecución:

Opción Descripción Objetivo
config_cache_reload Recargar caché de configuración. Se ignora si el caché se está cargando actualmente.
diaginfo[=<section>] Recopila información de diagnóstico en el archivo de registro del servidor. historycache - estadísticas de caché de historial
valuecache - estadísticas de caché de valores
* *preprocesamiento - estadísticas del administrador de preprocesamiento
alerting - estadísticas del administrador de alertas
lld - estadísticas del administrador LLD
bloqueos - lista de mutex (está vacía en Sistemas BSD)
conector**: 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 se pueden eliminar.
destino - nombre o ID del nodo (se puede obtener ejecutando ha_status)
ha_set_failover_delay=delay Establecer retraso de conmutación por error de alta disponibilidad (HA).
Se admiten sufijos de tiempo, p. 10s, 1m.
proxy_config_cache_reload[=<target>] Recargar caché de configuración de proxy. target - lista delimitada por comas de nombres de proxy
Si no se especifica ningún destino, recarga la configuración para todos los proxies
secrets_reload Recargar secretos desde Vault.
service_cache_reload Recargar la caché del administrador de servicios.
snmp_cache_reload Vuelva a cargar la caché SNMP, borre las propiedades SNMP (hora del motor, arranque del motor, identificación del motor, credenciales) para todos los equipos.
housekeeper_execute Iniciar el procedimiento de limpieza. Ignorado si el procedimiento de limpieza está actualmente en curso.
trigger_housekeeper_execute Iniciar el procedimiento de limpieza del disparador. Se ignora si el procedimiento de limpieza del activador está actualmente en curso.
log_level_increase[=<target>] Aumenta el nivel de registro, afecta a todos los procesos si no se especifica el objetivo.
No se admite en sistemas BSD.
tipo de proceso - Todos los procesos del tipo especificado (por ejemplo, listener)
Ver todos los tipos de procesos del servidor.
tipo de proceso,N - Tipo y número de proceso (por ejemplo, sondeador,3)< br>pid - Identificador de proceso (1 a 65535). Para valores mayores, especifique el destino como 'tipo de proceso,N'.
log_level_decrease[=<target>] Disminuye el nivel de registro, afecta a todos los procesos si no se especifica el objetivo.
No se admite en sistemas BSD.
prof_enable[=<target>] Habilitar creación de perfilado.
Afecta a todos los procesos si no se especifica el destino.
La creación del perfilado habilitada proporciona detalles de todos los rwlocks/mutexes por nombre de función.
* *tipo de proceso: todos los procesos del tipo especificado (por ejemplo, sincronizador de historial)
Tipos de procesos admitidos como objetivos de creación 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 y número de proceso (por ejemplo, sincronizador de historial,1)
pid: identificador de proceso (de 1 a 65535). Para valores más grandes, especifique el destino como 'tipo de proceso, N'.
alcance** - rwlock, mutex, processing se pueden usar con el tipo y número de proceso (por ejemplo, sincronizador de historial, 1, procesamiento) o todos los procesos de tipo (por ejemplo, sincronizador de historial, rwlock)
prof_disable[=<target>] Deshabilitar la creación de perfiles.
Afecta a todos los procesos si no se especifica el objetivo.
tipo de proceso - Todos los procesos del tipo especificado (por ejemplo, sincronizador de historial)
Tipos de procesos admitidos como objetivos de creación de perfiles: consulte prof_enable
tipo de proceso,N - Tipo y número de proceso (p. ej., sincronizador de historial,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

Ejemplos de uso del control en tiempo de ejecución para recopilar información de diagnóstico:

# Recopile toda la información de diagnóstico disponible en el archivo de registro del servidor:
       zabbix_server -R diaginfo
       
       # Recopile estadísticas de caché del 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 desencadenar la ejecución de las tareas de limpieza:

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:

# Incrementar el nivel de registro de todos los procesos:
       zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase
       
       # Incrementar el nivel de registro del segundo proceso de sondeo:
       zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2
       
       # Incrementar 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 del poller http:
       zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

Ejemplo de configuración del retraso 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 el archivo de configuración opciones para obtener detalles sobre la configuración de zabbix_proxy.

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 hebras del servidor

  • agent poller - proceso de encuestador asíncrono para comprobaciones pasivas con un hilo de trabajador
  • alert manager - administrador de colas de alertas
  • alert syncer - escritor de alertas en base de datos
  • alerter - proceso para enviar notificaciones
  • availability manager: proceso para actualizaciones de disponibilidad del host
  • configuration syncer: proceso para gestionar la caché en memoria de 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 de administrador para conectores
  • connector worker: proceso para manejar solicitudes del administrador del conector
  • discovery manager - proceso de administrador para el descubrimiento de dispositivos
  • discovery worker - Proceso para manejar tareas de descubrimiento desde el administrador de descubrimiento.
  • escalator - proceso para escalar acciones
  • ha manager: proceso para gestionar la alta disponibilidad
  • history poller: proceso para manejar cheques calculados que requieren una conexión a la base de datos
  • history syncer - escritor de historial en base de datos
  • housekeeper: proceso para eliminar datos históricos antiguos
  • http agent poller - proceso de sondeo asíncrono para comprobaciones HTTP con un subproceso de trabajo
  • http poller - sondeador de monitoreo web
  • icmp pinger - sondeador para comprobaciones de icmpping
  • ipmi manager - administrador de encuestadores IPMI
  • ipmi poller - sondeador para comprobaciones de IPMI
  • java poller - sondeador para comprobaciones de Java
  • lld manager: proceso de gestión 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 - administrador de tareas de preprocesamiento
  • preprocessing worker - proceso para el preprocesamiento de datos
  • proxy poller - sondeador para proxies pasivos
  • proxy group manager - gestor de balanceo de carga proxy y alta disponibilidad
  • report manager: proceso para generar informes programados
  • report writer - proceso para generar informes programados
  • self-monitoring: proceso para recopilar estadísticas internas del servidor
  • service manager: proceso para gestionar servicios mediante la recepción de información sobre problemas, etiquetas de problemas y recuperación de problemas desde el sincronizador de historial, el administrador de tareas y el administrador de alertas
  • 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 - capturador para capturas SNMP
  • task manager - proceso para la ejecución remota de tareas solicitadas por otros componentes (por ejemplo, cerrar el problema, reconocer el problema, verificar valor de la métrica ahora, funcionalidad de comando remoto)
  • timer - temporizador para procesar mantenimientos
  • trapper - capturador para comprobaciones activas, capturas y comunicación proxy
  • trigger housekeeper- proceso para eliminar problemas generados por iniciadores que han sido eliminados
  • unreachable poller - sondeador para dispositivos inalcanzables
  • vmware collector- recopilador de datos de VMware responsable de la recopilación de datos de servicios de VMware

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

Se pueden monitorear varios tipos de procesos del servidor Zabbix usando la métrica interna zabbix[process,<tipo>,<modo>,<estado>] .

Plataformas compatibles

Debido a los requisitos de seguridad y la naturaleza de misión crítica del servidor operación, UNIX es el único sistema operativo que puede consistentemente ofrecer el rendimiento, 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
  • Tru64/OSF1

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.