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).
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: