tecnología

Los artículos que hablan de la tecnología que utilizamos. En síntesis, lo referente a Zabbix y Grafana mas las cosas que podemos ir integrando como firewall sensores etc.

Zabbix Agent, módulos y sus usos.

Los Módulos en el Zabbix Agent ofrecen una funcionalidad extendida, pensada para mejorar el rendimiento.

En otras palabras, adaptar Zabbix a nuestras necesidades y monitorear exactamente lo que queremos.

Zabbix-agent-programador_zabbix

En Zabbix Agent ya existen algunas utilidades que contribuyen a esto:

  • Userparameters (métricas de Zabbix Agent, que utilizan Items)
  • External checks (métricas en las que no se utiliza el Zabbix Agent, por ejemplo, chequeos por SNMP)
  • El Item system.run[] de Zabbix Agent (permite ejecutar determinado comando en el Host)

Normalmente, éstas funcionalidades son muy eficaces, pero tenemos que tener en cuenta que, Zabbix va a inicar un nuevo proceso por cada métrica que necesita ejecutar.

Esto puede bajar mucho el rendimiento de Zabbix, si tenemos muchos comandos, scripts pesados o sistemas embebidos (embedded systems, diseñados para realizar funciones en específico).

Un Módulo permite extender las funcionalidades de Zabbix sin sacrificar el rendimiento del Zabbix Server o Zabbix Proxy.

Pueden implementarse con todo tipo de lógica y son librerías compartidas utilizadas por el proceso de Zabbix que inician junto con el servicio de Zabbix.

Sin embargo, lo más importante es que permite el desarrollo.

Es decir, se pueden desarrollar, compartir y usar estos módulos.

API de Módulos en Zabbix

Con el objetivo de hacer que una librería compartida sea considerada un Módulo en Zabbix, deberán implementarse y exportarse varias funciones.

Actualmente hay seis funciones en la API de Módulos de Zabbix y obligatoriamente se debe definir la versión de la API, mientras el resto de las interfaces son opcionales.

Versión (Obligatoria)

int	zbx_module_api_version(void);

Esta función devolverá la versión implementada en el módulo.

Inicialización (Opcional)

int	zbx_module_init(void);

Realizará lo necesario para la inicialización del módulo, Devolverá OK / FAIL según el resultado, en el caso de que Zabbix no inicie.

Lista de Items (Opcional)

ZBX_METRIC	*zbx_module_item_list(void);

Retornará la lista de Items soportados por el módulo. Cada uno está definido en una estructura de tipo ZBX_METRIC, y el valor de la «key» por defecto es NULL.

Configuración del Timeout (Opcional)

void	zbx_module_item_timeout(int timeout);

Si el módulo exporta zbx_module_item_list(), esta función es utilizada por Zabbix para especificar las configuraciones del Timeout en el archivo de configuración de Zabbix, el cual será respetado por los chequeos especificados en el módulo.

Callback de funciones (Opcional)

ZBX_HISTORY_WRITE_CBS	zbx_module_history_write_cbs(void);

Esta función retornará la lista de funciones: callback (funciones que son utilizadas como argumento) que Zabbix usará para exportar la historia de diferentes tipos de datos.

Los valores pueden ser NULL si el módulo no está intereado en la historia de un determinado tipo de datos.

Cierre (Opcional)

int	zbx_module_uninit(void);

Dicha función se encarga de cerrar, es decir, realizar lo opuesto a la inicialización.

Libera recursos ocupados, etc.

Recordemos que todas las funciones son llamadas una vez al momento en el que se carga el módulo, a excepción de ésta.

Definición de Items

Cada Item está definido en una estructura ZBX_METRIC, como se ve a continuación:

typedef struct
{
	char		*key;
	unsigned	flags;
	int		(*function)();
	char		*test_param;
}
ZBX_METRIC;

Se define la «key» la cual será la key del Item, y las Banderas.

