Всем доброго дня.
если мы получаем snmp трапы, в которых есть описание проблемы в одном из OID, при этом нет описания всех возможных трапов и приходится ловить и обрабатывать "как есть" (то есть потенциально может быть большое неизвестное число разных типов трапов). Но есть OID, который является указанием на уровень критичности и содержит 4 различных значения severity (.0.1 - .0.4). Соответственно, в ключе item'а прописываем условие по этому OID'у и получаем только 4 разных item'a. Для триггера вытащить описание из трапа не проблема, но т.к. выражение триггера (=ключу item'а) не отличается (для одного уровня критичности), то проблема всегда одна (первый трап), все остальное уходит в историю и не генерится новая проблема. То есть трапов может быть много разных о разных вещах, а проблема всегда одна для каждого уровня критичности. Т.к. списка описаний трапов нет, то и создать заранее отдельные элементы под них не получается, поэтому и ограничиваемся только общим регекспом
пример трапа
17:44:40 2022/05/25 ZBXTRAP х.х.х.х
VARBINDS:
.1.3.6.1.2.1.1.3.0 type=67 value=Timeticks: (44287590) 5 days, 3:01:15.90 .1.3.6.1.6.3.1.1.4.1.0 type=6 value=OID: .1.3.6.1.4.1.1139.21.0.3 .1.3.6.1.4.1.1139.21.1.1.0 type=4 value=STRING: "CKM00164500975" .1.3.6.1.4.1.1139.21.1.2.0 type=2 value=INTEGER: 0 .1.3.6.1.4.1.1139.21.1.3.0 type=4 value=STRING: "2315399417" .1.3.6.1.4.1.1139.21.1.4.0 type=4 value=STRING: "The average I/O latency on a storage-volume has exceeded the acceptable limit, likely due to increased latency on the backend storage array or fabrics between the VPLEX and storage-array." .1.3.6.1.4.1.1139.21.1.5.0 type=4 value=STRING: "Storage volume DS3Par02-23-C2 performance has degraded. Average read I/O latency increased from 21.491 milliseconds to 1372.910 milliseconds, which is above the acceptable limit of 200 milliseconds. Based on 85 I/Os observed during a 300 second period."
в триггере сообщение - {{ITEM.VALUE}.regsub("\.1\.3\.6\.1\.4\.1\.1139\.21 \.1\.4\.0.*"([^"]*)".*\.1\.3\.6\.1\.4\.1\.1139\.21\.1\.5\.0.*STRI N G: "([^"]+)"", "\2 (\1)")}
то есть вытаскиваются два последних OID
выражение привязано к item - nodata(/zbx_storage/snmptrap["\.1\.3\.6\.1\.4\.1\.1139\.21\.0\.2.*"],86400)=0
потому как создано только 4 item'a с фильтром по snmptrap["\.1\.3\.6\.1\.4\.1\.1139\.21\.0\.2.*"] - этот OID содержит 4 различных значения severity (.0.1 - .0.4)
История выглядит так (не для указанного выше примера, но суть одинакова):
Вопросы:
1) как сделать так, чтобы проблема возникала для каждого уникального трапа, а для каждого повторяющегося - нет (только в историю помещалось бы). Может какую функцию можно применить тут, типа change. или решение тут только - для каждого нового типа трапа создавать свой объект и триггер? Но т.к. описания трапов нет (не нашел), то не факт, что внутрянка даже для одного типа будет совпадать. Да и сам процесс настройки может затянуться
2) после ручного закрытия проблемы, она сразу появляется снова, причем с описанием из последнего трапа в истории (которое может совпадать с "закрытым", а может и нет...зависит от последовательности прихода трапов). Почему так может происходить? Как пофиксить?
3) как организовать автоматическое закрытие проблемы, для которой нет "трапа-ОК"? через nodata?
4) Можно ли заставить заббикс обновить описание проблемы в UI, если пришел новый трап этого же типа (например как в примере выше, только цифры другие)?
если мы получаем snmp трапы, в которых есть описание проблемы в одном из OID, при этом нет описания всех возможных трапов и приходится ловить и обрабатывать "как есть" (то есть потенциально может быть большое неизвестное число разных типов трапов). Но есть OID, который является указанием на уровень критичности и содержит 4 различных значения severity (.0.1 - .0.4). Соответственно, в ключе item'а прописываем условие по этому OID'у и получаем только 4 разных item'a. Для триггера вытащить описание из трапа не проблема, но т.к. выражение триггера (=ключу item'а) не отличается (для одного уровня критичности), то проблема всегда одна (первый трап), все остальное уходит в историю и не генерится новая проблема. То есть трапов может быть много разных о разных вещах, а проблема всегда одна для каждого уровня критичности. Т.к. списка описаний трапов нет, то и создать заранее отдельные элементы под них не получается, поэтому и ограничиваемся только общим регекспом
пример трапа
17:44:40 2022/05/25 ZBXTRAP х.х.х.х
VARBINDS:
.1.3.6.1.2.1.1.3.0 type=67 value=Timeticks: (44287590) 5 days, 3:01:15.90 .1.3.6.1.6.3.1.1.4.1.0 type=6 value=OID: .1.3.6.1.4.1.1139.21.0.3 .1.3.6.1.4.1.1139.21.1.1.0 type=4 value=STRING: "CKM00164500975" .1.3.6.1.4.1.1139.21.1.2.0 type=2 value=INTEGER: 0 .1.3.6.1.4.1.1139.21.1.3.0 type=4 value=STRING: "2315399417" .1.3.6.1.4.1.1139.21.1.4.0 type=4 value=STRING: "The average I/O latency on a storage-volume has exceeded the acceptable limit, likely due to increased latency on the backend storage array or fabrics between the VPLEX and storage-array." .1.3.6.1.4.1.1139.21.1.5.0 type=4 value=STRING: "Storage volume DS3Par02-23-C2 performance has degraded. Average read I/O latency increased from 21.491 milliseconds to 1372.910 milliseconds, which is above the acceptable limit of 200 milliseconds. Based on 85 I/Os observed during a 300 second period."
в триггере сообщение - {{ITEM.VALUE}.regsub("\.1\.3\.6\.1\.4\.1\.1139\.21 \.1\.4\.0.*"([^"]*)".*\.1\.3\.6\.1\.4\.1\.1139\.21\.1\.5\.0.*STRI N G: "([^"]+)"", "\2 (\1)")}
то есть вытаскиваются два последних OID
выражение привязано к item - nodata(/zbx_storage/snmptrap["\.1\.3\.6\.1\.4\.1\.1139\.21\.0\.2.*"],86400)=0
потому как создано только 4 item'a с фильтром по snmptrap["\.1\.3\.6\.1\.4\.1\.1139\.21\.0\.2.*"] - этот OID содержит 4 различных значения severity (.0.1 - .0.4)
История выглядит так (не для указанного выше примера, но суть одинакова):
| 26.05.2022 03:00:55 | 03:00:54 2022/05/26 VARBINDS: .1.3.6.1.2.1.1.3.0 type=67 value=Timeticks: (47292548) 5 days, 11:22:05.48 .1.3.6.1.6.3.1.1.4.1.0 type=6 value=OID: .1.3.6.1.4.1.1139.21.0.3 .1.3.6.1.4.1.1139.21.1.1.0 type=4 value=STRING: "CKM00164500976" .1.3.6.1.4.1.1139.21.1.2.0 type=2 value=INTEGER: 0 .1.3.6.1.4.1.1139.21.1.3.0 type=4 value=STRING: "2322018706" .1.3.6.1.4.1.1139.21.1.4.0 type=4 value=STRING: "Either a large I/O spike has occurred, there are frame drop issues on the fabric, or there is an internal issue in the VPLEX." .1.3.6.1.4.1.1139.21.1.5.0 type=4 value=STRING: "A0-FC01.0: In the last 60 seconds there were a high number of I/O allocation failures (0 ini 9746 tgt 0 tgtrsp)" | |
| 25.05.2022 15:41:46 | 15:41:45 2022/05/25 VARBINDS: .1.3.6.1.2.1.1.3.0 type=67 value=Timeticks: (39174273) 4 days, 12:49:02.73 .1.3.6.1.6.3.1.1.4.1.0 type=6 value=OID: .1.3.6.1.4.1.1139.21.0.3 .1.3.6.1.4.1.1139.21.1.1.0 type=4 value=STRING: "CKM00164500976" .1.3.6.1.4.1.1139.21.1.2.0 type=2 value=INTEGER: 0 .1.3.6.1.4.1.1139.21.1.3.0 type=4 value=STRING: "2322018805" .1.3.6.1.4.1.1139.21.1.4.0 type=4 value=STRING: "Either there are frame drop issues on the fabric or there is an internal issue in the VPLEX." .1.3.6.1.4.1.1139.21.1.5.0 type=4 value=STRING: "B0-FC03.0: In the last 61 seconds 2% of I/O failed on login (npid 0x661700, wwpn 0x50014380231e9d52)" | |
| 25.05.2022 15:02:01 | 15:01:59 2022/05/25 VARBINDS: .1.3.6.1.2.1.1.3.0 type=67 value=Timeticks: (38935648) 4 days, 12:09:16.48 .1.3.6.1.6.3.1.1.4.1.0 type=6 value=OID: .1.3.6.1.4.1.1139.21.0.3 .1.3.6.1.4.1.1139.21.1.1.0 type=4 value=STRING: "CKM00164500976" .1.3.6.1.4.1.1139.21.1.2.0 type=2 value=INTEGER: 0 .1.3.6.1.4.1.1139.21.1.3.0 type=4 value=STRING: "2322018805" .1.3.6.1.4.1.1139.21.1.4.0 type=4 value=STRING: "Either there are frame drop issues on the fabric or there is an internal issue in the VPLEX." .1.3.6.1.4.1.1139.21.1.5.0 type=4 value=STRING: "B0-FC03.0: In the last 56 seconds 2% of I/O failed on login (npid 0x661700, wwpn 0x50014380231e9d52)" |
1) как сделать так, чтобы проблема возникала для каждого уникального трапа, а для каждого повторяющегося - нет (только в историю помещалось бы). Может какую функцию можно применить тут, типа change. или решение тут только - для каждого нового типа трапа создавать свой объект и триггер? Но т.к. описания трапов нет (не нашел), то не факт, что внутрянка даже для одного типа будет совпадать. Да и сам процесс настройки может затянуться
2) после ручного закрытия проблемы, она сразу появляется снова, причем с описанием из последнего трапа в истории (которое может совпадать с "закрытым", а может и нет...зависит от последовательности прихода трапов). Почему так может происходить? Как пофиксить?
3) как организовать автоматическое закрытие проблемы, для которой нет "трапа-ОК"? через nodata?
4) Можно ли заставить заббикс обновить описание проблемы в UI, если пришел новый трап этого же типа (например как в примере выше, только цифры другие)?
Comment