En la primera entrada dedicada a Zabbix vimos templates para monitorizar impresoras Brother color. De todas las impresoras que tengo de esta marca he notado que la Broher DCP-9020CDW cada varios días se bloqueaba y me obligaba a reiniciarla. Si desactivaba la monitorización de Zabbix de esa impresora el problema desaparecía.
He deducido que alguno de los ítems que interrogaban a la impresora acababan finalmente provocando su cuelgue. Durante varios días he ido habilitando e inhabilitando ítems de la plantilla por grupos, mediante un divide y vencerás, hasta dar con el culpable: el "JetDirect Check".
Como es un ítem intrascendente que venía en la plantilla por defecto, lo he dejado desactivado (casilla "Enabled" desmarcada) y ya no ha vuelto a bloquearse:
Después de tener montado el Zabbix, van surgiendo nuevas necesidades para monitorizar nuestros clientes. En esta entrada voy a ver como he creado una plantilla para los Linux del IES, que me permite monitorizar varias cosas no previstas en la plantilla por defecto.
Lo que haremos en primer lugar es crear la plantilla "Template IES Linex"
A continuación vamos definir los ítems que extraigan datos del cliente. Estos ítems son pequeños fragmentos de código con comandos de terminal Unix. Lo podemos hacer de dos maneras:
Definir el código en el cliente dentro de /etc/zabbix/zabbix_agentd.conf.d/blablaba.conf y luego referenciarlo en el servidor Zabbix.
Definir el código en el servidor Zabbix, dentro del mismo item usando system.run[...]
En el primer caso vamos a crear, por ejemplo, un ítem llamado "puppetcheck" que nos diga si la última ejecución de puppet ha acabado con éxito. Para ello lo primero es programar las instrucciones que hagan eso. Hay varias maneras de averiguarlo, como por ejemplo esta:
Esto nos devolverá 0 si no hay ningún error y >0 si hay algun error en la última ejecución de puppet. Esta secuencia de comandos ejecutada como usuario root funciona, pero hay que tener en cuenta que el agente Zabbix se ejecuta con el usuario zabbix y eso nos puede causar problemas. En este caso concreto el problema era el acceso al fichero /var/lib/puppet/state/last_run_report.yaml del cliente.
Para que el agente Zabbix pueda llegar hasta allí tenemos que echar mano de sudoers:
.
Una vez definido el item en los clientes, lo añadimos a la plantilla en el servidor Zabbix:
Además de crear el ítem, le añadimos una regla de preprocesamiento llamada "Discard unchanged with a heartbeat" que evita que se guarden valores repetidos consecutivos del ítem en el registro histórico. De esta manera solo guardamos el ítem cuando cambia su valor respecto a la actualización anterior (o, en este caso concreto, han pasado 12 horas desde la última actualización). La finalidad de esto es evitar guardar valores repetidos consecutivos de los ítems en toda la base de datos histórica.
Finalmente creamos un trigger para que avise cuando hay un error. En este caso vemos si hay error en puppet durante las 3 últimas actualizaciones del ítem:
Con esto tenemos el pack completo: parámetro defínido en el cliente Zabbix, asociado a un ítem en el servidor Zabbix y con un trigger que nos avisa este tiene un valor determinado.
La otra otra opción consiste en definir en el servidor Zabbix el ítem con el código a ejecutar en el cliente remoto. Por ejemplo, un ítem que muestre en cada momento que usuario ha hecho login en la máquina, definido así:
El problema de este tipo de ítems es que debemos estar seguros de que el cliente Zabbix permite la ejecución remota de comandos, ya que si no es así el ítem no se actualizará nunca. De igual manera, si el agente se ejecuta en una máquina que está detrás de un firewall o un NAT tampoco podremos llegar a ella para ejecutar el comando desde el servidor Zabbix.
En este ítem LoggedUser tambien añadiremos una regla de preprocesamiento del tipo "Discard unchanged", para evitar guardar de forma repetida el usuario logado cada vez que se actualiza el ítem, y solo guardarlo cuando cambia entre una actualización y la siguiente.
Por último, comentar que una vez hemos definido los ítems tenemos la posibilidad de probarlos desde la línea de comandos para ver que tal funcionan. En el cliente local:
Bueno, pues con esto ya tenemos el armazón para añadir ítems y triggers a saco en nuestros clientes.
Aquí están los 3 camaradas taikonautas que han subido estos días en la Shenzou 14 para finalizar el montaje de la Estación Espacial China. Recordemos que esta estación existe porque USA se negó a dar acceso a China a la Estación Espacial Internacional, por lo que los chinos decidieron montarse su propia estación mastodóntica (que a diferencia de la de Bender, no tendrá casinos ni furcias (*)) adquiriendo en el proceso una experiencia y know-how que les vendrá de perlas.
Es lo que pasa cuando no se quiere colaborar internacionalmente. Avisados quedamos.
Poco a poco sigo poniendo en marcha mi servidor Zabbix. Tras poner en funcionamiento la monitorización de los equipos Windows usando el "Template Module Windows services by Zabbix agent" me encontré que el Dashboard se llenaba de alertas de "Problemas" con los servicios de los Windows.
Los mensajes en concreto eran del tipo:
12:58:34 pc "BITS" (Servicio de transferencia inteligente en segundo plano (BITS)) is not running (startup type automatic delayed) 12m 23s No
12:51:06 pc "BITS" (Servicio de transferencia inteligente en segundo plano (BITS)) is not running (startup type automatic delayed) 19m 51s No
12:05:19 pc "OneSyncSvc_1265ec8f" (Sincronizar host_1265ec8f) is not running (startup type automatic delayed) 1h 5m 38s No
12:05:18 pc "CDPUserSvc_1265ec8f" (Servicio de usuario de plataforma de dispositivos conectados_1265ec8f) is not running (startup type automatic)
Básicamente los que sucede es que hay varios servicios que, tras arrancar el equipo con Windows, tardan en arrancar o fallan y el Agente Zabbix nos informa de esa circunstancia. La plantilla usada realiza un descubrimiento de los servicios habilitados en la máquina y si tras 3 ciclos de actualización del agente no están en ejecución salta la alerta.
El mensaje que sale en la descripción del problema es "The service has a state other than "Running" for the last X times":
Al final, pasadas las horas, acaban por arrancar los servicios y desaparecen casi todas las alertas, pero no quita que en ciertos momentos se llene la pantalla de alertas sobre cosas que no me aportan nada.
Lo primero que intenté fue cambiar la plantilla para que en lugar de revisar el estado durante 3 ciclos lo hiciese durante 10, dando un poco más de margen de tiempo para que funcionen. No sirvió de nada.
Teniendo en cuenta que estos son servicios poco importantes (y que sospecho que algunos no funcionan bien por el firewall corporativo, que capa actualizaciones de Microsoft) la otra estrategía que podía aplicar es sencillamente dejar de monitorizar dichos servicios. ¿Se puede hacer eso? Pues gracias a la flexibilidad de Zabbix si se puede.
Los pasos a seguir son:
Vamos a Configuration->Templates.
Buscamos Template OS Windows by Zabbix agent -> Template Module Windows services by Zabbix agent
Vamos a Windows services discovery -> Filters.
Añadimos un filtro para ignorar, filtrando por su nombre, los Servicios que dan problemas (como vemos la lista es bastante grande, y eso que sigo añadiendo más):
{#SERVICE.NAME}
does not match
^(MMCSS|TrustedInstaller|BITS|GISvc|gupdate|MapsBroker|WbioSrvc|sppsvc|RemoteRegistry|wuauserv|gupdate|SysmonLog|clr_optimization_v2.0.50727_32|clr_optimization_v4.0.30319_32)$
El filtro se añade a la lista de filtros colocándose, no se por qué, en el tercer lugar:
Una vez acabamos veo que las alertas siguen saltando. La causa es que aunque hayamos cambiado la plantilla esos cambios no se aplican a los hosts dados de alta con ellas. Desconozco si hay alguna manera de trasladar esos cambios, pero como no encontraba nada lo resuelvo de una forma más expeditiva: borro los hosts Windows y dejo que se autoregistren de nuevo, aplicándose la plantilla ya cambiada con los filtros. Fin del problema.
Esta foto es del helicóptero marciano Ingenuity fotografiando la cápsula que dejó el Perseverance (mirar la sombra del propio helicóptero en la imagen) en tierra de forma segura y luego se alejó para caer al suelo. Como vemos el litofrenado la ha dejado bastante maltrecha.
Para mi gozo absoluto, hace unas semanas pude ver una réplica a tamaño real de la Perserverance y la Ingenuity en Nueva York, ahí van unas fotos hechas por mi:
Que maravilla de la ingeniería. Un aparato pensado para realizar un puñado de vuelos de prueba en una atmósfera un 99% menos densa que en la Tierra sigue dandose garbeos por el planeta rojo meses después.
Estuve cerca de ellas, pero no pude tocar nada. Por fortuna si que pude sentarme dentro de una de esas latas de sardina que fueron las cápsulas Gemini de los años 60. Emocionante.
Bueno, pues por fin me he metido en el apasionante mundo de Zabbix. Con ayuda de mis compañeros he ido montando el sistema, los clientes y los templates para cada tipo de dispositivo que se puede encontrar en mi red. Es todo un universo nuevo, pero merece la pena sobradamente.
Una de las cosas que más me interesa monitorizar son las impresoras, tanto para llevar un control histórico del gasto como para recibir avisos de que queda poca tinta/tóner e ir encargando con repuestos tiempo. Para las impresoras HP y Epson que tenemos en los centros ya hay templates de monitorización que han compartido los compañeros, pero tengo por mi parte varias impresoras Brother láser color (DCP-9020CDW, HL-4140CN y alguna más) para las cuales el número de templates que se encuentran es bastante escaso. En la página de templates oficial de Zabbix aparecen apenas 3 plantillas, todas para láser monocromo, que se pueden importar (algunas con errores que hay que corregir editando a mano XML, pues son un poco antiguas), pero no nos dan toda la información que queremos sobre las impresoras láser en color.
Me ha tocado investigar un poco para crear una plantilla mezcla de las 3 existentes más items nuevos para obtener los datos que faltaban. Esta es la parte divertida de nuestro trabajo, no todo iba a ser azotar usuarios. No ha sido todo nuevo, puesto que las impresoras son interrogadas usando el protocolo SNMP y ya tenía experiencia al haberlo utilizado hace bastante tiempo para otra entrada del blog.
AVISO: tochazo inside.
1. Uso de snmpwalk para interrogar impresoras.
Para preguntar sobre toda la información que comparte de forma pública una impresora usamos el comando:
La lista es bastante grande y normalmente ahí hay información de sobra sobre el estado de nuestra impresora. Cada rama o nodo tiene un significado más o menos estándar (aunque recordemos el axioma que dice "lo bueno de los estándares es que hay varios donde elegir"). Por ejemplo, de la lista anterior el OID iso.3.6.1.2.1.1.6 se describe como:
Literalmente: "The physical location of this node (e.g., 'telephone closet, 3rd floor'). If the location is unknown, the
value is the zero-length string", es decir, la ubicación física de la impresora tal como está definida en su configuración. El valor de este campo se obtiene con:
# snmpwalk -v 2c -c public 172.a.b.c iso.3.6.1.2.1.1.6
iso.3.6.1.2.1.1.6.0 = STRING: "Sala de Profesores"
La información sobre el contenido cada OID (object identifier o Identificador de Objeto, que se define como una secuencia de números que se asignan jerárquicamente y que permite identificar objetos en la red, siendo usados con gran cantidad de protocolos) estándar se puede consultar en varios sitios de internet:
Hasta aqui todo sería estupendo si todas las impresoras respetasen los OID estándar. Con las HP y las Epson no hay problema, pero mis Brother son rebeldes. La mayoría de los OID (ubicación, status, páginas impresas, número de serie, etc) se ajustan al estándar definido y vale el mismo template que para cualquier otra impresora, pero aquellos que deben decirme el nivel de tóner restante mienten o son inexactos.
El estado de los consumibles se encuentra en la rama iso.3.6.1.2.1.43.11, prtMarkerSupplies. Vamos a husmear dentro (añado comentarios explicando el significado de las ramas):
prtMarkerSuppliesType, nodo iso.3.6.1.2.1.43.11.1.1.5: tipos de consumible. Por ejemplo, el valor 3 equivale a "tóner".
prtMarkerSuppliesDescription, nodo iso.3.6.1.2.1.43.11.1.1.6: descripción del consumible. Por ejemplo "Magenta Toner Cartridge".
prtMarkerSuppliesSupplyUnit, nodo iso.3.6.1.2.1.43.11.1.1.7: unidades de medida del consumible. Por ejemplo, el valor 13 equivale a "decígramos".
prtMarkerSuppliesMaxCapacity, nodo iso.3.6.1.2.1.43.11.1.1.8: valor máximo de capacidad del consumible: puede ser la cantidad de tóner o tinta que cabe en el cartucho, o el número máximo de páginas que tiene de vida útil un tambor/cinta de arrastre.
prtMarkerSuppliesLevel, nodo iso.3.6.1.2.1.43.11.1.1.9: nivel actual del consumible: puede ser la cantidad de tóner o tinta que resta en el cartucho (un %, un número estimado de páginas, etc), o el número de páginas que le quedan por imprimir a un tambor/cinta de arrastre.
Con estos indicadores se puede controlar cuanto consumible queda... en teoría. En el caso de las impresoras Brother el contenido de las ramas prtMarkerSuppliesMaxCapacity y prtMarkerSuppliesLevel no dan datos reales sobre los niveles de tóner, aunque si del estado de otros consumibles: almacén de tóner, cinta de arrastre y tambores. En ellas prtMarkerSuppliesMaxCapacity siempre tiene el valor -2 y prtMarkerSuppliesLevel lo he visto con únicamente dos valores distintos: -3 (hay toner) y 0 (no hay tóner), lo cual es muy poco informativo. En Internet se habla de otros posibles valores asociados a varios estados ("full", "almost empty", "empty" or "absent) pero en mis pruebas esos valores nunca han aparecido.
Cusiosamente, casi todos los otros parámetros estándar de impresoras si que están implementados para las Brother. Por ejemplo, hrPrinterStatus con los valores de estado de la impresora: other(1), unknown(2), idle(3), printing(4), warmup(5).
Buscando una solución encontré un parámetro llamado prtAlertcode en la rama iso.3.6.1.2.1.43.18.1.1.7 que nos devuelve un código de alerta si pasa algo en la impresora. Como se ve en el enlace anterior hay un buen número de códigos, incluido el 1104 que significa markerTonerAlmostEmpty: queda poco tóner. No nos dice el color, pero puede servir para alertar si no nos queda más remedio.
Evidentemente, con esta información es imposible poder monitorizar con detalle el nivel de los consumibles y planificar su adquisión. Pero esto no puede quedar aquí: si vamos al interface web o el panel de la impresora Brother vemos que si que conocen y muestran esos niveles. Es obvio que tiene que haber alguna manera de interrogar a la impresora para obtenerlos.
3. Buscando e interpretando los OID privados.
Mirando con mas detalle me encontré que hay ciertas ramas "ocultas" o privadas que dependen del fabricante del dispositivo y que no salen haciendo un snmpwalk normal. El nodo sysObjectID, con OID iso.3.6.1.2.1.1.2 contiene "The vendor's authoritative identification of the network management subsystem contained in the entity". En caso de las Brother su contenido es:
Es decir, ese nodo contiene una referencia a otra rama, que en el caso de la Brother es iso.3.6.1.4.1.2435. Esta es una rama oculta, que si consultamos directamente con:
Muestra mas de 5000 nodos con mucha información privada de la impresora Brother. El código 2435 corresponde a Brother, pero como se puede ver en este enlace hay códigos para todo tipo de fabricantes, asignados por IANA. Cada uno tendrá su rama privada colgando de ahí.
En https://oidref.com/ podemos perdernos husmeando dentro de esa rama. Yo he ido al grano, buscando valores que me interesaban para su monitorización con Zabbix, por ejemplo el nodo brBackLightColor, que tiene 4 posibles valores: 0:Off/1:Green/2:Orange/3:Red. Básicamente sirven para indicarnos el color que muestra led del panel de la impresora, 0 o 1 significa que bien, y 2 o 3 que hay problemas. Los templates de Zabbix que encontré para impresoras Brother monocromo usaban brBackLightColor en conjunción con prtAlertCode (visto anteriormente) para avisar de forma rudimentaria de que quedaba poca tinta.
Pero no olvidemos que la meta es saber los niveles de los 4 tóneres de color. No hallaba información alguna hasta que encontré pistas en este enlace, y sobre todo en este otro, donde se muestra un programa que lee los niveles reales de tóner de una Brother color. Los datos se leen por SNMP mediante este conjunto de scripts en Python. Indagando en el código veo que los niveles de tinta se sacan de la rama iso.3.6.1.4.1.2435.2.3.9.4.2.1.5.5.8.0, llamada brInfoMaintenance. ¿Qué hay allí?:
Mmmm, esto es una retahíla hexadecimal incomprensible...
4. Extrayendo información de brInfoMaintenance
Bueno, pues ahi dentro está la información. Y alguien ha hecho ingeniería inversa para extraerla. Tras leer dicha página comprendo que, para las impresoras que tengo, la información se organiza en septetos de bytes, asi que formateo la salida del comando para que salga en grupos de 7 valores::
A continuación vienen los valores fijos "01 04" y los cuatro últimos bytes son el valor del parámetro, por ejemplo:
71 01 04 00 00 23 F0
El "71" es VAL_MAGENTA_TONER_REMAIN, tóner restante magenta. El "01 04" lo ignoramos. Y el "00 00 23 F0" es el número hexadecimal 0x23F0, que en decimal es 9200. Ese 9200 se debe dividir por 100 y nos da el porcentaje de toner magenta restante: 9200/100=92% de tóner. ¡Ahí está la información!. Por tanto, en:
Podremos sacar el % de cada cartucho de tóner. Puñeteramente endiablado lo ha puesto Brother. Menos mal que un esforzado hacker de los buenos lo ha decodificado, Gloria y Honor para él.
5. El template Zabbix final.
Bueno, pues el template debe extraer el churro hexadecimal de iso.3.6.1.4.1.2435.2.3.9.4.2.1.5.5.8.0, buscar los códigos 6F, 70, 71 y 72 para cada cartucho de tóner y extraer el nivel en cada uno.
La manera mas sencilla que he encontrado es crear un item que lee la secuencia hexadecimal completa por SNMP y luego hace un preprocessing con Javascript (me encanta ese lenguaje) que busca el código identificador del cartucho en cuestión, extrae los dos bytes con el valor, los convierte de hexadecimal a decimal y lo divide por 100 para obtener el valor que será el mostrado por el item. El código para el tóner Cyan sería:
var pos = value.indexOf("70 01 04 00 00");
var res=0;
if (pos >=0 ) {
res=value.substring(pos+15, pos+20);
res=parseInt(res.replace(" ", ""),16)/100;
};
return res;
Como se puede ver añadimos un trigger que avisa cuando el tóner está por debajo del 10%. El resto de colores se haría con el mismo método.
Finalmente, incluyo enlace Template_Brother_Laser_Printers.xml con el template Zabbix final para impresoras Brother Láser Color, en formato XML listo para ser importado y leer bien todos los niveles de tóner, junto con varios valores más adicionales que me ha parecido interesante mantener o añadir. Algo me dice que este será el template Zabbix mas enrevasado que nunca escribiré.
Estamos que no paramos con Marte. Los camaradas de la República Popular de China ha aterrizado con la discreción que le caracteriza su rover Zhurong. Parece ser que para la civilización China a la primera va la vencida. Todavía no hay imágenes directas, pero esto nos sirve como adelanto:
Esperamos ansiosos las imágenes del rover trabajando.
