UNIVERSIDAD REY JUAN CARLOS MASTER EN REDES DE TELECOMUNICACIÓN PARA PAISES EN DESARROLLO GESTIÓN Y MANTENIMIENTO DE REDES INALÁMBRICAS EN ZONAS RURALES
Trabajo Final
ZABBIX 1.8: ASPECTOS FUNCIONALES FUNCIONALES EN GESTIÓN DE REDES
Maksym Kuznyetsov
14 de Mayo del 2010
Índice Pagina
1. Introducción en Zabbix.
3
2. Gestión de Fallos.
6
3. Gestión de Configuraciones.
18
4. Gestión de Seguridad.
27
5. Gestión de Prestaciones.
29
6. Gestión de Usuarios y Cuentas.
37
7. Conclusión.
38
8. Bibliografía.
40
2
Índice Pagina
1. Introducción en Zabbix.
3
2. Gestión de Fallos.
6
3. Gestión de Configuraciones.
18
4. Gestión de Seguridad.
27
5. Gestión de Prestaciones.
29
6. Gestión de Usuarios y Cuentas.
37
7. Conclusión.
38
8. Bibliografía.
40
2
1. Introducción en Zabbix. Zabbix es una aplicación de sistema de gestión de red creada por Alexei Vladishev. Actualmente esta desarrollada y soportada por Zabbix SIA. Se diseñó para monitorizar el estado de varios servicios en la red, servidores u otro hardware utilizando MySQL, PostgreSQL, SQLite u Oracle para almacenar datos. Su backend esta escrito en C y la interfaz Web en PHP. La herramienta ofrece varias opciones de monitorización y mediante comprobaciones sencillas se puede verificar la disponibilidad y capacidad de respuesta estándar de los servicios SMTP o HTTP sin necesidad de instalar ningún software en el nodo monitorizado. El Agente Zabbix se puede instalar en los nodos de UNIX para realizar la monitorización ofreciendo las estadísticas tales como: co mo: carga de CPU, nivel del uso de la red, espacio libre en el disco y etc. Como una alternativa de instalar Agente en el nodo, Zabbix ofrece soporte para monitorización a través de comprobaciones SNMP, TCP, ICMP, IPMI y mediante los parámetros personalizados. La herramienta soporta la variedad de mecanismos de notificación en el tiempo real, como por ejemplo XMPP. Distribuido bajo los términos de la Licencia General Publica GNU - Zabbix es el software libre, lo que significa que su código fuente se distribuye gratuitamente y es disponible al público. También se ofrece el soporte comercial proporcionado propor cionado por la Empresa Zabbix. Zabbix es una solución abierta de monitorización distribuida en múltiples parámetros de la red que garantiza la integridad a los servidores. Utiliza un mecanismo flexible de notificaciones que permite a usuarios configurar notificaciones sobre cualquier evento por el correo, lo que posibilita reaccionar de manera rápida a los problemas con el servidor. Zabbix ofrece informes de alta calidad y visualización de datos basándose en la información recogida, que lo hace muy útil para la planificación. Zabbix soporta sondeo (polling), que es el conjunto de procesos de Servidor Zabbix y Zabbix Proxy que recogen la información de los Agentes Zabbix según elementos de datos. Zabbix también soporta la captura (trapping), que es el conjunto de procesos de Servidor Zabbix y Zabbix Proxy que escucha el puerto (habi ( habitualmente tualmente 10051) y recibe datos de los Agentes Zabbix respecto a las revisiones activas o datos del Zabbix Sender. Todos los informes y estadísticas de Zabbix, con las opciones de configuración están disponibles a través de la interfaz Web. La interfaz Web garantiza accesibilidad desde cualquier ubicación para poder realizar comprobaciones del estado de red y del correcto funcionamiento de servidores. La configuración adecuada de herramienta desempeña un papel primordial en el control de la infraestructura. Es importante como para las organizaciones pequeñas con unos cuantos servidores, tanto para las grandes empresas con una gran cantidad de estos. esto s. Zabbix 1.8 ofrece:
Detección automática de los servidores y dispositivos de red Monitorización distribuida con la administración centralizada a través de WEB Soporte a los mecanismos de sondeo y captura Software de servidor para Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X Agentes nativos de alto rendimiento (software de cliente para Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X, Tru64/OSF1, NT 4.0, Windows 2000, Windows 2003, Windows XP, Windows Vista) Monitorización sin Agente Autenticación segura de los usuarios Un sistema flexible de derechos de acceso de los usuarios Interfaz WEB Flexible notificación por correo electrónico acerca de los eventos determinados deter minados Vista (comercial) de alto alto nivel de los recursos controlados 3
Registro de auditoría
En relación con requerimientos de seguridad y control de los servidores críticamente importantes, sólo el sistema operativo UNIX es el único sistema operativo que puede proporcionar el rendimiento necesario, tolerancia a fallos y la flexibilidad usando Zabbix. Ventajas de la herramienta:
Software de fuente abierta. Agentes de alto rendimiento para UNIX y plataformas plata formas Win32. Bajo nivel de formación necesario para manejo. Alta rentabilidad de las inversiones. Tiempo de inactividad es muy caro. Bajo coste de mantenimiento. Configuración muy simple. Sistema centralizado de monitorización. Toda la información infor mación (configuración, datos de rendimiento) se almacena en una base de datos dat os relacionada. Árbol de servicio de alto nivel. nivel. Instalación muy sencilla. Soporte para SNMP (v1, v2, v3). Ambos modos: sondeo y captura. Posibilidad de visualizar. Un mecanismo integrado de limpieza.
Principios de desarrollo:
Ser cómodo para usuarios Simplicidad El uso de múltiples recursos de procesamiento Respuesta rápida Documentación sobre todos los aspectos del software
Componentes. Servidor Zabbix. zabbix_server Zabbix. zabbix_server es es un demonio del núcleo de software Zabbix y se encuentra en el fichero: /etc/zabbix/zabbix_server.conf. El servidor puede controlar de forma remota los servicios de red (como servidores Web y servidores de correo) usando revisiones de servicio simples, pero también es un componente central a quien los agentes informan sobre la disponibilidad e integridad de la información y estadísticas. El servidor es un repositorio de datos que almacena toda la configuración, los datos estadísticos y operativos, y también representa la entidad en el software de Zabbix que alertará a los administradores si ocurre algún problema con cualquiera de los equipos monitorizados. Zabbix también puede realizar la monitorización sin agentes, junto con la monitorización de los dispositivos de red mediante agentes SNMP. Zabbix Proxy. zabbix_proxy Proxy. zabbix_proxy es es un demonio Proxy, que se utiliza para recopilar datos remotos y se encuentra en el fichero: /etc/zabbix/zabbix_proxy.conf. Un Proxy no es un componente obligatorio en el despliegue de Zabbix. Zabbix. Proxy recoge datos sobre el rendimiento y la disponibilidad disponibilidad en nombre del servidor de Zabbix. Todos los datos recogidos se almacenan en un buffer a nivel local y se pasan al Servidor Ser vidor Zabbix, a cual pertenece el servidor ser vidor Proxy. Zabbix Proxy es una solución ideal para par a la monitorización centralizada remota de las ubicaciones, afiliados o redes que no disponen de los administradores locales. Zabbix Proxy también se puede utilizar para distribuir la carga de Servidor Zabbix individual. En este caso, el Proxy sólo recoge los datos, con lo que el servidor tiene menos carga de CPU y de disco de almacenamiento. almacenamient o. 4
Agente Zabbix. zabbix_agentd (UNIX, Standalone demon) es un demonio para monitorizar las diferentes opciones del servidor y se encuentra en el fichero: /etc/zabbix/zabbix_agentd.conf. Realiza el control de los recursos locales y aplicaciones (tales como discos duros, memoria RAM, estadísticas CPU, y etc.) en los sistemas de red que tienen que funcionar con el Agente Zabbix arrancado. Agente va a recoger puntualmente la información sobre el sistema en el que esta operando, y proporcionar estos datos a Zabbix para su posterior procesamiento. En caso de fallo (por ejemplo, el disco duro está lleno o se ha caído el proceso de servicio), Servidor Zabbix puede avisar a los administradores de equipos específicos que informaron sobre error. Los Agentes Zabbix son muy eficaces debido a que utilizan las llamadas del sistema nativas para recolectar la información estadística. zabbix_agent (UNIX, versión Inetd) es un fichero de configuración que contiene los parámetros de configuración. Este fichero tiene que existir y tener permisos de lectura para el usuario de Zabbix. Zabbix utiliza el protocolo de comunicación basado en JSON para la comunicación con el Agente Zabbix realizando comprobaciones pasivas y activas. La comprobación pasiva es una simple consulta de datos. El Servidor Zabbix (o Proxy) solicita los datos, por ejemplo la carga de CPU, y el agente Zabbix envía el resultado de vuelta al servidor. Por ejemplo: 1. El servidor abre una conexión TCP. 2. El servidor envía agent.ping\n. 3. El agente lee la solicitud y responde 1. 4. El servidor procesa el valor de datos obtenidos, en este caso "1". La comprobación activa requiere un procesamiento más sofisticado. Primero el Agente debe devolver la lista de elementos para su procesamiento independiente. El también envía periódicamente los nuevos valores al servidor. Por ejemplo: 1. El agente abre una conexión TCP. 2. El agente solicita la lista de revisiones. 3. El servidor responde con una lista de elementos (clave de elemento, retardo). 4. El agente analiza la respuesta e inicia una recogida periódica de datos. Web Interface. La interfaz Web tiene fin de facilitar el acceso rápido a los datos de monitorización y configuración de Zabbix desde cualquier lugar y desde cualquier plataforma siempre y cuando en esta exista la interfaz Web. La interfaz es parte del Servidor Zabbix, y por lo general (pero no necesariamente) se esta ejecutando en el único servidor físico. Si se está utilizando SQLite interfaz Web de Zabbix se debe ejecutar en el mismo servidor zabbix_get es la utilidad de línea de comandos para recibir datos de un Agente Zabbix remoto. Zabbix UNIX Get es un proceso que interactúa con el Agente Zabbix y recibe la información solicitada. Por lo general, esta utilidad se usa para solucionar problemas con los Agentes Zabbix. Por ejemplo: zabbix_get -s127.0.0.1 -p10050 -ksystem.cpu.load[all,avg1]. zabbix_sender es la utilidad de línea de comandos para enviar datos de rendimiento a un Servidor Zabbix remoto para su posterior procesamiento. Normalmente, esta utilidad se utiliza en scripts de usuarios de larga duración para un envío de datos periódico sobre la disponibilidad y rendimiento. Por ejemplo: zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -s ``Monitored Host'' -k ``mysql.queries'' -o ``342.45'' Tipos de medios de comunicación. Correo Electrónico – Se utiliza para las notificaciones por correo electrónico. Jabber – Notificaciones usando los mensajes Jabber. Scripts - Scripts de usuario. Zabbix envía a los scripts tres parámetros en la línea de comandos: Destinatario, Asunto y Mensaje. Módem GSM - Zabbix soporta el envío de mensajes SMS utilizando un módem GSM conectado al puerto serie de Servidor Zabbix. Principales mejoras en Zabbix 1.8 respecto a versiones anteriores:
Se añade el modulo ensanchado de monitorización que permite aumentar significativamente el rendimiento de operaciones de Servidores y de Proxy. A costa de disminuir la intensidad de 5
peticiones hacia base de datos, la velocidad de realizar algunas operaciones aumenta en aproximadamente 10 veces. Aumento de eficiencia de peticiones de sondeo (polling) con soporte para realizar al mismo tiempo centenas de procesos de revisión que funcionan a través del único gestor y no se dirigen directamente a la base de datos. La mejora de interfaz de usuario, en la interfaz Web aparece la posibilidad de división en las páginas, realización de operaciones masivas, y de trabajo con un conjunto de elementos determinado. Se optimizan las configuraciones con gran número de objetos observados. Aparece soporte de filtros para depurar la información que corresponde únicamente a la mascara actual. Se efectúa el soporte completo a PHP 5.3. El soporte a PHP 4 esta cancelado. Se amplían las posibilidades de contabilidad trabajando con un sistema de monitorización en periodos de prestaciones planificados, que ahora pueden ser acoplados con los nodos individuales o con grupos de nodos. Se incrementan las posibilidades de redacción por medio de la pantalla: está simplificada la modificación y creación de pantallas a costa de nuevas opciones de redacción y modo dragand-drop de desplazamiento de elementos. Trabajando con los mapas geográficos ahora se puede utilizar el modo drag-and-drop para crear el mapa de red (función de iluminación automática de unidades con problemas). Posibilidad de presentación separada de información detallada sobre accesibilidad del nodo, basándose en informes recibidos a través de Agente Zabbix, Agente IPMI y Agente SNMP. Soporte de expresiones complicadas en peticiones al sistema, que facilita el análisis de logficheros. Se mejoran los medios de autoidentificación de nuevas unidades de red, incluido monitorización de las subredes determinadas en la configuración y realización de SNMPv3 revisiones. Adjunto se soporta la registración automática en el Servidor. Se añade el soporte de macros que simplifican significativamente el manejo de configuraciones (aparecen configuraciones especificas para determinados tipos de nodos). Se añade el soporte de revisión de estado de sistemas remotos sin uso de Agente Zabbix, basándose en comprobaciones directas a través de Telnet o SSH. Se mejora el soporte de base de datos Oracle, de modo que para acceder a esta se utiliza librería OCI de alta productividad, en vez de biblioteca Sqlora8. Las funciones de búsqueda global permiten de manera rápida y sencilla obtener la información sobre un nodo determinado, plantilla o grupo de nodos. Se presenta API basado en JSON-RPC, que permite organizar control remoto o integrar en el sistema de monitorización anexos secundarios. Un soporte completo de UTF-8, que hace Zabbix preparado para el uso en comunidades que hablen lenguas diferentes. Ampliación de medios de monitorización Web, que permite realizar unas revisiones más finas de las unidades, incluyendo áreas protegidas con contraseña. Mejora de módulos para monitorización ICMP y DNS.
2. Gestión de Fallos. Mensajes de errores y avisos. Los demonios de Zabbix generan los mensajes de error y advertencias en el caso de problema. Los mensajes se graban en los ficheros de registros o syslog, dependiendo de la configuración. Algunos mensajes tienen su número. Los mensajes numerados sobre errores tienen soporte en Zabbix 6
a partir de versión 1.8. La tabla que viene a continuación tiene una lista completa de números de mensajes con información detallada: Error
Mensaje
Descripción El demonio de Zabbix no ha podido establecer una conexión estable a la Connection to base de datos. Información complementaria: nombre de la base de datos, Z3001 database '%s' el código de error de la base de datos, la línea de descripción de error de la failed: [%d] %s base de datos. Cannot create El demonio de Zabbix no ha podido crear la base de datos. Información Z3002 database '%s': [%d] complementaria: nombre de la base de datos, el código de error de la base %s de datos, la línea de descripción de error de la base de datos. No connection to Error que no tendría que ocurrir nunca. Z3003 the database. El demonio de Zabbix no ha podido cerrar la conexión a la base de datos. Cannot close Z3004 database: [%d] %s Información complementaria: el código de error de la base de datos, la línea de descripción de error de la base de datos. Error de ejecución de la petición SQL. Información complementaria: el Query failed: [%d] código de error de la base de datos, la línea de descripción de error de la Z3005 %s [%s] base de datos, la línea de petición SQL. Error de recepción de anotaciones. Información complementaria: el Fetch failed: [%d] código de error de la base de datos, la línea de descripción de error de la Z3006 %s base de datos. Triggers. Los triggers se definen como una expresión lógica y representan el estado del sistema. El estado (expresión) de trigger se vuelve a calcular cada vez que un servidor de Zabbix recibe un nuevo valor si este valor es parte de la expresión. La expresión puede tener los siguientes significados: Valor
Descripción Habitualmente significa que algo ha ocurrido. Por ejemplo, una carga excesiva de TRUE procesador. FALSE Es un estado normal de trigger. En este caso Zabbix no puede valorar la expresión de trigger debido a varias causas: DESCONOCIDO servidor indisponible, la expresión de trigger no puede ser valorada, la expresión de trigger ha sido cambiado recientemente. Importancia de los triggers. Importancia Sin clasificación Informativo Aviso Mediano Alto Emergencia
Definición Color Importancia desconocida. Gris. Con el propósito de informar. Verde claro. Con el propósito de advertir. Amarillo claro. Problema mediano. Rojo oscuro. Ha ocurrido algo importante. Rojo. Emergencia. (Perdidas financieras y etc.) Rojo claro. 7
Expresiones de los triggers. Las expresiones que se utilizan en los triggers son muy flexibles. Se pueden usar para crear unos complejos tests lógicos sobre monitorización de estadística. Los triggers soportan siguientes operadores: /, *, -, +, <, >, #, =, &, |. Funciones de los triggers. Se soportan las siguientes funciones: abschange, avg, change, count, date, dayofweek, delta, diff, fuzzytime, iregexp, last, logseverity, logsource, max, min, nodata, now, prev, regexp, str, sum, time. Todas funciones devuelven únicamente los valores numéricos. Algunas funciones no se pueden utilizar para los parámetros de texto. La mayoría de funciones numéricas toman el número de segundos como el argumento. También se puede utilizar el prefijo # para especificar que el argumento tiene los significados diferentes. Ejemplo 1. Alguien esta descargando de Internet un fichero muy grande. Se puede utilizar la función min: {www.zabbix.com:net.if.in[eth0,bytes].min(300)}>100K. Esta expresión es verdadera cuando la suma de los bytes recibidos en la interfaz eth0 supere 100KB en últimos 5 minutos. Ejemplo 2. Los dos servidores SMTP no estan disponibles. En la expresión se utilizarían dos diferentes nodos: {smtp1.zabbix.com:net.tcp.service[smtp].last(0)}=0&{smtp2.zabbix.com:net.tcp. service[smtp].last(0)}=0. Esta expresión es verdadera cuando ambos servidores SMTP no están disponibles smtp1.zabbix.com y smtp2.zabbix.com. Ejemplo 3. El Agente Zabbix necesita actualizarse. Se puede utilizar función str():{zabbix.zabbix.com:agent.version.str(beta8)}=1. Esta expresión es verdadera cuando la versión de Agente Zabbix tiene en su contenido beta8. (posible 1.0beta8). Monitorización distribuida. Zabbix puede configurarse para soportar la monitorización distribuida de modo jerárquico. (hasta 100 nodos utilizando solo un servidor Zabbix). Los objetivos de la monitorización distribuida:
Control sobre elementos de datos que se están monitorizando desde una o varias ubicaciones. (el administrador de Zabbix puede cambiar configuración de todos los nodos desde el único interfaz WEB de Zabbix). La monitorización jerárquica. (sirve para la monitorización en los entornos complejos de varios niveles). La monitorización de entornos grandes y complejos. (es útil para monitorizar varias ubicaciones geográficas). Reducir los gastos generales en el Servidor Zabbix sobrecargado.
Zabbix proporciona un método eficiente y confiable de control sobre una infraestructura distribuida de TI. La configuración de toda la instalación distribuida puede llevarse de un único lugar a través de la interfaz Web común. Zabbix soporta hasta 1000 nodos instalados en modo distribuido. Cada nodo es responsable de monitorizar su propia ubicación. El nodo puede ser configurado localmente o a través del nodo maestro, que tiene una copia de datos de configuración de todos los nodos esclavos. La configuración de los nodos esclavos se puede hacer offline, es decir, sin comunicación entre el nodo maestro y los nodos esclavos. Una visión jerárquica de la monitorización distribuida permite a los nodos obtener una estructura de árbol. Cada nodo tiene que mandar informes únicamente al nodo maestro. Todas las unidades pueden funcionar incluso en el caso de problemas de comunicación. Información de historial y sobre los eventos se almacena localmente. Cuando la conexión se recuperaría, los nodos esclavos enviarían datos al nodo maestro. 8
Los nuevos nodos se pueden añadir y eliminar del sistema distribuido de Zabbix sin perder la funcionalidad de la instalación y sin tener que reiniciarse. Cada nodo tiene su propia configuración y funciona como un Servidor Zabbix normal. Configuración de nodos: Parámetro Nombre ID Tipo Franja Horaria IP Puerto
Descripción El nombre único del nodo. El ID único del nodo. Maestro – el nodo local Remoto – el nodo remoto La franja horaria del nodo. Zabbix convierte automáticamente el tiempo a la franja horaria local cuando hace transferencias de datos entre nodos. Dirección IP del nodo. El capturador de Zabbix tiene que escuchar esta dirección IP. El número del puerto del nodo. El capturador de Zabbix tiene que escuchar este puerto. Por defecto 10051.
No almacenar historial Sirve únicamente para los datos de historial no locales. más de (días) No almacenar Sirve únicamente para los datos de tendencias no locales. tendencias más de (días) Ejemplo de la configuración simple. La configuración simple consta de un nodo maestro y un nodo esclavo. El nodo maestro tendrá control completo sobre la configuración de los nodos esclavos. El nodo esclavo va a mandar informes al nodo maestro sobre eventos, historial y tendencias. El nodo Maestro tendrá NodeID =1, el nodo esclavo NodeID =2. IP de nodo maestro: 192.168.3.2, Puerto: 10051 IP de nodo esclavo: 192.168.3.5, Puerto: 15052 Configuración del nodo Maestro: Paso 1. Después de instalar Zabbix se realiza una creación estándar de la base de datos, de interfaz WEB y de sus ficheros. Paso 2. Se instala NodeID en el fichero de la configuración del servidor zabbix_server.conf: NodeID=1 Paso 3. Conversión de datos de la base de datos. El servidor Zabbix tiene que ejecutarse para convertir las IDs únicas y utilizarlas con el primer nodo. cd bin ./zabbix_server -n 1 -c /etc/zabbix/zabbix_server.conf Converting tables .................................................................. done. Conversion completed. Paso 4. Se configuran los parámetros del nodo. Paso 5. Se agrega el nodo esclavo. Paso 6. Se arranca el nodo maestro. Se ve NodeID en los mensajes de arranque de servidor en el log-fichero: 31754:20070629:150342 server #16 started [Node watcher. Node ID:1] 9
Configuración del nodo Secundario: Paso 1. Después de instalar Zabbix se realiza una creación estándar de la base de datos, de interfaz WEB y de sus ficheros. Paso 2. Se instala NodeID en el fichero de la configuración del servidor zabbix_server.conf: NodeID=2 Paso 3. Conversión de datos de la base de datos. El servidor Zabbix tiene que ejecutarse para convertir las IDs únicas y utilizarlas con el primer nodo. cd bin ./zabbix_server -n 2 -c /etc/zabbix/zabbix_server.conf Converting tables .................................................................. done. Conversion completed. Paso 4. Se configuran los parámetros de nodo. Paso 5. Se agrega el nodo maestro. Paso 6. Se arranca el nodo esclavo. Se ve NodeID en los mensajes de arranque de servidor en el log-fichero: 27524:20070629:150622 server #9 started [Node watcher. Node ID:2] La elección del nodo activo aparecerá automáticamente después de agregar los nodos. Se añade el nodo para monitorizar al nodo esclavo y se observan los eventos en el nodo maestro. Ejemplo de la configuración avanzada. Esta instalación contiene 7 nodos. Cada nodo puede configurarse como en modo local (utilizando la interfaz Web local), tanto desde uno de los nodos maestro.
En este ejemplo Riga (Node 4) va a recoger eventos de todos los nodos subordinados. Opcionalmente también puede estar recogiendo los datos del historial. Plataformas independientes. El nodo puede utilizar su propia plataforma (sistema operativo, hardware) y una base de datos independiente de otros nodos. Además los nodos esclavos pueden instalarse sin la interfaz Web de Zabbix. Esto puede tener sentido al utilizar las soluciones de hardware para servidores Zabbix muy poco potentes y gestionados mediante MySQL MyISAM o SQLite. Los nodos de nivel más alto pueden usar una mejor combinación con InnoDB MySQL, Oracle o PostgreSQL. 10
Configuración de nodo individual. única.
Cada nodo en el entorno distribuido tiene que estar correctamente configurado y teniendo la ID
Paso 1. Se realiza la instalación estándar sin arrancar el servidor Zabbix. Se instala y se configura la interfaz Web de Zabbix junto con la base de datos, creando la base de datos y cargando esta con data.sql. Paso 2. Se configura zabbix_server.conf. Se añade NodeID al fichero de configuración de servidor Zabbix. NodeID tiene que ser una ID única del nodo. Paso 3. Se configura el nodo maestro y los nodos esclavos. Usando la interfaz Web de Zabbix se configuran detalles de los nodos que tienen una conexión directa con este nodo. Paso 4. Se arranca el nodo Zabbix: shell> ./zabbix_server Si todo esta ajustado correctamente, el nodo Zabbix empezará a configurarse de modo automático intercambiando datos con todos los nodos en la instalación distribuida. Se verán los siguientes mensajes en el log-fichero del servidor: 11656:20061129:171614 NODE 2: Sending data of node 2 to node 1 datalen 3522738 11656:20061129:171614 NODE 2: Sending data of node 2 to node 1 datalen 20624 Cambio de conexión entre nodos. Conectándose al nodo en una instalación distribuida, la lista de los nodos esclavos disponibles se refleja arriba a la derecha en la interfaz grafica mostrando el nodo actual. Toda la información disponible en la interfaz grafica corresponde al nodo seleccionado. Los flujos de datos. De esclavo al maestro. Cada nodo esclavo envía periódicamente los cambios de configuración, datos de historial y de eventos a su nodo maestro. Datos Frecuencia Cambio de configuración Cada 120 segundos. Cada 10 segundos. Eventos Cada 10 segundos. Historial El nodo esclavo repetirá el envío de datos al tener problemas con la comunicación. Las tendencias se calculan localmente basándose en los datos de historial transferidos. Zabbix no envía los datos operativos correspondientes a los nodos. Por ejemplo, la información sobre elementos de datos (última revisión, último valor y etc.) existe solo a nivel local. El envío de eventos e historial se puede controlar mediante parámetros de configuración NodeNoEvents y NodeNoHistory. De maestro al esclavo. Cada nodo maestro (nodo que tiene por lo menos un nodo esclavo) envía periódicamente los cambios de configuración a los nodos esclavos o de manera directa o mediante otros nodos esclavos relacionados directamente con el nodo maestro. Zabbix no envía la configuración del nodo maestro a los nodos esclavos. Datos Frecuencia Cambio de configuración Cada 120 segundos. 11
Configuración de Cortafuegos. Las comunicaciones entre los nodos utilizan únicamente el protocolo TCP y el puerto por defecto para el proceso del capturador de Zabbix. Flujo de Datos Puerto remitente Puerto destinatario 10051 Esclavo a Maestro Cualquier 10051 Maestro a Esclavo Cualquier Monitorización SNMP extendida. MIBs especiales. Algunos de los SNMP MIBs usados con mucha frecuencia se traducen automáticamente en representaciones numéricas de Zabbix. Por ejemplo, ifIndex se traduce en 1.3.6.1.2.1.2.2.1.1, ifIndex.0 se traduce en 1.3.6.1.2.1.2.2.1.1.0. La siguiente tabla contiene un conjunto de los SNMP MIBs especiales: MIB especial ifIndex
OID
Descripción
1.3.6.1.2.1.2.2.1.1 El significado único para cada interfaz. Texto que contiene información sobre interfaz. ifDescr 1.3.6.1.2.1.2.2.1.2 (fabricante, producto, versión de hardware) ifType 1.3.6.1.2.1.2.2.1.3 Tipo de interfaz. Protocolos a nivel físico. El tamaño de la datagrama más grande que puede ifMtu 1.3.6.1.2.1.2.2.1.4 ser enviada/recibida desde este interfaz. ifSpeed 1.3.6.1.2.1.2.2.1.5 La velocidad actual de interfaz en Bits por segundo. Dirección de interfaz de nivel de transporte que ifPhysAddress 1.3.6.1.2.1.2.2.1.6 sigue después de nivel de red. ifAdminStatus 1.3.6.1.2.1.2.2.1.7 El estado administrativo actual de interfaz. ifOperStatus 1.3.6.1.2.1.2.2.1.8 El estado operacional actual de interfaz. La cantidad general de octetos recibidos en la ifInOctets 1.3.6.1.2.1.2.2.1.10 interfaz, incluyendo los símbolos fragmentados. La cantidad de paquetes unicast transmitidos por el ifInUcastPkts 1.3.6.1.2.1.2.2.1.11 protocolo de alto nivel. La cantidad de paquetes unicast, broadcast o ifInNUcastPkts 1.3.6.1.2.1.2.2.1.12 multicast transmitidos por el protocolo de alto nivel. La cantidad de paquetes entrantes que han sido elegidos para denegar la entrega en el caso si no ha ifInDiscards 1.3.6.1.2.1.2.2.1.13 habido ningún error. (una causa posible – liberación de lugar en el buffer). La cantidad de paquetes entrantes que contienen ifInErrors 1.3.6.1.2.1.2.2.1.14 errores. La cantidad general de los paquetes enviados desde ifInUnknownProto 1.3.6.1.2.1.2.2.1.15 interfaz, descartados por causa de un protocolo s desconocido y no soportado. La cantidad general de octetos enviados desde el ifOutOctets 1.3.6.1.2.1.2.2.1.17 interfaz incluyendo los símbolos fragmentados. 12
ifOutNUcastPkts 1.3.6.1.2.1.2.2.1.18
ifOutDiscards
1.3.6.1.2.1.2.2.1.19
ifOutErrors
1.3.6.1.2.1.2.2.1.20
ifOutQLen
1.3.6.1.2.1.2.2.1.21
La cantidad general de paquetes de protocolos de alto nivel requeridos para envío a una dirección unicast de la subred, incluyendo los descartados. La cantidad de paquetes de salida que han sido seleccionados para denegar la entrega en el caso de no detectar ningún error. (una causa posible – liberación de espacio en el buffer). La cantidad de paquetes de salida que no han sido enviados por los errores. La longitud de la cola de salida de los paquetes.
Códigos dinámicos. Los códigos dinámicos están soportados por Zabbix a partir de la versión 1.5. La sintaxis especial para los elementos de datos OID se puede utilizar para tratar con datos dinámicos (identificadores aleatorios para las interfaces de red, etc.) Sintaxis: ["index","< OID de datos general >",""] Por ejemplo, para obtener ifInOctets para GigabitEthernet0/1 de la interfaz del dispositivo Cisco se utiliza el siguiente OID: ifInOctets["index","ifDescr","GigabitEthernet0/1"] Parámetro Index OID de datos general Cadena de búsqueda
Descripción El método de procesamiento. Actualmente esta soportado solo un método index – la búsqueda según código añadiendo al OID general. OID general se utiliza para la búsqueda de datos. Esta línea se utiliza para las coincidencias exactas con el valor deseado. Depende de registro.
Otro ejemplo, para obtención de datos del uso de memoria por el proceso apache: HOST-RESOURCES-MIB::hrSWRunPerfMem["index","HOST-RESOURCES-MIB::hrSWRunPath", "/usr/sbin/apache2"] ... HOST-RESOURCES-MIB::hrSWRunPath.5376 = STRING: "/sbin/getty" HOST-RESOURCES-MIB::hrSWRunPath.5377 = STRING: "/sbin/getty" HOST-RESOURCES-MIB::hrSWRunPath.5388 = STRING: "/usr/sbin/apache2" HOST-RESOURCES-MIB::hrSWRunPath.5389 = STRING: "/sbin/sshd" ... Se acaba de obtener el código 5388, que se añadirá al OID necesario para poder recibir el valor que nos interesa: HOST-RESOURCES-MIB::hrSWRunPerfMem.5376 = INTEGER: 528 KBytes HOST-RESOURCES-MIB::hrSWRunPerfMem.5377 = INTEGER: 528 KBytes HOST-RESOURCES-MIB::hrSWRunPerfMem.5388 = INTEGER: 31468 KBytes HOST-RESOURCES-MIB::hrSWRunPerfMem.5389 = INTEGER: 31740 KBytes HOST-RESOURCES-MIB::hrSWRunPerfMem.5390 = INTEGER: 32116 KBytes HOST-RESOURCES-MIB::hrSWRunPerfMem.5391 = INTEGER: 30420 KBytes HOST-RESOURCES-MIB::hrSWRunPerfMem.5392 = INTEGER: 32560 Kbytes 13
Monitorización Web. La monitorización Web en Zabbix persigue el cumplimiento de los siguientes objetivos:
La monitorización del rendimiento de aplicaciones Web. La monitorización de accesibilidad de aplicaciones Web. Soporte de HTTP y HTTPS. Soporte de escenarios complejos que constan de múltiples pasos (peticiones HTTP).
Zabbix ofrece la monitorización Web efectiva y muy flexible. El modulo realiza la ejecución periódica de escenarios Web y almacena los datos recopilados en la base de datos. Los datos se utilizan de modo automático en los gráficos, triggers y notificaciones. Zabbix también verifica si la pagina HTML contiene las líneas predeterminadas. La monitorización Web en Zabbix soporta HTTP y HTTPS. La información siguiente se recoge en cada paso del escenario Web:
Tiempo de respuesta. La velocidad de carga en segundos. Código de respuesta
Escenario Web. El escenario es un conjunto de peticiones HTTP (pasos), que va a ejecutar periódicamente el Servidor Zabbix. Habitualmente los escenarios se determinan para una parte específica de la funcionalidad de aplicación Web. Representan una manera muy cómoda de controlar al usuario. El escenario Web esta relacionado con el grupo de elementos de datos del nodo para agrupación y se ejecuta periódicamente constando de uno o múltiples pasos. Todos los ficheros temporales se guardan al ejecutarse el escenario único. Por ejemplo: La monitorización de la interfaz grafica de Zabbix. Si se requiere la monitorización de accesibilidad y rendimiento de Zabbix GUI es necesario logarse, verificar la velocidad de presentación de las páginas, el estado de los triggers y luego salir. Si el paso de escenario no puede ser cumplido, la ejecución de escenario se interrumpe. El escenario puede contener los siguientes pasos: 1. 2. 3. 4.
Entrada. Paso a la pantalla de observación. Paso a la pantalla de estado de los triggers. Salida.
Parámetro Descripción El escenario Web va a estar relacionado con este grupo de elementos de datos. El Grupo de elementos de datos grupo de nodos de datos tiene que existir. Por ejemplo: Zabbix Server. Nombre de escenario Web aparecerá en Monitorización > Web. Por ejemplo. Nombre Zabbix GUI Autenticación Usar o no la autenticación sencilla para acceso a las paginas. sencilla Al habilitar la autenticación sencilla se requiere introducir el usuario. Usuario Al habilitar la autenticación sencilla se requiere introducir la contraseña. Contraseña Periodo de La frecuencia de ejecución del escenario Web en segundos. Por ejemplo: 60 actualización 14
Zabbix va a representarse por el medio del navegador elegido que es útil para la monitorización de las paginas Web que generan el contenido diferente para diferentes navegadores. Por ejemplo: Opera 9.02 en Linux. Activado: la activación de escenario para su ejecución. Desactivado: deshabilitar el escenario para que no se ejecute. La lista de macros que van a usarse en la configuración de los pasos. Sintaxis: {macros}=valor Macros {macros} se reemplazará con “variable” en el paso URL o en las variables Post. Por ejemplo: {user}=guest {password}=guest Los pasos de escenario.
Agente Estado
Variables
Pasos
En cuanto el escenario este creado, Zabbix añade los siguientes elementos de datos de modo automático para la monitorización y relaciona a ellos con el grupo de elementos de datos. El nombre real del escenario será utilizado en vez de nombre “escenario”. Los siguientes elementos de datos se utilizarían para la creación de triggers y determinación de las condiciones de notificaciones: Elemento de datos
Descripción Este elemento de datos va a recoger la información sobre la velocidad de carga La velocidad (bytes por segundo) de todo el escenario, o sea el indicador medio para todos los de carga pasos. para el escenario Clave de elemento de datos: web.test.in[Scenario,,bps] “Escenario” Tipo: el número con el punto flotante Este elemento de datos guarda la cantidad de los pasos fallidos en el escenario. Si El paso erróneo todos los pasos de escenario se ejecutaron con éxito, este vuelve a cero. en el escenario Clave de elemento de datos: web.test.fail[Scenario] “Escenario” Tipo: números completos Ejemplo 1. Trigger “WEB scenario failed”. La expresión de trigger puede determinarse como: {host: web.test.fail[Scenario]}.last(0)#0. Es importante cambiar el nombre Escenario a un nombre real. Ejemplo 2. Trigger “WEB application is slow”. La expresión de trigger puede determinarse como: {host: web.test.in[Scenario,,bps]}.last(0)<10000. Es importante cambiar el nombre Escenario a un nombre real. Escalados y notificaciones repetidas. Zabbix ofrece una funcionalidad efectiva y flexible para escalados y múltiples notificaciones. Dependiendo de la configuración Zabbix puede escalar de modo automático (aumento del paso de escalado) problemas no resueltos y realizar acciones asignadas para cada paso de escalado. Zabbix soporta los siguientes escenarios de escalados, notificaciones y comandos remotos:
Notificación inmediata a los usuarios sobre nuevos problemas La monitorización proactiva, Zabbix ejecutará cualquier script (comandos remotos) Mensajes repetidos, hasta que no se resuelve el problema Notificaciones apartadas y comandos remotos Escalado de problemas a otros grupos de usuarios Diferentes vías de escalado para los problemas confirmados y no confirmados 15
Ejecución de acciones (ambos tipos de notificación y comandos remotos), si el problema existe más de N horas (segundos, minutos y etc.) Mensajes sobre recuperación a todos usuarios interesados Zabbix soporta una cantidad ilimitada de los pasos en los escalados
Mensajes simples. Aviso importante: Antes de habilitar los mensajes de recuperación o escalado es necesario añadir la condición “Valor de trigger=PROBLEMA” a la acción, al contrario los eventos también serán escalados. Con el fin de avisar a los administradores de MySQL, en cualquier cuestión con addons de MySQL puede usarse la siguiente configuración:
Debido a que no hay interés en enviar varios mensajes o escalar problemas de MySQL u otros grupos de usuarios - no se ha habilitado el escalado. Zabbix enviará un mensaje a los administradores de MySQL y un mensaje sobre recuperación cuando el problema será resuelto. Si el envío de los mensajes sobre recuperación no esta habilitado, Zabbix va a enviar solo un mensaje con la información sobre nuevo problema sin enviar los mensajes sobre recuperación, o sea cuando el problema estará resuelto. Las condiciones para acciones están definidas de tal manera que la acción se va a ejecutar con cualquier problema con MySQL. Es posible utilizar en mensajes los macros. Las acciones están definidas como:
El mensaje se enviará a todos los usuarios del grupo de administradores de MySQL. Comandos remotos. Los comandos remotos son un mecanismo potente para la monitorización proactiva rápida. Zabbix puede ejecutar el comando en el nodo observado en el caso si están definidas algunas condiciones de acciones. Las posibilidades más probables del uso de función de los comandos remotos:
Reiniciación automática de la aplicación (Servidor Web, CRM) si no hay respuesta 16
Uso del comando IPMI 'reboot' para reiniciar el servidor remoto, si este no responde a las peticiones Intentar liberar automáticamente el espacio en el disco (eliminar los ficheros antiguos, limpieza/tmp), si se acaba el espacio en el disco Migración de un VM al otro, dependiendo de la carga de CPU En caso de añadir nodos nuevos si no hay recursos suficientes de CPU (disco, memoria)
La configuración de la acción de los comandos remotos es analógica al envío de mensajes con diferencia de que Zabbix va a cumplir el comando en vez de mandar el mensaje. Esta acción se habilita en el caso cualquier problema emergente en cualquier aplicación de Apache.
Como una reacción a los problemas emergentes, Zabbix va a intentar a reiniciar el proceso Apache. En este caso se utilizaría macros {HOSTNAME}. El usuario 'zabbix' tiene que tener permisos para realizar el script. También el Agente Zabbix tiene que estar arrancado en el nodo remoto y tiene que estar recibiendo las conexiones entrantes. Notificaciones repetidas. Las notificaciones repetidas en Zabbix tienen el uso muy extendido. Primero es importante verificar que los escalados están encendidos en las detalles de la acción. El periodo determina la frecuencia de aumento del paso de escalado en Zabbix. (se cambia al siguiente paso por defecto cada hora, o sea 3600 segundos). Al habilitar escalados, las operaciones de acciones obtienen opciones adicionales: Paso(s), Periodo y Condiciones. Suponemos que es necesario mandar 5 mensajes cada hora, por eso es importante definir que la operación va a estar activa para el escalado desde el paso 1 hasta el paso 5. El periodo de escalado se tomará del periodo de escalado de la acción, si no se indica el periodo individual para cualquier operación.
En cuanto aparece el problema, Zabbix va al paso 1, por eso todas las operaciones definidas en este paso van a ser ejecutadas inmediatamente. Dentro de una hora el periodo de escalado se aumentará de modo automático (si el problema sigue existiendo) y van a ser ejecutadas todas las operaciones del paso 2. Y etc. El mensaje de recuperación se enviará únicamente a las personas que han recibido por lo menos un mensaje al producirse escalado. Si el trigger que provocó el escalado ha sido desconectado, Zabbix enviará el mensaje con la información sobre esto a todos los usuarios que ya recibían los mensajes. Notificaciones con retardo. Los escalados en Zabbix soportan el envío de mensajes con retardo. Si lo que se requiere es recibir los mensajes sobre un problema antiguo con MySQL y el periodo de escalado se cambió en su momento a 10 horas y se utiliza el mensaje cambiado por defecto: 17
La operación pasa únicamente al paso 2, lo que significa que la operación se ejecutará después de un periodo de escalado, o sea dentro de 10 horas. Por eso el usuario recibirá el mensaje únicamente en el caso si el problema existe ya más de 10 horas. El retardo de la notificación controla el periodo de escalado. Escalados al encargado. Los escalados en Zabbix pueden ser utilizados para escalar problemas a otros usuarios o grupos de usuarios. Si el problema no esta resuelta por el administrador – se escala al encargado. Se configura el envío de mensajes periódico por el administrador de MySQL. Los administradores reciben cuatro mensajes antes de que el problema se escale al encargado de base de datos. El encargado recibirá el mensaje únicamente en el caso si el problema todavía no esta confirmada y nadie esta trabajando sobre ella. Importante: se utiliza el macros {ESC.HISTORY} en el mensaje. Macros va a contener la información sobre todos los pasos realizados anteriormente. El encargado recibirá la información a su e-mail sobre todas las acciones realizadas antes de esto. Escenario complejo. El las acciones que se presentan a continuación, después de unos cuantos mensajes a los administradores de MySQL y un escalado al encargado, Zabbix intentará a reiniciar la base de datos MySQL. Esto ocurrirá dentro de 2 horas 30 minutos si el problema existe y no esta confirmado. Si el problema sigue existiendo, dentro de 30 minutos Zabbix enviará el mensaje al usuario. Si esto tampoco ayude dentro de una hora Zabbix reiniciará el Servidor con la base de datos MySQL usando comandos IPMI.
3. Gestión de Configuraciones. Macros. Zabbix soporta varios macros que pueden ser utilizados en diferentes situaciones permitiendo ahorrar el tiempo y hacer la configuración de Zabbix más transparente. Los macros para las firmas de los nodos se soportan desde la versión 1.8. Para ofrecer mayor flexibilidad, Zabbix puede soportar los 18
macros globales y los macros a nivel de nodos de la red y también a nivel de plantillas. Estos macros tienen una sintaxis especial: {$MACRO}. Los macros se pueden utilizarse en las claves de elementos de datos y en las expresiones de los triggers. Los siguientes símbolos se permiten en las expresiones de los macros: A-Z , 0-9 , _ , . Zabbix reemplaza los macros en el siguiente orden: 1. Macros del nodo de red (se verifican como primeros) 2. Macros asignado a la plantilla del nodo. Zabbix va a verificar las plantillas más profundamente tomando en cuenta las plantillas. 3. Macros globales (se verifican como últimos) En otras palabras si el macros no existe para el nodo, Zabbix intentará a encontrarlo en la plantilla del nodo. Si este no se encuentra, se utilizará la plantilla global, en el caso de existir. Y si es imposible encontrarlo, el macros será reemplazado. Los macros globales y los macros a nivel de los nodos son un método perfecto de hacer el soporte de la configuración de Zabbix mucho más sencillo. Los casos de uso de los macros globales y los macros a nivel de nodos de red: 1. Se usan plantillas con unos atributos específicos para el nodo: contraseñas, números de puertos, nombres de ficheros, expresiones regulares y etc. 2. Los macros globales para un cambio de configuración global a través de un click y una configuración más fina. Ejemplo 1. El uso de macros en la clave de elemento de red “Status of SSH daemon”: ssh,{$SSH_PORT} Ejemplo 2. El uso de macros a nivel del nodo de red en el trigger “CPU load is too high”: {ca_001:system.cpu.load[,avg1].last(0)}>{$MAX_CPULOAD} Ejemplo 3. El uso de dos macros en el trigger “CPU load is too high”: {ca_001:system.cpu.load[,avg1].min({$CPULOAD_PERIOD})}>{$MAX_CPULOAD} Importante: Macros puede ser utilizado como un parámetro de la función del trigger, en este ejemplo la función min(). Configuración de MySQL. De diferentes tipos de sistemas de gestión de bases de datos, MySQL es la más robusta y es recomendable su uso con Zabbix para optimizar el rendimiento. El fichero de configuración misc/conf/zabbix_agentd.conf contiene una lista de los parámetros que pueden usarse para realizar observación sobre MySQL. ### Set of parameter for monitoring MySQL server (v3.23.42 and later) ### Change -u and add -p if required #UserParameter=mysql[ping],mysqladmin -uroot ping|grep alive|wc -l #UserParameter=mysql[uptime],mysqladmin -uroot status|cut f2 -d”:”|cut -f1 -d”T” #UserParameter=mysql[threads],mysqladmin -uroot status|cut f3 -d”:”|cut -f1 -d”Q” #UserParameter=mysql[questions],mysqladmin -uroot status|cut f4 -d”:”|cut -f1 -d”S” #UserParameter=mysql[slowqueries],mysqladmin -uroot status|cut f5 -d”:”|cut -f1 -d”O” #UserParameter=mysql[qps],mysqladmin -uroot status|cut -f9 d”:” #UserParameter=version[mysql],mysql –V mysql[ping] - Para revisar si MySQL esta operativo. Resultado: 0 – no iniciado 1 - operativo mysql[uptime] - Cantidad de segundos desde el momento de inicio de MySQL mysql[threads] - Cantidad de flujos de MySQL mysql[questions] - Cantidad de peticiones procesadas mysql[slowqueries] - Cantidad de peticiones lentas 19
mysql[qps] - Peticiones por segundo mysql[version] - Versión. Por ejemplo, mysql Ver 11.16 Distrib 3.23.49, para pc-linux-gnu (i686) Almacenamiento de datos de configuración. Zabbix utiliza la base de datos para almacenar definiciones de configuración, pero no permite modificarla directamente. Por lo tanto, todos los cambios de configuración deben realizarse a través de la interfaz gráfica de usuario, o por las importaciones XML. La manipulación directa de la base de datos no parece ser una práctica común por parte de usuarios de Zabbix. Descubrimiento de red. El modulo de descubrimiento de Zabbix tiene varios objetivos:
Simplificar el despliegue. (La detección de la red puede usarse para simplificar y acelerar el despliegue de Zabbix. Esta característica también da posibilidad al usuario de crear unos dispositivos cómodos). Simplificar la administración. (El módulo de detección correctamente configurado simplifica significativamente la administración del sistema Zabbix). Soporte en los cambios del entorno. (La detección de red hace posible el uso de Zabbix en un entorno que cambia rápidamente sin la necesidad de administración excesiva).
Zabbix proporciona un descubrimiento de dispositivos de red eficiente y muy flexible. El descubrimiento de dispositivos de red Zabbix se basa en la siguiente información: • Rangos IP • Acceso a servicios externos (FTP, SSH, WEB, POP3, IMAP, TCP, y etc.) • Información recibida de Agente Zabbix • Información recibida de Agente SNMP Descubrimiento no ofrece la detección de la topología de red. Cada servicio y nodo de red IP, revisado por el módulo de descubrimiento Zabbix, genera eventos que se pueden utilizar en crear reglas para siguientes acciones: • Generar informes a los usuarios • Agregar y eliminar nodos • Habilitar y deshabilitar los nodos • Agregar nodos a un grupo de nodos de la red • Eliminar nodos de un grupo de nodos de la red • Conectar a los nodos con una plantilla • Desconectar a los nodos de la plantilla • Ejecución de scripts a distancia Las acciones pueden ser configuradas en relación de los nodos de red o tiempo de disponibilidad y tiempo de indisponibilidad del servicio. Si el servidor de Zabbix tiene incorporado soporte de IPv6 y fping6 no esta disponible, las revisiones con ICMP para IPv4 dispositivos tampoco funcionarán. Sólo desde la versión 1.8.2 direcciones IPv4 se procesan a través fping, con fping6 inaccesible. El descubrimiento de red se basa en dos componentes: la detección y la acción. En primer lugar, se detecta el nodo en la red o servicio y se genera un evento o eventos de descubrimiento. Luego los eventos se procesan y se aplican las acciones determinadas en función del tipo de dispositivo detectado, IP, su estado, disponibilidad de tiempo/indisponibilidad, y etc. 20
Detección. Zabbix periódicamente escanea los rangos IP especificados en las normas de detección. La frecuencia de escaneo se ajusta para cada regla individualmente. Cada regla define un conjunto revisiones de servicios que tienen que realizarse en un rango IP. Eventos generados por el módulo de descubrimiento de red están en el "descubrimiento". Zabbix genera los siguientes eventos: Evento Servicio esta disponible Servicio indisponible Host disponible Host indisponible Servicio detectado Servicio perdido El nodo detectado El nodo perdido
Cuando se realiza Siempre cuando se detectan los servicios Zabbix activos. Siempre cuando no es posible detectar el servicio Zabbix. Si por lo menos un servicio esta activo para IP. Si no hay respuesta de ningún servicio. Si el servicio ha vuelto ser disponible tras indisponibilidad o ha sido detectado por primera vez. Si el servicio se perdió después de estar activo. Si el nodo ha vuelto de estar disponible tras indisponibilidad o ha sido detectado por primera vez. Si el nodo se perdió después de estar activo.
Acciones. Zabbix reacciona a los eventos mediante la realización de muchas operaciones. Las acciones se pueden definir para cualquier evento o eventos, o grupo de eventos generados por Zabbix. Atributos de Acción: Parámetro Nombre
Descripción
El nombre único de la acción. La fuente del evento. Actualmente se soportan varias fuentes: Triggers – eventos generados por el cambio de estado de los triggers. Evento Descubrimiento – eventos generados por el modulo de autodetección. Registración automática – eventos generados por los agentes nuevos activos. Si esta habilitado, la acción será escalada según los pasos de las operaciones Habilitar determinadas para condiciones de eventos. escalado Periodo (segundos) El intervalo de tiempo para avanzar al siguiente paso en el escalado. Tema por defecto Tema de notificación por defecto que puede contener los macros. Mensaje por Mensaje de notificación por defecto que puede contener macros. defecto Si esta habilitado, Zabbix va a mandar el mensaje tras solucionar el problema a Mensaje de los que recibieron notificaciones sobre este problema antes. recuperación Tema de Tema del mensaje de recuperación que puede contener macros. recuperación Estado de la acción: Activado – acción habilitada Estado Desactivado – acción deshabilitada 21
Importante: Antes de habilitar los mensajes de recuperación o escalado, hay que asegurarse de que en la acción esta añadida condición de "significado de trigger = PROBLEMA", de lo contrario los acontecimientos pueden convertirse en escalados. Condiciones de las acciones. La acción se ejecutará sólo si se cumplen una serie de condiciones. Las siguientes condiciones pueden ser definidas para los eventos de los triggers: Operadores soportados
Tipo de condición
Grupo de elementos de datos
= contiene no contiene
Grupo de nodos de red
= <>
Plantilla del nodo de = <> la red
Nodo
= <>
Trigger
= <>
Descripción de trigger (nombre)
contiene no contiene
Importancia de trigger
= <> >= <=
Significado de trigger = Periodo de tiempo
en fuera
Descripción = - evento ocurrió por causa de trigger que es parte del grupo de elementos de datos. contiene – evento ocurrió del trigger que es parte del grupo de elementos de datos que contiene la línea indicada. no contiene - evento ocurrió del trigger que es parte del grupo de elementos de datos que no contiene la línea indicada. Compara si existe en el grupo de nodos de la red el trigger que generó el evento. = - Evento generado por el grupo de nodos indicado. <> - Evento generado por el grupo de nodos no indicado. Compara si existe en la plantilla de nodo de la red el trigger que generó el evento. = - Evento generado por el trigger de la plantilla del nodo indicado. <> - Evento generado por trigger que no esta en plantilla. Compara si existe el trigger que generó el evento en el nodo. = - Evento generado desde el nodo indicado. <> - Evento generado desde el nodo no indicado. Comparación del trigger indicado con el trigger que genero el evento. = - Evento generado por el trigger indicado. <> - Evento generado por el trigger no indicado. Compara si coincide el nombre de trigger con el nombre de trigger que generó el evento. contiene – la línea esta encontrada en el nombre de trigger. no contiene – la línea no encontrada en el nombre de trigger. Comparación con la importancia de trigger. = - igual a importancia de trigger <> - no igual a la importancia de trigger >= - igual, o incluso es un trigger más importante <= - igual, o es un trigger menos importante Comparación con el significado de trigger = - igual al significado de trigger (OK o PROBLEMA) en – Evento ocurrió en el periodo de tiempo indicado que tiene formato: dd-dd,hh:mm-hh:mm;dd-dd,hh:mm:hh:mm; 22
Estado de mantenimiento
= <>
Compara si el nodo se encuentra en el mantenimiento. = - Nodo se encuentra en el mantenimiento. <> - Nodo no se encuentra en el mantenimiento.
Significado de trigger. El estado de trigger se cambia de FALSE a TRUE (significado de trigger TRUE). El estado de trigger se cambia de TRUE a FALSE (significado de trigger FALSE). Si el estado de trigger esta cambiando FALSE→UNKNOWN→TRUE, entonces se interpreta como FALSE →TRUE, y si el estado cambia TRUE→UNKNOWN→FALSE, se interpreta como TRUE→FALSE. Las condiciones de acciones que se presentan a continuación pueden definirse para eventos de descubrimiento: Tipo de Operadores Descripción condición soportados Comprueba si la dirección IP del nodo localizado corresponde o no con el = rango indicado. IP de nodo <> = - IP de nodo corresponde con el rango. <> - IP de nodo no corresponde con el rango. Comprueba el tipo de servicio de dispositivo localizado. = Tipo de = - coincide el tipo de servicio de dispositivo localizado. <> servicio <> - no coincide el tipo de servicio de dispositivo localizado. Comprueba si el puerto TCP corresponde o no con el rango indicado. Puerto de = = - puerto corresponde con el rango. <> servicio <> - puerto no corresponde con el rango. Comprueba si el nodo localizado corresponde con la regla de detección = Regla de indicada. <> = - no corresponde con la regla de detección indicada. detección <> - corresponde con la regla de detección indicada. Comprueba el nodo localizado corresponde con la revisión de detección indicada. Revisión de = <> detección = - corresponde con la revisión de detección indicada. <> - no corresponde con la revisión de detección indicada. Objeto = Comprueba que es el objeto localizado, dispositivo o servicio. detectado Up – Evento de estado de detección coincide con “accesible”. Down – Evento de estado de detección coincide con “no accesible”. Estado de = detección Localizado – Evento de estado de detección coincide con “localizado”. Perdido – Evento de estado de detección coincide con “perdido”. Tiempo de inaccesibilidad para eventos de inaccesibilidad de nodo o servicio. Tiempo de accesibilidad para eventos de accesibilidad de nodo o Accesible/ >= servicio. Inaccesible <= >= - accesible/inaccesible igual o más <= - accesible/inaccesible igual o menos. (parámetro en segundos) Comparación de líneas con el valor recibido del agente (Zabbix, SNMP). = = - igual al valor <> <> - no igual al valor >= Valor >= - igual o más que el valor <= obtenido <= - igual o menos que el valor no contiene contiene – como sublínea contiene no contiene – no como sublínea. (parámetro como valor de línea) 23
Comprueba detrás de que Zabbix Proxy se detectó el objeto. = - corresponde con servidor Proxy indicado. <> - no corresponde con servidor Proxy indicado.
= <>
Proxy
Las condiciones de acciones que vienen a continuación pueden ser determinadas para eventos de registración automática: Tipo de condición
Operadores soportados
Nombre de nodo
contiene no contiene
Proxy
= <>
Descripción Comprueba si el objeto localizado contiene en el nombre de nodo la información indicada. contiene – el nodo contiene en el nombre la información indicada. no contiene - el nodo no contiene en el nombre la información indicada. Comprueba detrás de cual Zabbix Proxy esta localizado el objeto. = - corresponde con el servidor Proxy indicado. <> - no corresponde con el servidor Proxy indicado.
Por ejemplo, las siguientes condiciones tienen el tipo de cálculo AND/OR:
Grupo de nodos = Oracle servers Grupo de nodos = MySQL servers Nombre de trigger contiene ‘Database is down’ Nombre de trigger contiene ‘Database is unavailable’
Que equivale a: (Grupo de nodos = Oracle servers o Grupo de nodos = MySQL servers) y (Nombre de trigger contiene 'Database is down' o Nombre de trigger contiene 'Database is unavailable') Operaciones. Operaciones o conjunto de operaciones se ejecutan cuando coinciden las condiciones de acción. Zabbix soporta las operaciones siguientes:
Envío de mensaje. Ejecución de comando(s), habilitando IPMI.
Para envío y lectura de e-mail desde Zabbix con éxito, los servidores/clientes de e-mail tienen que soportar estándar 'SMTP/MIME e-mail', por Zabbix envía los datos UTF-8 en este formato. Empezando por la versión 1.8.2, el asunto y el cuerpo del mensaje se codifican en base64 para soportar estándar 'SMTP/MIME e-mail'. A continuación se presentan las operaciones adicionales disponibles para eventos de descubrimiento:
Añadir nodo Eliminar nodo Habilitar nodo Deshabilitar nodo Añadir al grupo Eliminar del grupo Unir con la plantilla Desadjuntar de la plantilla 24
Al agregar el nodo, su nombre se extraerá de la función estándar gethostbyname. Si el nodo se resuelve, entonces se utiliza el nombre de dominio. Si no es así, se utiliza la dirección IP. Además, si la dirección IPv6 se utiliza como el nombre de nodo, entonces todos ":" (dos puntos) se sustituyen por "_" (barra baja), debido a que ":" (dos puntos) no están permitidos en el nombre de los nodos de la red. Si la detección ha funcionado a través del Proxy, el nombre actual del nodo se coloca también en el servidor de Zabbix. Si un nodo recién detectado ya existe en la configuración de Zabbix con el mismo nombre, entonces las versiones de Zabbix anteriores a 1.8 añaden este segundo nodo con el mismo nombre a la red. Zabbix 1.8.1 agrega _N al final del nombre del nodo, donde N es un número que aumenta, empezando en 2. Parámetro Paso
Tipo de operación
Descripción Si esta habilitado el escalado para esta acción, existe siguiente configuración: С – ejecutar en cada paso empezando por el primero. К – hasta este (0, para todos pasos empezando por С) Periodo – aumento del paso después de periodo determinado, 0 – periodo por defecto. Tipo de acción: Enviar el mensaje – envío de mensaje a usuario Comando remoto – ejecutar el comando remoto
Fuente del evento Enviar mensaje: Enviar mensaje Usuario único – para usuario único. Grupo de usuarios – para todos los miembros de grupo de usuarios. Mensaje por Si esta seleccionado, se usará el mensaje por defecto. defecto Enviar Selección de los medios de comunicación para enviar el mensaje (todos o uno). únicamente Tema de mensaje que puede contener macros. Tema Mensaje directo que puede contener macros. Mensaje Comando La lista de comandos remotos. remoto Se utiliza en una acción escalada con un trigger que funcionó. Puede tomar valores Condiciones para confirmar el evento de trigger “No confirmado” o “Confirmado”. Empezando por la versión 1.6.2, Zabbix envía notificaciones solo a los usuarios que tienen por lo menos los permisos de lectura para el nodo (trigger), que generó el evento. Por lo menos un nodo de la expresión de trigger tiene que estar disponible al usuario. Regla de descubrimiento de red. Regla de descubrimiento de red - es una regla que utiliza Zabbix para descubrir nodos y servicios. Los parámetros de descubrimiento de red: Parámetro Nombre
Descripción Nombre de la regla. Por ejemplo, “Local network”. 25
Rango IP
Rango de direcciones IP para descubrimiento. Puede tomar los siguientes formatos. Una IP: 192.168.1.33 Rango de direcciones IP: 192.168.1.1-255 Rango IP con mascara: 192.168.4.0/24 Lista: 192.168.1.1-255,192.168.2.1-100,192.168.2.200,192.168.4.0/24
Retraso (en segundos)
Este parámetro determina con que frecuencia Zabbix va a cumplir esta regla.
Revisiones
Criterio de singularidad del dispositivo Estado
Zabbix va a usar esta lista de revisiones para detección de nodos y servicios. La lista de revisiones soportadas: SSH, LDAP, SMTP, FTP, HTTP, POP, NNTP, IMAP, TCP, Agente Zabbix, Agente SNMPv1, Agente SNMPv2, Agente SNMPv3 El parámetro de puertos puede tomar siguientes significados: Un puerto: 22 Rango de puertos: 22-45 Lista: 22-45,55,60-70 Criterio de singularidad puede ser según: Dirección IP – no se tratan los dispositivos con varias direcciones IP. Una de las revisiones de descubrimiento – se basará en una revisión SNMP o en una revisión de Agente Zabbix. Activo – esta regla esta activa y va a cumplirse por el servidor Zabbix. Desactivado – esta regla no esta activa y no se cumplirá.
Por ejemplo, suponemos, que se requiere configurar el descubrimiento de una red de área local con el rango IP: 192.168.1.1-192.168.1.255. En este caso es preferible:
Detectar únicamente aquellos nodos que disponen de Agente Zabbix Iniciar el descubrimiento cada 10 minutos. Añadir el nodo para observación si el tiempo de trabajo de nodo es mayor a 1 hora Eliminar el nodo si este es indisponible durante más de 24 horas Utilizar Template_Windows para los nodos de Windows Utilizar Template_Linux para los nodos de Linux Añadir los nodos de Linux al grupo de “Linux servers” Añadir los nodos de Windows al grupo de “Windows Servers”
Paso 1. Se establece una regla de descubrimiento de red para un rango de direcciones IP dado. Zabbix intentará a detectar los nodos en el rango de direcciones IP 192.168.1.1-192.168.1.255, intentando a conectarse al Agente Zabbix y obtener el significado de la clave system.uname. Al obtener el significado del Agente puede utilizarse para crear las acciones diferentes para sistemas operativas diferentes. Por ejemplo, unir los servidores de Linux con la plantilla Linux_Template. La regla tiene que cumplirse cada 10 minutos (600 segundos). Cuando la regla se añade, Zabbix iniciará el descubrimiento automáticamente y generará los eventos basados en detección para su elaboración posterior. Paso 2. Se definen las acciones para añadir nuevos servidores de Linux detectados. Esta acción se ejecuta si:
El servicio de Agente Zabbix esta disponible El significado de system.uname (la clave del Agente Zabbix se utilizó para crear la regla) contiene “Linux” Tiempo de trabajo es mayor de 1 hora (3600 segundos)
26
Esta acción va a ejecutar las siguientes operaciones:
Añadir nuevo nodo detectado al grupo “Linux servers” (añade el nodo si este no fue añadido a este grupo antes) Unir con plantilla “Template_Linux”. Zabbix iniciará la observación del nodo automáticamente usando los elementos de datos y los triggers de la plantilla “Template_Linux”.
Paso 3. Se definen las acciones para añadir nuevos servidores Windows detectados. Paso 4. Se definen las acciones para eliminar los servidores perdidos. El servidor se eliminará si el servicio Agente Zabbix estará indisponible durante más de 24 horas (86400 segundos). Nodos y dependencias de triggers. Zabbix no soporta las dependencias de los nodos de red. Dependencias entre los nodos de red se podría determinar usando una opción más flexible, es decir, dependencias de triggers. El trigger puede tener la lista de uno o más triggers dependientes. Esto significa que el trigger va a cambiar su estado, independientemente del estado de triggers en la lista, aunque no generará alertas y acciones en caso de que uno de los triggers de la lista obtendra el valor TRUE. Por ejemplo, suponemos que disponemos de dos nodos: router y servidor. El servidor se encuentra detrás del router, por eso es preferible estar recibiendo solo una notificación en el caso de que router no esta disponible: “The router is down”, en vez de: “The router is down” y “The host is down”. Para conseguir esto se crea una dependencia en trigger: "The host is down" depende de "The router is down". Ahora, en el caso de que servidor y router van a ser indisponibles, Zabbix no va a ejecutar acción para trigger “The host is down”.
4. Gestión de Seguridad. Entrada al sistema. Para entrar en el sistema, Zabbix requiere autentificación. Aparece una pantalla, como la que viene a continuación, que pide nombre de usuario y contraseña. Después de instalación para entrar en el sistema como Superusuario hay que introducir el nombre de usuario “Admin” seguido de la contraseña “zabbix”.
Al entrar aparece “Conected as Admin” y se ofrece el acceso a áreas de “Configuración” y “Administración”. Protección contra ataques de fuerza bruta. En el caso de cinco fallidos intentos realizados de manera seguida, la interfaz de Zabbix tomara una pausa de 60 segundos durante los siguientes 15 minutos para prevenir los ataques mediante fuerza bruta y ataques por el diccionario. Se reflejará la dirección IP del intento anterior fallido después de la autentificación exitosa. 27
Permisos de los usuarios. Todos los usuarios en Zabbix tienen acceso a la aplicación Zabbix a través de interfaz Web. A cada usuario en Zabbix se le asigna un nombre de usuario y contraseña únicos. Todas las contraseñas de usuarios están encriptadas y se guardan en la base de datos de Zabbix. Los usuarios no pueden utilizar su nombre de usuario y contraseña para entrar directamente al servidor UNIX si estas no han sido creadas con antelación de manera correspondiente en UNIX. La comunicación entre el Servidor Web y navegador de usuario puede estar protegida por el medio de SSL. Los permisos de acceso a la página de administración pueden establecerse para cada usuario. Por defecto un usuario no tiene derechos de acceso a las páginas de Zabbix después de registrarse. El usuario se desconecta de interfaz Web de manera automática tras inactividad de 30 minutos (este parámetro se puede configurar de manera más fina para cada usuario). Zabbix dispone de un esquema flexible de los permisos de usuario que puede ser usada de manera efectiva en gestión de derechos de usuarios, en gestión de permisos de servidor Zabbix individual o en la monitorización distribuida. Los permisos se asignan a los grupos de usuarios a nivel de grupos de nodos. Zabbix soporta varios tipos de usuarios. El tipo de usuario es una definición de las funciones administrativas a cuales el usuario tiene permiso. Tipos de usuarios. Los tipos de usuarios se utilizan para obtener el acceso a las funciones administrativas y señalan los derechos por defecto. Tipo de usuario Usuario Zabbix Administrador Zabbix Superadministrador Zabbix
Descripción El usuario tiene acceso al área de Monitorización. Por defecto el usuario no tiene derechos de acceso a los recursos. Los derechos de acceso al grupo de nodos de la red tienen especificarse de manera explicita. El usuario tiene acceso al área de Monitorización y Configuración. Por defecto el usuario no tiene derechos de acceso a los recursos. Los derechos de acceso al grupo de nodos de la red tienen especificarse de manera explicita. El usuario tiene acceso a cualquier área: Monitorización, Configuración y Administración. El usuario tiene permisos de lectura y escritura a todos los grupos de nodos de la red. El permiso no puede denegarse para cualquier grupo de nodos de la red.
Modo de mantenimiento de Zabbix GUI. Zabbix GUI puede desconectarse temporalmente para denegar el acceso desde exterior al interfaz Web. Esto es muy útil para proteger la base de datos de Zabbix de cualquier cambio iniciado por el usuario y evitar de esta manera los cambios indeseados (violación de integridad). Base de datos puede ser detenida mientras Zabbix Gui se encuentra en el modo de mantenimiento. Objetivos del modo mantenimiento. • Protección de base de datos de Zabbix de cualquier cambio iniciado por los usuarios • Realizar el mantenimiento de base de datos • Informar a los usuarios acerca de la causa de los trabajos programados • Usuarios del rango de direcciones determinado tendrán la oportunidad de trabajar con GUI en el proceso de mantenimiento • Retorno automático al modo normal terminando el mantenimiento 28
Configuración. Para encender el modo de mantenimiento, el fichero “conf/maintenance.conf.php” tiene que modificarse de siguiente manera: // Modo de mantenimiento define('ZBX_DENY_GUI_ACCESS',1); // Rango IP, que tendrá permiso de acceso a interfaz WEB $ZBX_GUI_ACCESS_IP_RANGE = array('127.0.0.1'); // El mensaje de Aviso que saldría en la pantalla $_REQUEST['warning_msg'] = 'Zabbix is under maintenance.'; Parámetro Detalles Para encender el modo de mantenimiento: 1 – el modo de mantenimiento esta encendido, esta apagado con ZBX_DENY_GUI_ACCESS cualquier valor que no es 1. El acceso desde estas direcciones IP será permitido en el modo de mantenimiento. ZBX_GUI_ACCESS_IP_RANGE Por ejemplo: 192.168.1.1-255 El mensaje informativo. warning_msg La siguiente pantalla aparecerá mientras el servidor se encuentra en el modo de mantenimiento. La pantalla se renueva cada 30segundos, para poder volver al modo normal después de terminar el mantenimiento.
5. Gestión de Prestaciones. TI servicios. Zabbix dispone de TI servicios que están dirigidos a los que quieren obtener la monitorización de más alto nivel (bussiness). Habitualmente, la información relacionada con la falta de espacio en el disco, alta carga de procesador y otra, no despierta gran interés. Los detalles de gran importancia resultan ser la accesibilidad a los servicios ofrecidos, localización de debilidades en la infraestructura TI, SLA de diferentes servicios TI, estructura de la existente infraestructura TI y cualquier otra información de alto nivel. TI-servicios dan la respuesta a todas las preguntas planteadas arriba y son una presentación jerárquica de los datos de monitorización. Una estructura muy simple de TI-servicio puede presentarse de siguiente manera: TI ser vi ci o | | - Est aci ones acti vas | | | | - Wor kst at i on1 | | | | - Wor kst at i on2 | | - Ser vi dor es
29
Cada nodo de la estructura tiene un atributo de estado. Estado se calcula y se extiende a los niveles superiores en relación con el algoritmo elegido. Los triggers crean un nivel bajo de TIservicios. Hasta la versión Zabbix 1.8.1 los triggers con importancia Sin Clasificar y Informacional no influyen al calculo de SLA. Informes y presentación de diapositivas. Los informes en Zabbix son muy completos y permiten agrupar diferente información de un acceso rápido en la pantalla única. Fácil de usar, el informe es simple, intuitivo y claro. La cantidad de elementos en cada informe no esta limitada. El informe es una tabla que puede contener en cada casilla la siguiente información:
gráficos simples gráficos de usuario mapas otros informes información en texto información sobre servidor información sobre triggers información general de datos reloj historial de eventos historial de acciones URL (los datos se toman de otro lugar)
La presentación de diapositivas representa un conjunto de los informes que van a presentarse automáticamente de acuerdo con la configuración del intervalo de renovación. Parámetro Nombre Intervalo de renovación (en seg.) Diapositivas Informe Retraso
Descripción Nombre de presentación de diapositivas. Este parámetro establece un intervalo por defecto entre rotaciones de los informes en segundos. La lista de diapositivas individuales (informes). Nombre del informe. Duración de presentación del informe en segundos. Con valor 0 se utilizará el intervalo general de renovación de diapositivas.
30
Por ejemplo: Presentación de diapositivas “Zabbix administrators”. Presentación de diapositivas consiste en dos informes que se presentarán en el siguiente orden: Zabbix Server ⇒ Pausa de 60 seg. ⇒ Zabbix Server2 ⇒Pausa de 30 seg. ⇒ Zabbix Server ⇒Pausa de 60 seg. ⇒ Zabbix Server2 ⇒ … Grupos de elementos de datos. Grupo de elementos de datos es un conjunto de elementos de datos de un nodo. Por ejemplo, un grupo de elementos de datos "MySQL Server” puede contener todos los elementos de datos que están relacionados con servidor MySQL: la disponibilidad de MySQL, el tamaño de espacio en disco, uso de CPU, operaciones por segundo, el número de consultas lentas, y etc. Elemento de datos puede estar asociado con uno o varios grupos de elementos de datos. Los grupos de elementos de datos se utilizan en la interfaz Web de Zabbix para la agrupación de elementos de datos. Actualmente, el nodo no se puede conectar con diferentes plantillas que tienen los mismos grupos de elementos de datos. Visualización de Colas. En la cola de Zabbix se muestran los elementos de datos que esperan actualizaciones. Las colas son una representación lógica de los datos en la base de datos. Estadísticas de la cola es un buen indicador del rendimiento del servidor Zabbix. La cola en una única aplicación o en el nodo maestro muestra los elementos que están a la espera de la actualización.
En este caso, se observa que hay cero elementos del tipo Agente Zabbix que esperan a la actualización 0-5 segundos, que hay cero elementos del tipo Agente Zabbix (activo) esperando más de cinco minutos. Hay que tener en cuenta que la información en el nodo esclavo no se muestra en la última actualización. El nodo maestro recibe los datos de historial con cierto retraso (normalmente hasta 10 segundos debido a la transferencia de datos entre nodos), que significa que la información se puede entregar con un retraso.
31
En la imagen anterior se muestra que hay 93 elementos de datos que están esperando más de 5 minutos para las actualizaciones en el nodo esclavo. Pero es preferible no confiar demasiado de esta información, ya que su fiabilidad depende de:
Rendimiento del nodo esclavo Comunicación entre nodo maestro y nodos esclavos Posible falta de correspondencia en la hora y fecha local entre el nodo maestro y nodos subordinados
Un elemento de datos especial con la clave zabbix[queue] puede ser utilizado para monitorizar el estado de la cola de Zabbix. Monitorización de log-ficheros. Zabbix puede ser usado para monitorizar y analizar los log-ficheros con/sin soporte de rotación de registros. Puede utilizarse notificaciones para avisar al usuario si el log-fichero contiene varias líneas o plantillas de líneas. La monitorización de log-ficheros requiere que el agente Zabbix este en marcha en el nodo remoto de red. El elemento de datos que se utiliza para monitorizar el log-fichero debe ser de tipo Zabbix Agente (Activo), su tipo de valor debe ser Registro y la clave tiene que establecerse como log[fichero<,plantilla><,codificación><,cantidad max de líneas>] o logrt[ruta al fichero de registro con el nombre de fichero formateado<,plantilla><,codificación><,cantidad max de líneas>].
Por ejemplo: log["/home/user/file.log","pattern_to_match","UTF-8",100], o logrt["/home/user/filelog_.*_[0-9]{1,3}","pattern_to_match","UTF-8",100] El último ejemplo va a recoger datos de los ficheros como “filelog_abc_1” o “filelog__001”. Importante: • El servidor y el agente hacen seguimiento del tamaño del registro observado y del tiempo de la última modificación (para logrt) con dos contadores. • El agente comienza a leer el log-fichero desde el punto donde se detuvo la última vez. • El número de bytes ya revisados (contador de tamaño), y la hora de la última modificación (contador de tiempo) se almacenan en la base de datos de Zabbix y se envían al agente para asegurarse de que este empieza a leer el log-fichero desde ese punto. • Siempre cuando el log-fichero se pone menor que el valor del contador del tamaño conocido por el agente, el contador se pone a cero, y el agente comienza a leer el log-fichero desde el principio pasando el contador de tiempo al servidor. • Todos los ficheros que corresponden con el nombre de archivo en la carpeta se analizan en cada ciclo y el agente intenta obtener siguiente línea del archivo de registro (para logrt). • Si hay varios log-ficheros con el mismo tiempo de los últimos cambios en la carpeta, el agente leerá el lexicográficamente menor. • Agente Zabbix procesa las nuevas entradas de log-ficheros una vez por periodo de renovación de segundos. • Agente Zabbix no envía más de maxlines de log-fichero por segundo. Restricción evita la congestión de red y recursos de la CPU, y redefine la opción por defecto determinado por el parámetro MaxLinesPerSecond en archivo de configuración del agente. Parámetros del usuario. Funcionalidad de los Agentes Zabbix puede ser mejorada mediante la definición de los parámetros de usuario (UserParameter) en el fichero de configuración del agente. Los parámetros de usuario en los comandos se ejecutan por el Agente Zabbix. En UNIX se utiliza e l interpretador de línea 32
de comandos /bin/sh. A fin de establecer nuevos parámetros para la monitorización hay que añadir una sola línea en el fichero de configuración de Agente Zabbix y reiniciarlo. El parámetro de usuario tiene la siguiente sintaxis: UserParameter = la clave, comando Parámetro Descripción La clave única de elemento de datos. Clave Comando El comando que se ejecutará para obtener el significado de la clave. Por ejemplo: UserParameter=mysql.ping,mysqladmin -uroot ping|grep alive|wc –l El agente va a devolver '1', si el servidor MySQL esta disponible, '0' – en el caso contrario. Parámetros de usuario flexibles. Los parámetros de usuario flexibles pueden ser utilizados para aumentar el control y flexibilidad. Para los parámetros de usuario flexibles, UserParameter=clave[*],comando Parámetro Descripción La clave única de elemento de datos. [*] determina si la clave puede tomar parámetros. Clave Comando que va a ejecutarse para obtener el significado de la clave. El agente Zabbix Comando puede distinguir el contenido de [] y cambiar $1,…,$10 en el comando. Por ejemplo: UserParameter=mysql.ping[*],mysqladmin –u$1 –p$2 ping|grep alive|wc –l Este parámetro puede ser utilizado para monitorizar la disponibilidad de la base de datos MySQL. Se puede transmitir el nombre de usuario y contraseña: mysql.ping[zabbix,our_password] Importación y Exportación. Las funciones de Importación/Exportación en Zabbix ofrecen la posibilidad del cambio de diferentes parámetros de configuración. Los datos se exportan al formato XML cual es fácil de leer y cambiar.
Intercambio de plantillas o mapas de las redes. (Los usuarios de Zabbix pueden intercambiar los parámetros de configuración). Integración con los dispositivos externos. (El formato universal XML hace posible la integración e Importación/Exportación de datos con herramientas y aplicaciones externas).
La exportación o importación de los mapas de red esta soportado en Zabbix desde la versión 1.8.2. Actualmente se soportan dos principales categorías de configuración para la exportación – los nodos de red y relacionados con ellos datos con los mapas de red. En Zabbix se pueden Importar/Exportar los siguientes datos:
Nodos y plantillas relacionadas con ellos; Plantillas; Grupos de elementos de datos; Elementos de datos; Triggers; Gráficos de usuario; Configuración de los mapas; Elementos de los mapas (imágenes, triggers, nodos, grupos de nodos y los mapas); Firmas y los indicadores de estado. 33
Se realizaría la exportación únicamente de estructura del mapa o del informe (configuración del mapa/informe, configuración de elementos, indicadores de estado). No se exportarían los grupos de nodos, nodos, triggers, imágenes, lo que significa que si por lo menos un elemento del mapa hace referencia al elemento de datos erróneo, la exportación fallará. Plantillas de nodos. El uso de plantillas permite realizar el soporte de Zabbix de una manera mucho más simplificada. La plantilla puede estar relacionada con cualquier número de los nodos en la red. Añade de modo automático los elementos de datos, triggers y gráficos al nodo relacionado. Al cambiar cualquier elemento en la plantilla (trigger, grafico), los cambios se aplicarán automáticamente a los nodos relacionados con la plantilla. Los atributos de las plantillas de nodos: Parámetro Descripción El nombre único de plantilla (nodo). Nombre Lista del grupo de nodos a cuales pertenece la plantilla. Grupo Asignación del grupo nuevo de nodos a la plantilla. Grupo nuevo Relación de plantilla con nodos indicados u otras plantillas. Nodos/Plantillas Relación con plantillas Se utiliza para crear jerarquía de plantillas. El uso de macros a nivel de plantillas. Macros Optimización de rendimiento. Configuración real. Un Servidor con Zabbix 1.0 instalado (RedHat Linux 8.0, kernel 2.4.18-14, MySQL/MyISAM 3.23.54a-4, Pentium IV 1,5 GHz, 256 MB, disco duro IDE) es capaz de recoger más de 200 parámetros por segundo de los servidores monitorizados (con condición de ausencia de retrasos en la red). ¿Cuántos servidores se pueden monitorear usando Zabbix en un hardware determinado? La respuesta depende del número de parámetros controlados y con qué frecuencia Zabbix tendrá que consultar estos parámetros. Si supongamos que cada servidor observa diez parámetros y hay que actualizar estos parámetros una vez cada 30 segundos, tras realizar unos cálculos simples, se ve que el servidor de Zabbix puede manejar 600 (o 6000 controles). Si estos parámetros se deben actualizar una vez por minuto, la configuración de hardware será capaz de manejar 600 × 2 = 1,200 servidores. Estos cálculos se hacen sobre la suposición de que todos los valores observados se obtienen tan pronto como se piden (retardo 0). Si esto no es un requisito la cantidad de los servidores monitorizados se puede aumentar hasta en 5x-10x veces. Optimización de hardware.
Uso del procesador más rápido disponible SCSI o SAS mejor que IDE (el rendimiento de los discos IDE puede mejorarse considerablemente mediante hdparm utillity) y SATA 15K RPM mejor que 10K RPM, que es mejor que 7200 RPM Uso de un almacenamiento rápido RAID Uso de la tarjeta de red rápida Es siempre mejor la disponibilidad de memoria adicional
Optimización de Sistema Operativo.
Uso de la más reciente (estable) versión del sistema operativo Desactivar la funcionalidad del núcleo no necesaria Optimizar los parámetros del núcleo 34
Optimización de los parámetros de configuración de Zabbix. zabbix_server StartPollers. Regla general - mantener el valor de este parámetro lo más bajo posible. Cada unidad adicional de zabbix_server añade ciertos gastos generales, y al mismo tiempo, aumenta el paralelismo. El número óptimo se logra cuando la cola, en promedio, contiene el número mínimo de parámetros (lo ideal, 0 en cualquier momento dado). Este valor puede ser controlado por la revisión interna de zabbix[queue]. DebugLevel El valor óptimo es 3. DBSocket Únicamente para MySQL. Se recomienda usar DBSocket para las conexiones a la base de datos. Es un modo más rápido y más seguro. El motor de la base de datos. Esta es probablemente la parte más importante de la optimización de Zabbix. Zabbix depende mucho de la disponibilidad y el rendimiento de la base de datos.
Uso del motor de la base de datos más rápido, que es MySQL Utilice la versión estable del motor de base de datos Para obtener el rendimiento máximo se puede reconstruir el MySQL o PostgreSQL desde el código fuente siguiendo las instrucciones para optimizar el rendimiento de la documentación de MySQL o PostgreSQL Uso de la estructura de tablas InnoDB para MySQL (Zabbix funciona al menos 1,5 veces más rápido (en comparación con MyISAM) si se usa InnoDB. Sin embargo, InnoDB requiere más recursos de la CPU. Dispersión de las tablas de la base de datos en diferentes discos duros ('history', 'history_str, 'items' 'functions', triggers', y 'trends' son las tablas que se usan de modo más activo). Para grandes instalaciones, se recomienda usar en MySQL para los archivos temporales el tmpfs
Consejos generales para optimizar el rendimiento:
Monitorizar solo los parámetros necesarios. Optimizar el “intervalo de actualización” para todos los elementos de datos. El ajuste de un intervalo de actualización pequeño puede ser bueno para los gráficos bonitos, pero va a recargar demasiado a la herramienta. Optimizar parámetros por defecto para las plantillas. Optimizar parámetros de la limpieza de historial. No utilizar los parámetros que devuelven la misma información. Por ejemplo: No hace falta utilizar system.cpu.util[,user,avg10] y system.cpu.util[,user,avg15] porque system.cpu.util[,user,avg1] contiene todas las opciones enumeradas anteriormente. Evitar el uso de triggers con un periodo largo enviado como argumento de la función. Por ejemplo, max (3600) se calculará mucho más despacio que el max (60).
Rendimiento en monitorización distribuida. Cada nodo requiere más recursos para procesamiento en una instalación distribuida. El nodo maestro debe ser lo suficientemente potente para manejar y almacenar no sólo los datos locales, pero los datos de todos sus nodos secundarios. La comunicación entre nodos también debe ser lo suficientemente rápido para la transferencia oportuna de nuevos datos. 35
Proxy. Zabbix Proxy puede simplificar de manera significativa el soporte para el entorno de Zabbix e incrementar la productividad del servidor central. Además, el uso de Zabbix Proxy es la forma más fácil de realizar la monitorización centralizada y distribuida, cuando todos los agentes y proxy se gestionan por un servidor Zabbix que recoge todos los datos de forma centralizada. Zabbix Proxy puede ser utilizado para los siguientes propósitos:
La reducción de la carga en Zabbix monitorizando miles de dispositivos Monitorización de ubicaciones remotas Monitorización de ubicaciones con la comunicación poco fiable Simplificación de mantenimiento de la monitorización distribuida
Proxy v.s. Host Eligiendo entre la opción de utilizar el Servidor Proxy y de utilizar el Nodo hay que tomar en cuenta una serie de consideraciones siguientes: Funcionamiento Mantenimiento Creación Administración Facilidad GUI independiente automática ligero local de BD Nodo No Si SI No No Si Proxy Si No Si Si Si No
Preparación para dispositivos de hardware integrados Nodo No Proxy Si
Posibilidad de Configuración Generación de conexión centralizada notificaciones TCP Si No Si Si Si No
Configuración de Proxy. Cada nodo de la red se puede monitorizar ya sea por el Servidor Zabbix o por Zabbix Proxy. Esto se configura en el nodo de red. Si el nodo de la red está configurado para supervisar a través de 36
un Proxy, el servidor Proxy realizará la recogida de datos de rendimiento y disponibilidad de datos para el nodo de red. Los datos serán recogidos en el Proxy y se enviarán al servidor de Zabbix para su posterior procesamiento.
6. Gestión de Usuarios y Cuentas. Después de instalación inicial, Zabbix dispone de únicamente dos usuarios. El usuario Admin es el Superusuario en sistema y tiene todos los privilegios. El usuario Guest es un usuario especial por defecto y tiene derechos únicamente para la lectura. Para añadir usuario se pulsa la opción de “Create User”. Por defecto el nuevo usuario no tiene permisos. Los derechos a los usuarios se asignan a través de los determinados grupos como se muestra en la siguiente figura:
Tras asignar los derechos al usuario se determinan los métodos de notificación (media) al usuario.
Si es necesario cambiar los derechos del grupo hay que seleccionar “Groups of Users” de la lista para redactar los miembros del grupo. Se pulsa sobre el grupo para cambiar los derechos o miembros del grupo. Recién instalado, Zabbix dispone de solamente un modo de notificación (tipo de media), que es el Correo Electrónico. Es importante configurar las notificaciones por Correo Electrónico seleccionando “Email” de la lista de métodos de notificación disponibles y definiendo los valores correctos para servidor SMTP, SMTP hello y SMTP email. El tipo de notificación “Email” tiene que estar relacionado con el usuario para poder ser utilizado.
37
Escenario Web. El escenario presenta un conjunto de peticiones HTTP (pasos), que va a ejecutar periódicamente el Servidor Zabbix. Habitualmente los escenarios se determinan para una parte definida de la funcionalidad de la aplicación Web. Los escenarios representan en si un modo muy cómodo de control sobre el usuario. El escenario Web esta relacionado con el grupo de elementos de datos y nodo para agrupar. El escenario Web se ejecuta periódicamente y consta de uno o más pasos. Todos los ficheros temporales se guardan al ejecutarse un escenario.
7. Conclusión. Un sistema de monitorización debe ser capaz de gestionar miles de servidores y decenas de miles de servicios. Además, debe ser fácil de implementarse con el mayor grado de automatización posible, para que los nuevos servidores se pueden aprovisionar y añadirse a la monitorización con una sobrecarga administrativa minima y con capacidad de enviar scripts de cambios y comandos. Zabbix cumple todos estos objetivos. Referente a las principales características de sistema de monitorización, Zabbix esta basando su control en ambos modos: monitorización SNMP y mediante el Agente específico del sistema operativo que le permite realizar comprobaciones a nivel de puertos de varias aplicaciones. Zabbix puede efectuar las comprobaciones pasivas y activas, verificando los resultados antes de ser enviados al servidor a través de la utilidad zabbix_sender. También esta soportada la monitorización con logficheros, donde alertas se producen de los triggers a partir de log-eventos. Zabbix actualmente tiene capacidad de seguimiento de más de 10.000 unidades diferentes con capacidad de almacenamiento de datos de monitorización de miles de nodos. En el Manual del Usuario de Zabbix se ofrece una tabla de especificaciones de hardware que describe los requisitos para monitorizar más de 10.000 máquinas. La interfaz de usuario para la administración del sistema principal, así como para la monitorización esta basada en la Web y debe ser configurada a través de este. La funcionalidad es proporcionada por los scripts PHP que interactúan con la base de datos realizando el almacenamiento de datos y de la configuración de monitorización. El hecho de que la interfaz de usuario de Zabbix está basada en la Web hace que todas sus funciones son accesibles desde cualquier ubicación geográfica. Las cuentas individuales de usuarios o las cuentas genéricas con los permisos de sólo lectura se pueden configurar para permitir o denegar el acceso. Los firewalls de red, ACLs, u otras restricciones podrían bloquear el acceso remoto, pero en teoría este inconveniente puede superarse con configuraciones adicionales. Es posible que gran número de usuarios sobrecargue el sistema si están accediendo todos a la vez, pero en general esto es poco probable. Zabbix cuenta con una interfaz de usuario mucho más atractiva y madura que las que pueden ofrecer otras herramientas de gestión de su clase. Debido al 38
hecho de que la interfaz de usuario de Zabbix está basada en Web, no existen restricciones respecto a los sistemas operativos y compatibilidad de plataformas para efectuar el acceso a la herramienta. Una de las posibles desventajas es que el GUI (la principal interfaz de Zabbix basado en Web) cuenta con un soporte de la línea de comandos o control de scripts limitado. Algunos objetos de configuración pueden ser modificados a través de las importaciones xml, pero tienen límites. El hecho de no existir manera para ejecutar las tareas administrativas vía línea de comandos limita considerablemente el scripting y se nota aún más al realizar algunos cambios cuando la interfaz a veces es bastante lenta y exige hacer varios clicks. Con el uso de scripts de shell esto no ocurriría. Una de las mejores características de Zabbix es su representación gráfica y capacidad de cartografía que es parte del paquete básico estándar gratuito. Se puede elaborar un mapa de red basado en dependencias que mostraría la ubicación física y lógica de los nodos, con la posibilidad de crear los gráficos de informes de rendimiento que destacan por ser claros, concisos y fáciles de leer. La interfaz Web proporciona varias maneras para definir los gráficos de datos. Es muy fácil crear un gráfico nuevo debido a soporte explicativo que se ofrece. En general, el sistema de informes para los datos de rendimiento y tendencias a través de los gráficos ofrecida por Zabbix, es excepcional y supera cualquier otra herramienta de gestión de la misma clase. Por ejemplo, Nagios podría producir algunos de los mismos tipos de gráficos únicamente a través de add-ons de terceros y herramientas externas. Zabbix ofrece capacidad de almacenar decenas de Gigabytes de datos de monitorización. Según la documentación oficial de Zabbix, la herramienta no tiene ningún inconveniente para almacenar decenas de gigabytes de datos. Un ejemplo de cálculo de tamaño de base de datos en el Manual de Usuario de Zabbix ofrece unos 50 Gigabytes, lo que permite configurarlo para usar Mysql o Postgres. Respecto a un almacenamiento de los datos de configuración, Zabbix utiliza la base de datos para guardar definiciones de configuración, aunque no ofrece posibilidad de modificarlos directamente. Por lo tanto, todos los cambios de configuración deben realizarse a través de la interfaz gráfica de usuario, o por las importaciones XML. Manipulación directa de la base de datos no parece ser una práctica común por parte de usuarios de Zabbix. El hecho de tener configuraciones en la base de datos relacional podría aprovechar para informes ad-hoc, así como actualizaciones. El sistema permite realizar configuraciones de los periodos de retención de datos para los datos del historial (revisiones periódicas) y datos sobre tendencias (promedio) de forma independiente. Esto permite a usuario definir las reglas de retención que mejor se adapten a sus necesidades. Respecto a la escalabilidad, Zabbix puede correr múltiples servidores agregando los resultados de manera centralizada y trabaja principalmente a través de un Agente que se ejecuta en cada nodo monitorizado. Este cliente recolecta un amplio conjunto de información, que luego se envía al servidor de forma regular efectuando de este modo los escalados al número de servidores requerido. Zabbix realiza estos escalados sin ningún tipo de add-ons de terceros, mientras que por ejemplo, Nagios requiere determinados cambios y un software de terceros para prestar servicios al volumen de revisiones que se anticipa. Igual que otras herramientas de gestión, Zabbix tiene posibilidad de configuración Proxy donde los servidores secundarios pueden actuar como un Proxy para ejecutar comprobaciones de ubicaciones remotas en nombre del servidor central. Estos Proxies en Zabbix tienen algunas ventajas y desventajas. Existen otras herramientas parecidas, donde todos los Proxies juntos pueden ejecutar comprobaciones de servicio en todos los nodos. Esto significa que los nodos específicos no pueden ser asignados a un Proxy específico. La ventaja de esto es que la pérdida de un Proxy no elimina la capacidad de supervisar un conjunto de servidores. La desventaja es que no se puede configurar un Proxy en particular detrás de un firewall específico para monitorizar un subconjunto de nodos. En Zabbix, un Proxy específico único se asigna al nodo específico lo que permite a Zabbix Proxy monitorizar desde una subred diferente y crea el punto de recuperación de sistema. Zabbix permite definir de manera individual la frecuencia de monitorización de cada revisión y tiene posibilidad de definir el conjunto de revisiones a aplicar en los nodos. Zabbix proporciona un mecanismo llamado plantillas. La plantilla es un conjunto de revisiones que podrían aplicarse a varios nodos. Una vez definida, la plantilla puede aplicarse al nodo necesario. La implementación de la 39
