Tengo un caso especifico relacionada a los traps de snmp donde se realizo una configuración basada en severidad, lo que impide que los traps «de limpieza» cierren la alarma que corresponda
Cuando hablamos de monitoreo por SNMP hay muchas variables que hacen que se deba dedicar un esfuerzo extra para añadirlo al monitoreo, en este caso teníamos unas configuraciones de legado sin documentación donde se definieron traps de acuerdo a la severidad enviada en el trap, lo que impedía que Zabbix entendiera que debe resolver el evento cuando le llegase una severidad de limpieza, en este caso cleared.
Vamos a ver un ejemplo de trap de alarma en esta plataforma especifica
2021-11-30 17:18:06 17:17:57 30/11/2021 PDU INFO: notificationtype TRAP version 0 receivedfrom UDP: [10.40.10.152]:53898->[10.40.10.151] errorstatus 0 messageid 0 community Monitoreo transactionid 2730074 errorindex 0 requestid 0 VARBINDS: DISMAN-EVENT-MIB::sysUpTimeInstance type=67 value=Timeticks: (2598112553) 300 days, 16:58:45.53 SNMPv2-MIB::snmpTrapOID.0 type=6 value=OID: SNMPv2-SMI::enterprises.1729.104.0.2 SNMPv2-SMI::enterprises.1729.100.1.10.13.0 type=66 value=Gauge32: 102 SNMPv2-SMI::enterprises.1729.100.1.10.14.0 type=4 value=STRING: "Application type: StatServer. Application terminated due to internal condition" SNMPv2-SMI::enterprises.1729.100.1.10.15.0 type=4 value=STRING: "5064" SNMPv2-SMI::enterprises.1729.100.1.10.16.0 type=4 value=STRING: "host2" SNMPv2-SMI::enterprises.1729.100.1.10.17.0 type=4 value=STRING: "StatServer" SNMPv2-SMI::enterprises.1729.100.1.10.18.0 type=4 value=STRING: "Major" SNMPv2-SMI::enterprises.1729.100.1.10.19.0 type=4 value=STRING: "A190A7C9-59B5-4F9D-8B93-4306EC749620" SNMPv2-SMI::enterprises.1729.100.1.10.20.0 type=4 value=STRING: "Host-ejemplo" SNMP-COMMUNITY-MIB::snmpTrapAddress.0 type=64 value=IpAddress: 198.18.48.220 SNMP-COMMUNITY-MIB::snmpTrapCommunity.0 type=4 value=STRING: "Monitoreo" SNMPv2-MIB::snmpTrapEnterprise.0 type=6 value=OID: SNMPv2-SMI::enterprises.1729.104
Como les comente, la condición de alarma es basada en la severidad, en este caso la definición del trigger tendremos
Problem: {Host-ejemplo:snmptrap["(SNMPv2-SMI::enterprises.1729)"].str(Major)}=1
Como ven básicamente busca el string «Major» y gatilla el evento, lo malo de este método es que hace un poco mas difícil el poder resolver este evento automáticamente ya que no se realiza una diferenciación entre una alarma más especifica
Ahora veremos como luce un trap de limpieza, o sea severidad «Clearance»
2021-11-30 17:20:16 17:20:07 30/11/2021 PDU INFO: notificationtype TRAP version 0 receivedfrom UDP: [10.40.10.152]:53911->[10.40.10.151] errorstatus 0 messageid 0 community Monitoreo transactionid 2730087 errorindex 0 requestid 0 VARBINDS: DISMAN-EVENT-MIB::sysUpTimeInstance type=67 value=Timeticks: (2598113089) 300 days, 16:58:50.89 SNMPv2-MIB::snmpTrapOID.0 type=6 value=OID: SNMPv2-SMI::enterprises.1729.104.0.2 SNMPv2-SMI::enterprises.1729.100.1.10.13.0 type=66 value=Gauge32: 102 SNMPv2-SMI::enterprises.1729.100.1.10.14.0 type=4 value=STRING: "Application type: StatServer. Application start detected by Management Layer" SNMPv2-SMI::enterprises.1729.100.1.10.15.0 type=4 value=STRING: "5090" SNMPv2-SMI::enterprises.1729.100.1.10.16.0 type=4 value=STRING: "host2" SNMPv2-SMI::enterprises.1729.100.1.10.17.0 type=4 value=STRING: "StatServer" SNMPv2-SMI::enterprises.1729.100.1.10.18.0 type=4 value=STRING: "Clearance" SNMPv2-SMI::enterprises.1729.100.1.10.19.0 type=4 value=STRING: "A190A7C9-59B5-4F9D-8B93-4306EC749620" SNMPv2-SMI::enterprises.1729.100.1.10.20.0 type=4 value=STRING: "host-ejemplo" SNMP-COMMUNITY-MIB::snmpTrapAddress.0 type=64 value=IpAddress: 198.18.48.220 SNMP-COMMUNITY-MIB::snmpTrapCommunity.0 type=4 value=STRING: "Monitoreo" SNMPv2-MIB::snmpTrapEnterprise.0 type=6 value=OID: SNMPv2-SMI::enterprises.1729.104
Estos son solo 2 ejemplos de la misma alarma, hay muchos traps distintos y la experiencia nos ha enseñado que la única OID para cada alarma es el OID SNMPv2-SMI::enterprises.1729.100.1.10.19.0 ya que todos los otros valores, o son únicos por cada trap, o no son únicos para cada alarma. También notamos que esta OID tendrá un valor con un formato especifico de letras y números
Una vez conocido esto, voy a usar la información que sea única por cada alarma para voy a agregar un tag al trigger y así Zabbix pueda identificar que evento debe resolver cuando llegue el trap de limpieza.
Para crear los tags usamos las funciones iregsub o regsub junto a alguna macros que puedan ser usadas para tags. Para la versión que trabajamos usé la macro {ITEM.VALUE} lo cual indicara que aplicaremos la función al valor que gatillo el evento. Para fines prácticos elegí usar la función iregsub, la única diferencia entre una y la otra función es que regsub es sensible a mayusculas e iregusb es insensible a ellas.
El resultado final para extraer el tag que queremos es:
{{ITEM.VALUE}.iregsub("([0-9A-Z]{8}-[0-9A-Z]{4}-[0-9A-Z]{4}-[0-9A-Z]{4}-[0-9A-Z]{12})", \1)}
con esa regrex indicamos que el valor que guardaremos es «A190A7C9-59B5-4F9D-8B93-4306EC749620»
Luego solo basta con indicar en la configuración del trigger una expresión de recuperación, que el evento se resolverá cuando se cumpla la condición, y que se resuelvan los eventos que cumplan con el criterio del tag
Ya con esta configuración en el frontend, podemos lograr que Zabbix sea capas de identificar una alarma de otra y poder realizar la limpieza necesaria cuando llegue un trap de «cleared».
Como comente anteriormente SNMP requiere mas tiempo para realizar la configuración necesaria, dependemos bastante de la documentación para configurarlo de forma óptima pero es una potente herramienta para monitorear lo que no alcanza a visualizar el agente Zabbix o cuando no se puede instalar el agente.
¿y tú has tenido alguna experiencia donde hayas que tenido que configurar SNMP en Zabbix?
Leo tus comentarios!