static ZBX_METRIC keys[] =
{
	{ "dummy.random", CF_HAVEPARAMS, zbx_module_dummy_random, "1,1000" },
	{ NULL }
}

Cada función que implementa un Item debe aceptar dos Parámetros, siendo el primero de tipo AGENT_REQUEST y el segundo de tipo AGENT_RESULT.

int	zbx_module_dummy_random(AGENT_REQUEST *request, AGENT_RESULT *result)
{
	...
 
	SET_UI64_RESULT(result, from + rand() % (to - from + 1));
 
	return SYSINFO_RET_OK;

Estas funciones devolverán SYSINFO_RET_OK si el Parámetro fue obtenido con éxito, de lo contrario retornarán SYSINFO_RET_FAIL.

Historia del Item

NOTA: En el caso de que el script ./configure no exista aún, se debe ejecutar primero el comando ./bootstrap.sh para generarlo. Esto puede darse porque se obtuvo Zabbix desde otro repositorio siendo una sub-versión.

Se pueden definir dentro del módulo, ciertas funciones para exportar los datos de la Historia del Item según el tipo de dato.

typedef struct
{
	void	(*history_float_cb)(const ZBX_HISTORY_FLOAT *history, int history_num);
	void	(*history_integer_cb)(const ZBX_HISTORY_INTEGER *history, int history_num);
	void	(*history_string_cb)(const ZBX_HISTORY_STRING *history, int history_num);
	void	(*history_text_cb)(const ZBX_HISTORY_TEXT *history, int history_num);
	void	(*history_log_cb)(const ZBX_HISTORY_LOG *history, int history_num);
}
ZBX_HISTORY_WRITE_CBS;

Cada uno de ellos seleccionará el array «history» de «history_num», cuantas veces éste último exista como argumento.

En este caso por ejemplo, estamos queriendo obtener la Historia filtrando por tipo de dato FLOAT.

typedef struct
{
	zbx_uint64_t	itemid;
	int		clock;
	int		ns;
	double		value;
}
ZBX_HISTORY_FLOAT;

Construyendo módulos

El encabezado (header) más importante para los módulos es el include/module.h, el cual define la estructura de los datos.

Otro encabezado útil es el include/sysinc.h, el cual realiza la inclusión de todos los encabezados necesarios por el sistema.

Entre ellos, también incluye el include/module.h el cual es necesario para trabajar correctamente.

Para que, tanto include/module.h como include/syninc.h sean incluidos, el comando ./configure (sin argumentos) debería ser ejecutado primeramente en el directorio raíz de los recursos de Zabbix.

Esto creará el archivo include/config.h, del cual depende include/sysinc.h.

NOTA: En el caso de que el script ./configure no exista aún, se debe ejecutar primero el comando ./bootstrap.sh para generarlo. Esto puede darse porque se obtuvo Zabbix desde otro repositorio siendo una sub-versión.

Parámetros de configuración

El Zabbix Agent, Zabbix Server y Proxy, soportan dos parámetros para lidiar con los módulos.

  • LoadModulePath
    • La ruta completa donde están los módulos
  • LoadModule
    • Los módulos que se cargarán al inicio de Zabbix. Estos deben estar ubicados en el directorio que estará especificado en el primer parámetro. Es posible definir un LoadModule=nombre_modulo.so.

Configuración del Frontend

Ya que los módulos son soportados por el Zabbix Agent, el Zabbix Server y el Zabbix Proxy, el tipo de Item en el Zabbix Frontend dependerá de dónde se carga el módulo.

Si el módulo es cargado en el Agente, entonces el tipo de chequeo deberá ser Passive Check o Active Check.

Si el módulo es cargado en el Server o en el Proxy, deberá ser de tipo «Simple Check».


?Más info aquí


¿Tienes alguna consulta o quieres conocer más sobre Zabbix? ¡Hablemos! Whatsapp | Telegram | info@custos.uy

+Leer
Custos MonitoringZabbix Agent, módulos y sus usos.

Zabbix Agent avanzado. Configuración avanzada.

Ahora que ya conocemos las configuraciones básicas y necesarias del Zabbix Agent, podemos descubrir otras configuraciones. Con esto definiremos nuevas funcionalidades y tendremos mayor control sobre nuestros equipos.

Autoregister en Zabbix

El Autoregister es una opción la cual permite que se registre automáticamente en el equipo quede monitoreado. Siempre y cuando esté bien instalado y funcionando el Zabbix Agent en un equipo

Esto ahorra tiempo si tenemos que hacer una instalación masiva en muchos equipos. De esta manera no tenemos que ir agregando cada equipo manualmente.

Tener en cuenta que ésta funcionalidad está implementada desde Zabbix 2.0, pero a partir de las versiones 4.0. La acción de Autoregister se realiza cada vez que el Zabbix Agent intenta hacer un chequeo de tipo Active Check.

En estas versiones esto ocurre cada 60s, lo cual favorece la rapidez para detectar nuevos equipos.

Crear un Action

Para configurar dicha funcionalidad, debemos ir a la sección «Configuration». Luego a «Action» en nuestro Zabbix Frontend y seleccionar el tipo de Acción. Debemos elegir en el menú desplegable «Event source: Autoregister» y finalmente hacer clic en el botón «Create Action».

Allí, estableceremos condiciones para que la Acción de Autoregister ocurra cuando dichas condiciones se cumplan; o por el contrario, no se cumplan. Es decir, hacer que dicha Acción se ejecute con una negación referente al contenido del Metadata.

Zabbix Agent avanzado.  Autoregister.

De esta manera podemos, por ejemplo, establecer que la Acción sea ejecutada si el Metadata contiene una palabra que definiremos. O bien, si es exactamente dicha palabra o sentencia.

En este caso, definimos que, si el Metadata es equivalente a la frase «oficina-central», se va a ejecutar dicha Acción.

Definir Operaciones en Action

Ahora bien, si vamos a agregar a Zabbix los nuevos Zabbix Agent que se detecten, entonces necesitamos definir una Operación y definir más datos. Es posible configurar el HostGroup a donde irá este nuevo Host y que Templates se les asignarán.

Esto lo hacemos al cambiar a la pestaña «Operations» y clic en «New».

Zabbix Agent avanzado.  Action

Se desplegarán opciones para que podamos crear una nueva Operación. En este caso, queremos que el nuevo Host que se reporte sea agregado, en el HostGroup «Equipos Oficina Central».

Para eso debemos configurar las Operaciones de la Acción definiendo una Operación para cada característica que queramos especificar.

Primero, debemos especificar que cuando se ejecute la Acción, se agregue el Host en cuestión (que cumpla las condiciones que establecimos al principio). Elegiremos entonces, «Operation type: Add Host», y haremos clic en Add para añadir la Operación a la Acción.

Zabbix Agent avanzado.  Add Host

En segundo lugar, añadiremos otra Operación haciendo clic en el botón «New» y luego elegiremos «Operation type: Add to host group»

Zabbix Agent avanzado.  Add to host group

Finalmente daremos clic en el botón azul «Add» que está abajo, para crear la Acción. Recordemos que se puede deshabilitar la Acción y también editar o eliminar tanto la Acción como sus Operaciones.

Como mencionamos anteriormente, también es posible determinar condiciones más complejas. Con el uso de Regular Expressions podemos indicar que la condición se cumpla si el Metadata equivale a «nada». Es decir, no se define o está vacío.

Zabbix Agent avanzado. Add

Configuración del Metadata y ServerActive en Zabbix Agent

Ahora bien, ¿cómo configuramos el Metadata en el Zabbix Agent? Para acceder a esta configuración, tenemos que modificar el parámetro «Metadata». El mismo está en el archivo de configuración del Zabbix Agent, donde podemos descomentar el parámetro. Esto sería quitar el # que está delante de «Metadata» y modificar el valor para hacerlo coincidir con lo establecido en la condición del Action.

Zabbix Agent avanzado.  Metadata

También es necesario especificar el parámetro ServerActive en el archivo de configuración del Zabbix Agent. Esto lo hacemos para definir que los chequeos de tipo Active Checks sean dirigidos a la IP que definimos en el parámetro.

En este punto iniciamos o reiniciamos el Zabbix Agent, y podemos echar un vistazo al Log de Zabbix Server. Podemos ver que el equipo en cuestión intentó hacer un chequeo de tipo Active Check y dio error (ya que el mismo no esta agregado en Zabbix).

Sin embargo, al tener el Action de Autoregister, dicho error solo ocurre esa vez, ya que es el momento en cuando se toman los datos para poder darse de alta él mismo.

Tener en cuenta que, añadir equipos mediante la función Autoregister, se rige bajo las mismas reglas que añadir un equipo manualmente. Es decir, esto solamente podrá funcionar si no existe un Host con el mismo Hostname.

Por tanto es necesario cambiar siempre el Hostname en el archivo de configuración del Zabbix Agent. O bien asegurarse que el nombre de Host del equipo sea diferente y único a los que ya existen.

Asignación de nuevas Keys en Zabbix

Para asignar nuevas Keys en Zabbix, tenemos que comprender primero qué son las Keys y que es el archivo Userparameters. El uso de este archivo, permite una funcionalidad extendida para mejorar el desempeño de Zabbix. Puedes ver más información en el artículo Zabbix Agent: Uso de Módulos

  • Key
    • Es un atributo del Item el cual se refiere a una solicitud, comando o query para obtener determinados datos recolectados por Zabbix. Recordemos que un Item es un elemento que podemos agregar en Zabbix para configurar un nuevo chequeo, y la query es una solicitud o consulta al Zabbix Database, una vez ya se recolectó dicho dato (gracias a un comando).
  • Userparameters
    • Dicho archivo sirve para especificar nuevas Keys en él. Es muy útil cuando queremos consultar por algún chequeo que no está comprendido por las Keys que tiene por defecto el Zabbix Agent. De esta manera, podemos agregar un nuevo Item a Zabbix, con esta nueva Key que creamos, y tener monitoreo en el Zabbix Frontend, ver el histórico, verlo en Grafana, etc.

Editar el archivo Userparameters en Zabbix Agent

Es necesario que dicho archivo este configurado en todos los equipos en los que necesitamos que funcionen las Keys que queremos establecer. Por ejemplo, si queremos configurar un archivo Userparameters donde se definan las Keys que utilizaremos para realizar consultas a la Zabbix Database, deberíamos crearlo en el Zabbix Agent del Zabbix Database.

Para que funcione el archivo Userparamenters, también es necesario indicarle dónde está éste archivo al Zabbix Agent.

Esto se puede hacer editando el archivo de configuración del Zabbix Agent, y agregar la siguiente línea. Podemos realizar la búsqueda del término «include» en el archivo de configuración de Zabbix Agent para ubicarnos rápidamente y encontrar el lugar donde debemos configurar que, Zabbix Agent incluya también las Keys que se encuentran en dicho directorio y que terminen con .conf.

Include=/etc/zabbix/zabbix_agentd.d/*.conf
Zabbix Agent avanzado. .conf

Vamos a crear el archivo userparameters.mysql en la ruta que especificamos y lo editaremos para continuar con las Keys.

Ahora, se debe seguir determinada sintaxis para que las nuevas Keys sean reconocidas y funcionen como tal.

Userparameters=<key>,<command>

La <key> será de nuestra elección, que sea referente al propósito de dicha consulta. Debe ser única dentro del Host, es decir que en el Host, no puede existir otra Key con el mismo nombre. Ésta, será la misma Key que vamos a introducir cuando creemos el Item y debamos especificar la Key del mismo.

*insertar captura de pantalla al cr4ar un item

El <command> es el script o la función mediante la cual recolectaremos esos datos que serán guardados en el Zabbix Database. Puede ser la ejecución de un archivo con un script mucho más complejo que hayamos definido.

Mysql.ping como ejemplo para Key

En el siguiente ejemplo tenemos un Userparameter con <key> = mysql.ping y un <command> = mysqladmin -uroot ping | grep -c alive

UserParameter=mysql.ping,mysqladmin -uroot ping | grep -c alive

La <key> mysql.ping es simplemente el nombre de la Key para poder hacer referencia a la misma y la que vamos a utilizar al crear el Item.

El <comand> mysqladmin -uroot ping | grep -c alive, intenta conectarse y hacer un ping con el usuario root. Existe una separación con «|», esto hace que lo que está después del pipeline se ejecute luego de haber ejecutado lo que está antes del mismo.

Entonces, la ejecución de mysqladmin -uroot ping dará un resultado donde veremos la información del ping que realizamos, en definitiva si se puede o no conectar a la Base de Datos.

Esto imprimirá un resultado en pantalla, en el cual buscamos y contamos con un grep, si existe el término «alive». De esta manera, si la ejecución de este UserParameter da como resultado «1», significa que encontró una vez el término «alive» y por tanto, la conexión a mysql está disponible.

Tener en cuenta que, si queremos utilizar comandos más complejos, y realizar consultas al Zabbix Database, lo más probable es que debamos utilizar un usuario con una contraseña que tenga los permisos suficientes para acceder a la Database en cuestión. Tendremos que definir un archivo y especificar en el mismo, los datos para conectarnos a MySQL.

Este mismo archivo será el que Userparameters tomará como referencia para hacer la conexión y la consulta. Para que lo encuentre, es necesario especificar que el directorio donde se encuentra este archivo .my.cnf, sea el HOME.

/var/lib/zabbix/.my.cnf

[client]
user=usuario
password=contraseña

? Lee más en Zabbix


¿Tienes alguna consulta o quieres conocer más sobre Zabbix? ¡Hablemos! Whatsapp | Telegram | info@custos.uy

+Leer
Custos MonitoringZabbix Agent avanzado. Configuración avanzada.

Monitoreo Zabbix: Componentes básicos.

En ésta publicación vamos a contarte, de forma detallada, cuales son los componentes básicos del Monitoreo Zabbix.

Monitoreo Zabbix_Implementacion básica de Zabbix


Monitoreo Zabbix


En la figura, se representa un sistema de Monitoreo Zabbix básico, con hexágonos las computadoras y dentro se describe la función.

Existen ciertos componentes esenciales, algunos imprescindibles, a la hora de implementar el sistema de monitoreo Zabbix.

Lograr el correcto funcionamiento del mismo puede requerir de los componentes que no son imprescindibles.

Hablamos de ellos a continuación:

Frontend

Es el Zabbix Frontend, la cara, imprescindible.

Encargado de:

  • Interactuar con el usuario
  • Mostrar los datos cosechados mediante
    • Gráficas
    • Mapas
    • Dashboards
  • Configurar
    • Dispositivos (Hosts), equipos que se monitorean
    • Medidas (Items), que es lo que mido del equipo
    • Condiciones de error (triggers), o problemas
    • Alertas (comunicación de eventos al usuario)

BackEnd

Es el Zabbix Server, el corazón, imprescindible.

Encargado de

  • Cosechar datos centralizadamente
  • Analizar los datos recolectados
  • Notificar a los usuarios
  • Almacenar los datos en la DB
  • Administrar la DB
    • Eliminar datos viejos
    • Crear trends

Base de datos

Es la Zabbix DB Donde se guarda toda la información:

  • Configuraciones de monitoreo
    • Usuarios y permisos
    • Elementos de visualización de datos
      • Gráficas, screens, dashboards, mapas
    • Métricas a recolectar
      • Dispositivos y mediciones
      • Tiempo de vida de estas mediciones
  • Datos historicos
    • Mediciones que se fueron cosechando

Proxy

Es el Zabbix Proxy, su instalación no es obligatorioa.

Encargado de:

  • Compartir trabajos con el Server
    • Encargarse de cosechar datos
    • Hacer preproceso de datos
  • Saltar proxies
  • No perder datos sobre una conexión poco estable
  • Agrupar configuraciones por características (por ejemplo la necesidad de timeouts mas largos)

Agente

Es el Zabbix Agent, su instalación no es obligatoria.

Puedes ver más información sobre el mismo y su configuración en los artículos Configuración básica y Configuración avanzada del Agente.

Se encarga de:

  • Cosechar datos
  • Independizarnos del sistema operativo
  • Ejecutar comando remotos
  • Compartir trabajos con el Server o Proxy

? ¿Más sobre los componentes del sistema?


¿Tienes alguna consulta o quieres conocer más sobre Zabbix? ¡Hablemos! Whatsapp | Telegram | info@custos.uy

+Leer
Custos MonitoringMonitoreo Zabbix: Componentes básicos.

Zabbix checks: Active Checks – Passive Checks.

Zabbix checks.

Los chequeos tienen una primera calificación entre Chequeos Activos y Chequeos Pasivos.

Esta calificación, de Zabbix checks, es desde el punto de vista del Zabbix Agent.

¡A continuación te contamos todos los detalles de los Zabbix checks!


.

Passive Checks

Item Type: Zabbix Agent
El Agente va a tomar un rol pasivo, es decir que va a esperar que le soliciten el valor

Chequeos pasivos, a traves de un polling se solicita la información

Chequeos Activos

Item Type: Zabbix Agent (active)
El Agente debe tomar un rol activo, es decir que va a tomar la iniciativa de comunicar el valor. Para saber que tiene que comunicar, previamente le pregunta al servidor y se identifica con su Hostname, para saber un poquito más aquí

Zabbix Checks- Trapping
Chequeos activos, el agente envía la información

¿Por qué el uso de diferentes tipos de Zabbix checks?

La comunicación entre dos puntos NodoA y NodoB de una red puede abierta o limitada.
Puede que NodoA no logre llegar a NodoB (NAT o Firewalls) pero NodoB puede llegar a NodoA, es decir que la comunicación está limitada.

Para poder cosechar el dato, el nodo que pude comunicarse con el otro debe inciar la comunicación. Si la inicia el Zabbix Agent, es un chequeo activo, y es un chequeo pasivo en caso de que sea el Zabbix Server o Proxy el que inicie la comunicación.

NOTA: En el caso de que el script ./configure no exista aún, se debe ejecutar primero el comando ./bootstrap.sh para generarlo. Esto puede darse porque se obtuvo Zabbix desde otro repositorio siendo una sub-versión.

¿Existen otros beneficios?

Si el chequeo es activo. el Zabbix Agent se va a comunicar periódicamente con el Server identificándose y preguntando cuáles son los chequeos que se necesitan y cada cuánto (período) se necesitan. Luego de esto, todo el trabajo va a estar del lado del Zabbix Agent en lo referente a esos chequeos, el Server no necesita preocuparse y puede dedicarse a otras tareas.

Por otro lado, el funcionamiento también es distinto, ya que si el Server es el que se encarga de cosechar el dato, tiene que abrir una conexión por cada dato que solicita. Si los chequeos son activos, el agente guarda en un buffer los datos y los envía periódicamente, mejorando la utilización del ancho de banda.

Resumen

  • Chequeos Activos (active checks)
    • Responsabilidad del Zabbix Agent en la cosecha y entrega del dato
    • Se le quita carga al Zabbix Server
    • Se mejora el uso del ancho de banda al poder enviar más de un valor por conexión
    • Necesarios cuando el Server no tiene acceso al dispositivo monitoreado (NAT, Firewalls).
  • Chequeos Pasivos (pasive checks)
    • Responsabilidad del Server en la cosecha del dato
    • Necesario cuando el Zabbix Agent no tiene acceso al Server

Recordemos que para configurar los Active Checks, debemos definir el parámetro ServerActive en el archivo de configuración del Agente.

Puedes ver más información en nuestro artículo Configuración básica de Zabbix Agent

Y si te interesa profundizar más, mirá este artículo Zabbix Checks


¿Tienes alguna consulta o quieres conocer más sobre Zabbix? ¡Hablemos! Whatsapp | Telegram | info@custos.uy





+Leer
Custos MonitoringZabbix checks: Active Checks – Passive Checks.

Zabbix Agent – Configuración básica.

Zabbix Agent

Uno de los componentes de Zabbix es el Zabbix Agent, que, aunque es opcional su instalación (no es esencial para monitorear, podemos hacerlo mediante SNMP entre otros), nos abre la «puerta mas grande» para monitorear un dispositivo.

Para poder instalar el Agent, es necesario que exista un Sistema Operativo. Zabbix provee Pre Compiled Agents para muchos Sistemas Operativos tales como Ubuntu, Red Hat, Centos, Suse, Raspbian (Sistema Operativo de la raspberry), etc.

En caso de que no exista un agente precompilado, si el Sistema Operativo tiene un compilador C, alcanza con bajar los fuentes y compilarlo. Zabbix y nosotros ofrecemos ayuda para esto.

Configuración mínima de Zabbix Agent.

Lo mínimo que tenemos que decirle al Agente es cuál Zabbix Server o Proxy puede preguntarle datos (Passive Checks Chequeos Pasivos) y/o a quien tiene que ir a consultar por Chequeos Activos (Active Checks).

La configuración del agente se hace en un archivo de configuración en texto plano «zabbix_agentd.conf«, generalmente (y recomendablemente) se encuentra en el directorio /etc/zabbix/.

La mínima configuración (luego la podemos recortar un poco más) es:

Server=10.10.10.10
ServerActive=10.10.10.10
Hostname=Stout

Como puede verse en Tipos de Chequeos hay chequeos activos y pasivos, nombrados así por como los ve el agente.

El Server va a ser el sevidor que se va «a encargar» de los chequeos pasivos y el ServerActive, de los chequeos activos.

Server

Todas las IP (y/o DNS) listadas en Server son las IP del Zabbix Server o Proxy de las que el agente va a aceptar preguntas, es decir Chequeos Pasivos.
Si alguien que no esta en la lista le pregunta, lo va a ignorar.

ServerActive/Hostname

El ServerActive lista las IP (y/o DNS) del Zabbix Server o Proxy a donde el agente va a ir a preguntar periódicamente «¿qué información querés que te mande?».
El agente se va a identificar con el valor de Hostname, y es por eso que ese valor debe coincidir con el nombre que se le dio al host cuando se dió de alta en el FrontEnd.
En síntesis, el agente le va a preguntar a cada IP listada, «soy Hostname, ¿qué ítems tienes configurados para mi?»

Recortando un poco más.

Si nuestro Agent se encuentra inaccesible desde el Server, es decir, no tenemos posibilidad de hacerle preguntas, solo vamos a poder cosechar Chequeos Activos, por lo que podríamos obviar configurar el Server.
Dicho de otra manera, si no se configura el Server, los chequeos pasivos están deshabilitados.

Si por el contrario, el Agente es incapaz de establecer la comunicación con el Zabbix Server, solo vamos a cosechar Chequeos Pasivos, carece de importancia configurar ServerActive y Hostname.
Dicho de otra manera, si no se configura el ServerActive y Hostname, los chequeos activos están deshabilitados

Tips: Al limitar los servidores en la configuración, impido que un servidor externo pregunte datos al agente. Esto va a evitar que múltiples servidores «molesten» al agente y se filtren datos. Es conveniente mantener al mínimo los servidores configurados.

¿Querés saber más? Mirá Zabbix



¿Tienes alguna consulta o quieres conocer más sobre Zabbix? ¡Hablemos! Whatsapp | Telegram | info@custos.uy

+Leer
Custos MonitoringZabbix Agent – Configuración básica.