Monitorización segura con Zabbix
febrero 20, 2017
Nuevas funcionalidades en Zabbix 3.2 : "Event Tags"
En estos primeros posts, vamos a analizar algunas de las interesantes nuevas funcionalidades que nos brinda la nueva versión de Zabbix. Hemos escogido para este primer post, una de las más destacadas, denominada «Event tags», o «etiquetas de evento».
La perspectiva respecto a la gestión de las incidencias de Zabbix hasta ahora estaba muy orientada a «hosts» concretos, a servidores y a servicios dentro de servidores y no de manera global a «servicios». Esta perspectiva, proveniente de la naturaleza original de la configuración de Zabbix (que sigue vigente) aplica muy bien para la gestión de redes y servidores en una única ubicación, lo cual corresponde a un uso muy habitual del sistema.
Pero, hoy en día, con el uso cada vez más extendido de contenedores y sobre todo arquitecturas orientadas a micro-servicios, es necesaria otra aproximación diferente para que Zabbix sea una herramienta adecuada tanto para los equipos que gestionan la infraestructura para como los que gestionan los servicios (que, cada día más, son los mismos equipos). Para ello, la gente de Zabbix ha rediseñado la pantalla de problemas y ha añadido la posibilidad de, en cada «trigger» se indique una etiqueta concreta.
Estas etiquetas o tags se contruyen mediante un nombre etiqueta, que puede llevar asociado un valor, permitiendo dotar a estas etiquetas de un nivel extra de clasificación, por ejemplo: WebServices, WebServices:Muutech-Login, WebServices:Muutech-Web y otros que se nos pueden ocurrir una vez empecemos a trabajar con ellos como de quién es responsabilidad, si afecta a clientes, etc. (Team:Ops, Team:Dev, Customer:External).
Para el ejemplo, vamos a querer que Zabbix nos avise cada vez que haya un error 404, por ejemplo:
Configuramos el item de forma adecuada para que lea del log las peticiones GET, así como el agente de Zabbix para que soporte el modo activo y, importante, tenga derechos de lectura sobre el log.
A la hora de configurar el trigger, la clave para indicarle que etiqueta poner cuando salte este problema viene en el apartado «Tags». Es posible utilizar las siguientes macros para cumplimentar las etiquetas: {ITEM.VALUE} e {ITEM.LASTVALUE}, así como macros de usuarios. Esto puede ser tremendamente útil para auto-generar las etiquetas, combinándolo con las nuevas funciones para macros regsub e iregsub. En el manual de Zabbix tenéis ejemplos de cómo configurarlos. Lo probamos:
La perspectiva respecto a la gestión de las incidencias de Zabbix hasta ahora estaba muy orientada a «hosts» concretos, a servidores y a servicios dentro de servidores y no de manera global a «servicios». Esta perspectiva, proveniente de la naturaleza original de la configuración de Zabbix (que sigue vigente) aplica muy bien para la gestión de redes y servidores en una única ubicación, lo cual corresponde a un uso muy habitual del sistema.
Pero, hoy en día, con el uso cada vez más extendido de contenedores y sobre todo arquitecturas orientadas a micro-servicios, es necesaria otra aproximación diferente para que Zabbix sea una herramienta adecuada tanto para los equipos que gestionan la infraestructura para como los que gestionan los servicios (que, cada día más, son los mismos equipos). Para ello, la gente de Zabbix ha rediseñado la pantalla de problemas y ha añadido la posibilidad de, en cada «trigger» se indique una etiqueta concreta.
Estas etiquetas o tags se contruyen mediante un nombre etiqueta, que puede llevar asociado un valor, permitiendo dotar a estas etiquetas de un nivel extra de clasificación, por ejemplo: WebServices, WebServices:Muutech-Login, WebServices:Muutech-Web y otros que se nos pueden ocurrir una vez empecemos a trabajar con ellos como de quién es responsabilidad, si afecta a clientes, etc. (Team:Ops, Team:Dev, Customer:External).
Ejemplo de uso y configuración de triggers
El ejemplo de uso que vamos a poner es en el más evidente, cuando tenemos un único host cuyos servicios afectan a varias de nuestras aplicaciones o micro-servicios. Podríamos, por ejemplo, monitorizar datos concretos de las bases de datos de cada micro-servicio, el consumo de disco de sus carpetas asignadas, etc, pero en este ejemplo vamos a utilizar ese lugar adónde van a parar muchas veces cosas de diversos micro-servicios o incluso otros sistemas, de forma difícil de ver: el LOG. En el ejemplo, vamos a utilizar el log de un Apache sirviendo varios micro-servicios web (dos en concreto que llamaremos Muutech-Login y Muutech-Web). Aunque lo aconsejable sería separar el log de cada micro-servicio en diferentes ficheros, para mostrar todas las bondades de estas funcionalidad de Zabbix, vamos a hacer que escriban sobre el log general.Para el ejemplo, vamos a querer que Zabbix nos avise cada vez que haya un error 404, por ejemplo:
192.168.56.1 - - [29/Jan/2017:20:46:57 +0100] "GET /muutech-login/no-existe HTTP/1.1" 404 221 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36"
Configuramos el item de forma adecuada para que lea del log las peticiones GET, así como el agente de Zabbix para que soporte el modo activo y, importante, tenga derechos de lectura sobre el log.
A la hora de configurar el trigger, la clave para indicarle que etiqueta poner cuando salte este problema viene en el apartado «Tags». Es posible utilizar las siguientes macros para cumplimentar las etiquetas: {ITEM.VALUE} e {ITEM.LASTVALUE}, así como macros de usuarios. Esto puede ser tremendamente útil para auto-generar las etiquetas, combinándolo con las nuevas funciones para macros regsub e iregsub. En el manual de Zabbix tenéis ejemplos de cómo configurarlos. Lo probamos:
Si os fijáis lo que hace este trigger es saltar si el último GET recibido (leido del log) tiene un 404, por lo que el problema se generará cada vez que aparezca un 404 y se eliminará cada vez que haya un GET exitoso.
Fijaos en la etiqueta que hemos puesto, genérica «WebServices» y en valor:
para que coja la carpeta (nuestro rudimentario equivalente al VirtualHost del micro-servicio). Con esto cada vez que salte la alarma de 404, en la etiqueta nos dirá para que micro-servicio ha saltado.
Ojo: tal y como dijimos esta alarma se genera ante cualquier 404 etiquetando la alarma con el micro-servicio para el que haya saltado pero, como no se borrará hasta el siguiente GET exitoso, si hubiese otro 404 en otro micro-servicio (o en este mismo) no saltaría un nuevo problema. Para cambiar esto, es necesario marcar como «MULTIPLE» el «PROBLEM event generation mode» de modo que nos salte una alarma ante cualquier 404 etiquetándonos el servicio al que corresponde.
Vamos a probarlo.
Para nuestro ejemplo, hemos probado a acceder a /muutech-login/no-existe y, tal y como esperabamos, ha saltado una alarma, que podemos ver correctamente etiquetada en la pantalla:
Fijaos en la etiqueta que hemos puesto, genérica «WebServices» y en valor:
{{ITEM.VALUE}.regsub(«GET \/([A-Za-z\-]+)\/» ,\1)}
para que coja la carpeta (nuestro rudimentario equivalente al VirtualHost del micro-servicio). Con esto cada vez que salte la alarma de 404, en la etiqueta nos dirá para que micro-servicio ha saltado.
Ojo: tal y como dijimos esta alarma se genera ante cualquier 404 etiquetando la alarma con el micro-servicio para el que haya saltado pero, como no se borrará hasta el siguiente GET exitoso, si hubiese otro 404 en otro micro-servicio (o en este mismo) no saltaría un nuevo problema. Para cambiar esto, es necesario marcar como «MULTIPLE» el «PROBLEM event generation mode» de modo que nos salte una alarma ante cualquier 404 etiquetándonos el servicio al que corresponde.
Vamos a probarlo.
Visualización de problemas
En Monitoring -> Problems podemos ver los tags asociados a cada trigger disparado, siendo el máximo de etiquetas mostrado tres. En caso de haber más de tres pasando el ratón por encima de los tres puntos que aparecerían veríamos el resto.Para nuestro ejemplo, hemos probado a acceder a /muutech-login/no-existe y, tal y como esperabamos, ha saltado una alarma, que podemos ver correctamente etiquetada en la pantalla:
Como véis las etiquetas que debemos usar, deben ser lo más minimalistas posible ya que la visualización de los valores no es buena. Pero, si que tenemos la gran ventaja de poder filtrar por estas etiquetas a la hora de visualizar los problemas, lo que nos permitirá generar pantallas personalizadas a partir de estos tags, monitorizando de forma adecuada nuestros micro-servicios… o lo que se nos ocurra etiquetar en base a nuestra arquitectura.
Uso de tags en acciones
Al configurar las acciones (por ejemplo en las notificaciones) podremos usar las etiquetas como filtrado, lo cual permite un punto más de granularidad a la hora de realizar acciones automatizadas o de a quién avisar.
Además, como en el reporte podremos usar la macro {EVENT.TAGS} (y para los de recuperación {EVENT.RECOVERY.TAGS}, nos será muy útil para etiquetarlo también en nuestro correo electrónico.
También es interesante comentar que estos tags se pueden usar en conjunción con el sistema de correlación de eventos, que veremos en futuros posts, así como el cierre de problemas (ambas novedades de esta versión 3.2)
Usos avanzados
Después de esta pequeña explicación de uso básico, podréis probar a incorporar estos tags a vuestros templates o incluso utilizarlos en aquellas plantillas que utilicen LLD (low-level-discovery), pudiendo utilizar las macros propias de LLD para rellenar los valores de las etiquetas.También es interesante comentar que estos tags se pueden usar en conjunción con el sistema de correlación de eventos, que veremos en futuros posts, así como el cierre de problemas (ambas novedades de esta versión 3.2)
Impacto en rendimiento
Naturalmente, esta funcionalidad no es gratuita a nivel de de rendimiento de nuestro Zabbix. Según advierte la propia documentación de Zabbix y la lógica se verán afectados los siguientes puntos:- Procesamiento de eventos en general
- Creación, actualización y borrado de triggers, sobretodo aquellos que hereden a través de plantillas y se modifiquen estas
- Sincronización de la caché de configuración
- Aumento del espacio consumido en disco de cada evento de una forma, además difícil de predecir, ya que variará mucho en función del tamaño y número de tags.