Snmp agent item on host failed another network error wait for 15 seconds

SNMP agent item failed: first network error, wait for 15 seconds

Details

Description

I have distributed monitoring that using proxies for check devices on client-side.

Some of my proxies generates alot of errors:
1857:20141028:105659.890 SNMP agent item «IfHCOutOctets [FastEthernet0/21] » on host «rostovdon-1-sw1» failed: first network error, wait for 15 seconds
1799:20141028:105705.803 SNMP agent item «ifHCInOctets [FastEthernet0/20] » on host «izjevsk-1-sw1» failed: first network error, wait for 15 seconds
2502:20141028:105708.190 resuming SNMP agent checks on host «volgograd-1-sw1»: connection restored
1910:20141028:105708.847 SNMP agent item «locIfInRunts [Vlan100] » on host «samara-1-sw1» failed: first network error, wait for 15 seconds
2266:20141028:105709.161 SNMP agent item «locIfCollisions [FastEthernet0/32] » on host «ho-1-sw2» failed: first network error, wait for 15 seconds
1765:20141028:105711.973 SNMP agent item «locIfInIgnored [GigabitEthernet0/3] » on host «ho-1-sw3» failed: first network error, wait for 15 seconds
2502:20141028:105714.215 resuming SNMP agent checks on host «rostovdon-1-sw1»: connection restored
1706:20141028:105715.072 SNMP agent item «IfHCOutOctets [FastEthernet0/43] » on host «ho-1-sw4» failed: first network error, wait for 15 seconds
2348:20141028:105718.883 SNMP agent item «ifAdminStatus [FastEthernet0/18] » on host «lipeck-1-sw1» failed: first network error, wait for 15 seconds
1705:20141028:105719.233 SNMP agent item «locIfInRunts [GigabitEthernet2/0/6] » on host «n.novgorod-cc-c3750» failed: first network error, wait for 15 seconds
2502:20141028:105720.238 resuming SNMP agent checks on host «izjevsk-1-sw1»: connection restored
1639:20141028:105721.030 SNMP agent item «locIfInCRC [FastEthernet0/20] » on host «n.novgorod-cc-sw1» failed: first network error, wait for 15 seconds
2502:20141028:105723.339 resuming SNMP agent checks on host «samara-1-sw1»: connection restored
1760:20141028:105723.698 SNMP agent item «ifHCInOctets [Vlan20] » on host «stavropol-1-sw1» failed: first network error, wait for 15 seconds
2502:20141028:105724.348 resuming SNMP agent checks on host «ho-1-sw2»: connection restored
2425:20141028:105725.493 SNMP agent item «ifInErrors [FastEthernet0/12] » on host «n.novgorod-cc-sw3» failed: first network error, wait for 15 seconds
2502:20141028:105726.356 resuming SNMP agent checks on host «ho-1-sw3»: connection restored
1915:20141028:105727.808 SNMP agent item «ifOutErrors [Vlan1] » on host «n.novgorod-cc-sw4» failed: first network error, wait for 15 seconds
1999:20141028:105728.901 SNMP agent item «locIfInFrame [FastEthernet0/2] » on host «tula-1-sw1» failed: first network error, wait for 15 seconds
2502:20141028:105730.374 resuming SNMP agent checks on host «ho-1-sw4»: connection restored
2502:20141028:105733.387 resuming SNMP agent checks on host «lipeck-1-sw1»: connection restored
2502:20141028:105734.398 resuming SNMP agent checks on host «n.novgorod-cc-c3750»: connection restored

and looks like some of items don’t recieved for a long time (bcause queue proxy queue for a day). this is only snmp item problem.

anyway. i try to get those items by snmpget/snmpwalk In loop and doesnt have any problem.

also i have tried many variations:
oracle linux 6.6 + zabbix_proxy 2.4.1 + vmware-tools drivers(vmxnet3) + esxi 5.1
oracle linux 6.6 + zabbix_proxy 2.4.1 + linux embeded drivers(vmxnet3) + esxi 5.1
oracle linux 6.6 + zabbix_proxy 2.4.1 + vmware-tools drivers(vmxnet3) + esxi 5.5
oracle linux 6.6 + zabbix_proxy 2.4.1 + linux embeded drivers(vmxnet3) + esxi 5.5
ubuntu 14.04 LTS + zabbix_proxy 2.4.1 + vmware-tools drivers(vmxnet3) + esxi 5.1
ubuntu 14.04 LTS + zabbix_proxy 2.4.1 + linux embeded drivers(vmxnet3) + esxi 5.1

and right now i trying to test on hardware server..

Источник

another network error retrying to get a value

Details

Description

I have problems with retrying to get a value.
First found in version 1.9.7 (fresh install), upgrade to 1.9.9 didn’t fixed it. Tested on 2 servers with lots of clients.
I found some fixed issues on similar errors, but it seems they are not completely fixed, upgrade to the 1.9.9 doen’t help.

Logs are populated with the following:
17808:20120210:161916.259 resuming Zabbix agent checks on host [lari-casino] : connection restored
17821:20120210:161923.164 resuming Zabbix agent checks on host [gw.viaden.com] : connection restored
17796:20120210:161925.241 Zabbix agent item [system.swap.size [,pfree] ] on host [lari-poker] failed: first network error, wait for 20 seconds
17751:20120210:161929.219 Zabbix agent item [system.cpu.load [,avg15] ] on host [lari-casino] failed: first network error, wait for 20 seconds
17812:20120210:161949.182 resuming Zabbix agent checks on host [lari-casino] : connection restored
17782:20120210:161958.749 Zabbix agent item [vm.memory.size [total] ] on host [gw.viaden.com] failed: first network error, wait for 20 seconds
17782:20120210:162005.730 Zabbix agent item [vfs.fs.size [/,pfree] ] on host [lari-casino] failed: first network error, wait for 20 seconds
17819:20120210:162018.302 resuming Zabbix agent checks on host [gw.viaden.com] : connection restored
17816:20120210:162025.407 resuming Zabbix agent checks on host [lari-casino] : connection restored
17785:20120210:162102.411 Zabbix agent item [vfs.fs.inode [/home,pfree] ] on host [lari-casino] failed: first network error, wait for 20 seconds
17806:20120210:162122.346 resuming Zabbix agent checks on host [lari-casino] : connection restored
17714:20120210:162124.508 Zabbix agent item [system.cpu.util [,idle,avg1] ] on host [gw.viaden.com] failed: first network error, wait for 20 seconds
17793:20120210:162126.288 Zabbix agent item [vm.memory.inactive] on host [gw.viaden.com] failed: another network error, wait for 20 seconds
17726:20120210:162140.805 Zabbix agent item [system.cpu.load [,avg1] ] on host [lari-casino] failed: first network error, wait for 20 seconds
17805:20120210:162146.459 resuming Zabbix agent checks on host [gw.viaden.com] : connection restored
17805:20120210:162200.672 resuming Zabbix agent checks on host [lari-casino] : connection restored

Note, keys and servers are different.
Tested different UnreachableDelay (from 5 to 20).
This is not connectivity issue, the same time tested with multiple zabbix_get — no errors at all.

The agent log with debug enabled shows no errors — it always sends data back.
tcpdump shows a lot of RST flags from server. It doesn’t seem to be right tcp session end.

I tried to disable checks on host, wait until queue is cleared, then start monitoring again. It doesn’t help.
Agent and server restarts sometimes help, sometimes not. The issue occurs randomly and can dissaper after some time (few hours ordinary), or stay for a long time.
There are no strange spikes on the internal zabbix monitoring graphs (except housekeeping tasks), network activity and pooling are stable.

Источник

Note.wdm.net.ua

my notes

Zabbix failed another network error

История: Zabbix начал периодично показывать недоступность 2-х из 61 узлов. Началось ночью в воскресенье. Периодичность разная от 2 до 30 минут.

Описание:
Zabbix сервер 3.2 на Debian 7.11.
V01 – Windows. Zabbix агент 2.0.8 (revision 38015)
V06 – Windows. Zabbix агент 2.0.8 (revision 38015)

Все хосты лежат на одном гипервизоре ESXi, в одном VLAN-е, в одной подсети.

Выглядит так:

Гипервизор – не показывает Статусы в Health Status. Пишет на них “Unknown”. Операция Reset Sensors – не выполняется. Получено ответ:

Смотрим в лог Zabbix-сервера, видим:

Никаких действий с хостами до или в момент начало проблемы не производилось. Хосты не выключались 497 дней.

В момент наличия проблемы: загрузка CPU, сети – у самих хостов и гипервизора – минимальная. Никакой активности.

Анализ сетевого трафика между клиентами и сервером забикса ничего не дал: все ходит, задержек нет:

Маршрут между клиентами и сервером:

Включил Debug=4 на сервере забикс для поиска причины:

Перезапуск заббикс-агентов/забикс сервера – ничего не дал. Наверное и не должен был.

Обновление агента до Zabbix 3.2.0 (revision 62444) – ничего не изменило.
Установка значения Timeout=10 на агенте – ничего не дало.

Перезапуск хоста V01 помог. – По нему сообщения “failed: first network error” в логе перестали появляться.

Увидел задержку c Zabbix-сервера увидел. После 3-4-ой команды идет тайм-аут:

Та же команда с соседнего сервера (FreeBSD 10.3) не ловит тайм-аут, сколько бы раз не запускал :

Отключение/включение сетевого интерфейса на хосте 192.168.112.56 не дало эффекта.

Перегрузили V06 (192.168.112.56) – проблема ушла.

Источник

Some SNMP hosts don’t become available after being unavailable till zabbix server restart

Details

Description

I monitor network devices thru snmpv3 over the internet. I use authPriv, aesdes encryption and SHA authentication.

When power is lost or internet link to my network is down, the snmp devices get unavailable in zabbix. After connection is restored sometimes some of the devices don’t become available till zabbix server restart. I can simulate this specially cause it doesn’t repeat constantly.

When it happens I get:
temporarily disabling SNMP agent checks on host «. «: host unavailable

and for some devices it’s the last message till zabbix server restart. After restarting zabbix server I get:
enabling SNMP agent checks on host «»: host became available
very quikly.

Attachments

Issue Links

ZBX-8385 snmpV3 report (response) «usmStatsNotInTimeWindows» treated as NETWORK_ERROR, which is bad and may mislead

• Reopened
  This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved. «>Reopened

ZBX-11806 Some SNMP hosts still don’t become available after being unavailable till zabbix server restart

• Closed
  The issue is considered finished, the resolution is correct. Issues which are closed can be reopened. «>Closed

Источник

using «Interfaces» as Application name makes the host unavailable

Details

Description

I have configured a host with SNMP observing several SNMP values.

As soon as I create an Application named «Interfaces» the previous working snmp request stops working.

The server.log shows:

18793:20111222:173250.415 SNMP item [Port_22_In_Octets] on host [test] failed: first network error, wait for 15 seconds
18791:20111222:173251.413 SNMP item [Port_22_Out_Octets] on host [test] failed: another network error, wait for 15 seconds
18795:20111222:173252.418 SNMP item [Port_22_In_Errors] on host [test] failed: another network error, wait for 15 seconds
18794:20111222:173253.428 SNMP item [Port_22_Out_Errors] on host [test] failed: another network error, wait for 15 seconds
18796:20111222:173314.066 SNMP item [Port_22_Out_Octets] on host [test] failed: another network error, wait for 15 seconds
18796:20111222:173335.086 SNMP item [Port_22_Out_Errors] on host [test] failed: another network error, wait for 15 seconds
18796:20111222:173356.119 temporarily disabling SNMP checks on host [test] : host unavailable
18796:20111222:173456.128 enabling SNMP checks on host [test] : host became available

I then have to completely remove the host from the db and recreate it. Just removing the Application association does not help.

Without having this association SNMP retrieval works without any issue.

Источник

Диагностика работы сервера и агента Zabbix. Самые простые способы найти причины неработоспособности.

Проблемы, проблемы, проблемы…

В предыдущей статье мы рассматривали процесс установки Zabbix. Сегодня мы коснемся основных способов диагностики работы сервера и агента Zabbix, а также решение некоторых возникающих проблем.

Ничего сверхестественного. Только базовая информация, которая дает представление о том куда нужно двигаться при наличии проблем в работе мониторинга на базе Zabbix.

Как себя чувствует сервер

Бывает, что на сервере возникают какие-либо проблемы, связанные как с самой службой Zabbix-сервера, так и с его взаимодействием с агентами или связанными компонентами. Первый источник информации, который может помочь в поиске причин проблем — это логи Zabbix-сервера. Еще одним важным источником данных может быть сама система мониторинга, которая мониторит сама себя.

Логи наше все

Логи по традиции мира *.nix хранятся в текстовых файлах и располагаются в каталоге ‘/var/log/zabbix’.

[ypermitin@zabbix zabbix]$ ls
zabbix_agentd.log              zabbix_agentd.log-20201011  zabbix_server.log-20201004.gz
zabbix_agentd.log-20201004.gz  zabbix_server.log           zabbix_server.log-20201011

В этом же каталоге можно увидеть файлы логов Zabbix-агента. Чаще всего на сервере Zabbix для отслеживания работы сервера установлен агент. Да, Zabbix-сервер следит сам за собой.

Прочитать содержимое можно стандартными для Linux способами:

• Смотрим файл логов с возможностью прокрутки.

less /var/log/zabbix/zabbix_server.log

• Просмотр файла логов в реальном времени.

tail -f /var/log/zabbix/zabbix_server.log

• Смотрим первые записи

head /var/log/zabbix/zabbix_server.log

• Смотрим последние события

tail -n 30 /var/log/zabbix/zabbix_server.log

• Получаем только записи с ошибками

grep -i error /var/log/zabbix/zabbix_server.log

В общем, это самые простые способы прочитать содержимое файла логов. Если Вы знаете что нужно искать, то grep Вам в помощью. В противном случае в бой вступает tail, но можно выполнять анализ и более сложными способами.

Вот, например, вывод последних 10 событий из файла логов.

[ypermitin@zabbix zabbix]$ tail -n 10 /var/log/zabbix/zabbix_server.log

  1370:20201016:230008.844 housekeeper [deleted 4601 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit items in 0.047217 sec, idle for 1 hour(s)]
  1370:20201017:000346.901 executing housekeeper
  1370:20201017:000346.958 housekeeper [deleted 4857 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit items in 0.053027 sec, idle for 1 hour(s)]
  1386:20201017:002028.428 Zabbix agent item "system.swap.size[,free]" on host "YY-COMP" failed: first network error, wait for 15 seconds
  1394:20201017:002043.521 Zabbix agent item "system.uptime" on host "YY-COMP" failed: another network error, wait for 15 seconds
  1394:20201017:002058.554 Zabbix agent item "agent.ping" on host "YY-COMP" failed: another network error, wait for 15 seconds
  1394:20201017:002113.579 temporarily disabling Zabbix agent checks on host "YY-COMP": host unavailable
  1394:20201017:003815.366 enabling Zabbix agent checks on host "YY-COMP": host became available
  1370:20201017:010352.434 executing housekeeper
  1370:20201017:010352.503 housekeeper [deleted 4599 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit items in 0.063396 sec, idle for 1 hour(s)]

Здесь мы видим события процесса housekeeper, который отвечает за удаление устаревшей информации из базы данных мониторинга. Далее идут более интересные события об ошибке связи с хостом “YY-COMP”, а также события последующего восстановления соединения с агентом этого хоста.

 1386:20201017:002028.428 Zabbix agent item "system.swap.size[,free]" on host "YY-COMP" failed: first network error, wait for 15 seconds
  1394:20201017:002043.521 Zabbix agent item "system.uptime" on host "YY-COMP" failed: another network error, wait for 15 seconds
  1394:20201017:002058.554 Zabbix agent item "agent.ping" on host "YY-COMP" failed: another network error, wait for 15 seconds
  1394:20201017:002113.579 temporarily disabling Zabbix agent checks on host "YY-COMP": host unavailable
  1394:20201017:003815.366 enabling Zabbix agent checks on host "YY-COMP": host became available

В любом случае, основным источником данных о том, что и как делает процесс Zabbix-сервера, есть ли у него проблемы и другую связанную с ним информацию можно найти в его логах. Метод “тыка” тоже работает, но эффективнее просто посмотреть в файл лога событий.

Мониторинг системы мониторинга

Благодаря тому, что Zabbix позволяет собирает метрики о состоянии самого себя, мы можем отслеживать некоторые проблемы с его помощью. После установки сервера, по умолчанию в списке хостов содержится сам сервер с шаблоном “Template App Zabbix Server”.

Этот шаблон является ключевым для диагностики работы Zabbix, т.к. содержит множество полезных метрик и триггеров на критичные события.

Например, если Вы увидите уведомления о проблеме “Zabbix poller processes more than 75% busy” от одного из триггеров этого шаблона, то идем в официальную документацию и читаем что это. Можно увидеть, что проблему можно решить изменив параметр “StartPollers” в файле конфигурации Zabbix-сервера.

Вообще, оптимизация настроек этой системы мониторинга отдельная тема, но должно быть понятно, что следить за сервером Zabbix является неотъемлемой частью мониторинга. Иначе как Вы узнаете, что пора актуализировать настройки сервера или проапгрейдить железо?

Все в очередь

Кроме логов и мониторинга Zabbix-сервера есть еще один важный показатель, демонстрирующий общую картину производительности процессов системы мониторинга. Причем помогает диагностировать проблемы не только в работе сервера, но и агентов Zabbix.

Речь идет про очередь обработки элементов данных, которая отлично описана в официальной документации. На следующем скриншоте показана идеальная картина, когда никаких очередей нет и все элементы обрабатываются за минимальное время.

Самыми распространёнными причинами увеличения очереди являются:

• Агент сбора данных стал недоступен и не присылает данные / не может ответить на запрос.
• У сервера не хватает ресурсов для выполнения обработки присланных элементов данных или опроса хостов (зависит от типа агента — активный или пассивный).

В случаях, когда Вы будете наблюдать большие значения очередей с периодом обработки более 1 минуты, то стоит насторожиться и начать диагностику сервера и агентов.

Вы всегда можете посмотреть элементы очереди детально, чтобы понять, где именно появилась проблема. Плюс ко всему, очередь обработки сообщений можно добавить в метрики сбора данных мониторинга и привязать на них триггеры. Таким образом, очереди позволяют отслеживать общее состояние как сервера Zabbix, так и состояние всего мониторинга с учетом агентов.

База данных требует внимания

Zabbix хранит данные метрик в одной из поддерживаемых СУБД: MySQL или PostgreSQL. Для оптимальной производительности обязательно нужно выполнить их настройку. Я предпочитаю использовать PostgreSQL, но тут все полностью зависит от задач.

Касательно PostgreSQL нужно обязательно адаптировать ее настройки под ресурсы сервера, т.к. по умолчанию там установлены максимальные ограничения на используемую память и другие ресурсы. Рекомендую зайти на сайт PGTune, который поможет подобрать параметры СУБД под Ваш сервер. Просто берете и переносите их в свой файл конфигурации “postgresql.conf”.

Конечно, со временем может понадобиться адаптировать эти параметры под свою нагрузку и задачи. Подробнее о настройках Вы можете прочитать здесь.

То же самое относится и к MySQL. Вы можете обратиться к официальной документации, чтобы узнать больше.

Главное помнить, что настройки сервера баз данных являются ключевым фактором для достижения высокой производительности всей системы мониторинга.

Агент еще жив

Основные способы диагностики сервера Zabbix мы рассмотрели. А что на счет агентов на хостах, которые входят в мониторинг?

Выше уже было упомянуто, что у агента есть свои логи. Именно они и являются основным источником данных для диагностики его работы. Если мы говорим о *.nix системах, то обычно файл лога находится в “/var/log/zabbix/zabbix_agent.log”. Вот, например, его содержимое при старте процесса агента.

[ypermitin@zabbix zabbix]$ tail -n 30 /var/log/zabbix/zabbix_agentd.log
 88139:20201017:164146.511 Starting Zabbix Agent [Zabbix server]. Zabbix 4.0.25 (revision 32662425e6).
 88139:20201017:164146.511 **** Enabled features ****
 88139:20201017:164146.511 IPv6 support:          YES
 88139:20201017:164146.511 TLS support:           YES
 88139:20201017:164146.511 **************************
 88139:20201017:164146.511 using configuration file: /etc/zabbix/zabbix_agentd.conf
 88139:20201017:164146.511 agent #0 started [main process]
 88140:20201017:164146.511 agent #1 started [collector]
 88141:20201017:164146.512 agent #2 started [listener #1]
 88144:20201017:164146.513 agent #5 started [active checks #1]
 88143:20201017:164146.515 agent #4 started [listener #3]
 88142:20201017:164146.516 agent #3 started [listener #2]

Это идеальный вариант, когда агент был запущен и никаких проблем с его работой не наблюдается. Но там могут быть и ошибки или информация о проблемах связи. Например, вот это событие говорит о том, что что-то блокирует доступ агента к серверу Zabbix.

  3900:20201017:002349.716 active check configuration update from [192.168.11.149:10051] started to fail (cannot connect to [[192.168.11.149]:10051]: (null))

Может не открыт порт на сервере? Или сервер недоступен? Или ошибка в конфигурационном файле агента?

Аналогичный файл лога есть для агентов всех поддерживаемых операционных систем, в том числе и Windows. Его расположение можно уточнить в самом конфигурационном файле агента в параметре “LogFile”. Для Windows это может быть каталог самого агента, например:

### Option: LogFile
#	Log file name for LogType 'file' parameter.
#
# Mandatory: no
# Default:
# LogFile=

LogFile=C:Program FilesZabbixAgentzabbix_agentd.log

В любом случае, если у Вас проблемы в работе агента, то первым делом идем в его логи и смотрим что вообще происходит.

Решение некоторых проблем

Рассмотрим решение некоторых проблем в работе сервера и агента. Это ни в коем случае не полноценный мануал, а скорее пара заметок. Небольшая порция “траблшутинга”. Более развернутую информацию Вы можете найти в официальной Wiki.

Немного опечатались

Иногда бывает так, что порты и все доступы настроены, агент установлен, ошибок в логах нет, но метрики не приходят или приходят не полностью. В самом Zabbix хост “горит зеленым” и непонятно, что вообще происходит.

Можно потратить много времени на разбор ситуации, а причина окажется очень проста — ошибка в файле конфигурации из-за “копипасты”. То есть конфигурацию скопировали, но в файле не поменяли параметр “Hostname”. В итоге сервер Zabbix говорит, что агент доступен, но сам агент присылает данные для другого хоста. Вот так выглядит список дисков для проблемной машины. Нет никакой информации о дисках, но при этом общие показатели агент все же передал.

Как только мы исправим в файле конфигурации параметр “Hostname” на нужный (в нашем случае это “SRV-SQL-01-VM”), то картина сразу же изменится. В списке появятся все диски сервера.

Данные могут появиться не сразу, т.к. правила обнаружения выполняются не так часто, как получение обычных метрик, но Вы можете запустить их вручную в настройках хоста.

Копипаст — зло! Будьте осторожны!

Ребут и агента нет

Бывают случаи, когда агент был успешно установлен и настроен на хосте, мониторинг работает как надо. НО! При очередном запланированном перезапуске сервера (хоста) Zabbix-агент не смог запуститься.

Причин тому может быть несколько:

• Агент запускается от доменной учетной записи, но на момент старта сервера связи с доменом не оказалось.
• В момент запуска агент пытался запуститься, когда еще не “поднялся” доступ к сети.

При этом в файле лога агента может не быть какой-либо полезной информации, но она есть в системных журналах ОС. Чаще всего это поведение встречал в ОС Windows.

Решение достаточно простое: нужно установить для службы Windows режим запуска “Автоматически (отложенный запуск)”. В большинстве случаев проблема будет решена.

Быстро и просто!

Особые проблемы со счетчиками

Особой проблемой, которая встречается не очень часто, бывают проблемы со счетчиками производительности Windows. После настройки мониторинга на сервере можно увидеть для хоста элементы данных со статусом “Не поддерживается”. При этом все они получаются через показатели производительности Windows. Обратившись к логам агента Zabbix можно увидеть следующее.

zabbix agent log: check_counter_path(): cannot make counterpath
zabbix agent log: A required argument is missing or not correct.... active check "perf_counter[....]" is not supported

При этом для хоста у элементов данных будет такая ошибка.

ZBX_NOTSUPPORTED: Cannot obtain system information.

Проблема в некорректном списке доступных счетчиков производительности Windows на хосте с агентом, то есть на машине, которую мы собираемся мониторить. Можно проверить наличие нужного счетчика через “Монитор производительности” (perfmon.exe) или через ветку реестра:

"HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionPerflib09"

# Ключ "Counter" содержит список всех доступных счетчиков производительности.

Если нужного счетчика нет, то можно попытаться перестроить все счетчики ОС командой:

lodctr /r

# Утилита находится в "C:WINDOWSSystem32"

В большинстве случаев это помогает. Если остаются проблемы со счетчиками производительности сторонних приложений, то нужно изучить документацию по этим счетчикам. Например, для Microsoft SQL Server можно отдельно восстановить счетчики из поставляемых настроек. Подробнее можно узнать здесь.

Счетчики производительности для мониторинга Windows — отличный инструмент. И его, конечно же, нужно использовать.

Таймаут выполнения скриптов

Еще небольшой ошибкой может быть ситуация, когда на сервер не поступают данные по каким-либо элементам данных, а в логах агента можно увидеть ошибки вида:

ZBX_NOTSUPPORTED: Timeout while executing a shell script

Так происходит, поскольку выполняемый скрипт не укладывается в заданное время выполнения. Время задается также в конфигурации агента Zabbix и по умолчанию составляет 3 секунды.

### Option: Timeout
#	Spend no more than Timeout seconds on processing
#
# Mandatory: no
# Range: 1-30
# Default:
# Timeout=3

Имеется три основных варианта решения:

• Увеличить таймаут до подходящего значения. Например, до 30 секунд:

### Option: Timeout
#	Spend no more than Timeout seconds on processing
#
# Mandatory: no
# Range: 1-30
# Default:
# Timeout=3

Timeout=30

• Второй вариант — разобраться в причинах долгого выполнения и попытаться их исправить. Конечно, если это возможно.

• Отказаться от сбора этих метрик

В любом случае, посмотрите почему скрипт может выполняться дольше, чем запланировано. Только после этого меняйте настройки.

Продолжение следует

Это была еще одна небольшая публикация по теме мониторинга с помощью Zabbix. В следующих статьях мы поговорим об обновлении Zabbix с версии 4.0 на 5.0, создадим свой шаблон для сбора метрик и рассмотрим некоторые особенности этого процесса, настроим уведомления в Telegram-канал, а также получении данных с Prometheus и визуализации данных в Grafana. И, конечно же, оптимизация производительности сервера мониторинга Zabbix!

Будьте на связи

Будьте в курсе

Создание материалов будет продолжаться. Хотите быть в курсе последних обновлений? Подписывайтесь на канал.

По любым вопросам пишите на электронную почту. Адрес в самом низу страницы.

    for (i = 0; i < num; i++)
    {
        switch (errcodes[i])
        {
            case SUCCEED:
            case NOTSUPPORTED:
            case AGENT_ERROR:
                if (HOST_AVAILABLE_TRUE != last_available)
                {
                    zbx_activate_item_host(&items[i], &timespec);
                    last_available = HOST_AVAILABLE_TRUE;
                }
                break;
            case NETWORK_ERROR:
            case GATEWAY_ERROR:
            case TIMEOUT_ERROR:
                if (HOST_AVAILABLE_FALSE != last_available)
                {
                    zbx_deactivate_item_host(&items[i], &timespec, results[i].msg);
                    last_available = HOST_AVAILABLE_FALSE;
                }
                break;
            case CONFIG_ERROR:
                /* nothing to do */
                break;
            default:
                zbx_error("unknown response code returned: %d", errcodes[i]);
                THIS_SHOULD_NEVER_HAPPEN;
        }

Here is the code for zbx_deactivate_item_host:

void    zbx_deactivate_item_host(DC_ITEM *item, zbx_timespec_t *ts, const char *error)                       //   #0
{
    const char        *__function_name = "zbx_deactivate_item_host";
    zbx_host_availability_t    in, out;                                                                         //   #1
    unsigned char        agent_type;                                                                          //   #2

    zabbix_log(LOG_LEVEL_DEBUG, "In %s() hostid:" ZBX_FS_UI64 " itemid:" ZBX_FS_UI64 " type:%d",             //   #3
            __function_name, item->host.hostid, item->itemid, (int)item->type);

    zbx_host_availability_init(&in, item->host.hostid);                                                      //   #4
    zbx_host_availability_init(&out,item->host.hostid);                                                      //   #5

    if (ZBX_AGENT_UNKNOWN == (agent_type = host_availability_agent_by_item_type(item->type)))                //   #6
        goto out;

    if (FAIL == host_get_availability(&item->host, agent_type, &in))                                         //   #7
        goto out;

    if (FAIL == DChost_deactivate(item->host.hostid, agent_type, ts, &in.agents[agent_type],                 //   #8
            &out.agents[agent_type], error))
    {
        goto out;
    }

    if (FAIL == db_host_update_availability(&out))                                                           //   #9
        goto out;

    host_set_availability(&item->host, agent_type, &out);                                                    //   #10

    if (0 == in.agents[agent_type].errors_from)                                                              //   #11
    {
        zabbix_log(LOG_LEVEL_WARNING, "%s item "%s" on host "%s" failed:"                                //   #12
                " first network error, wait for %d seconds",
                zbx_agent_type_string(item->type), item->key_orig, item->host.host,
                out.agents[agent_type].disable_until - ts->sec);
    }
    else
    {
        if (HOST_AVAILABLE_FALSE != in.agents[agent_type].available)                                         //   #13
        {
            if (HOST_AVAILABLE_FALSE != out.agents[agent_type].available)                                    //   #14
            {
                zabbix_log(LOG_LEVEL_WARNING, "%s item "%s" on host "%s" failed:"                        //   #15
                        " another network error, wait for %d seconds",
                        zbx_agent_type_string(item->type), item->key_orig, item->host.host,
                        out.agents[agent_type].disable_until - ts->sec);
            }
            else
            {
                zabbix_log(LOG_LEVEL_WARNING, "temporarily disabling %s checks on host "%s":"              //   #16
                        " host unavailable",
                        zbx_agent_type_string(item->type), item->host.host);
            }
        }
    }

    zabbix_log(LOG_LEVEL_DEBUG, "%s() errors_from:%d available:%d", __function_name,
            out.agents[agent_type].errors_from, out.agents[agent_type].available);
out:
    zbx_host_availability_clean(&out);
    zbx_host_availability_clean(&in);

    zabbix_log(LOG_LEVEL_DEBUG, "End of %s()", __function_name);
}

Here’s the logic of the zbx_deactivate_item_host code:

The #0 zbx_deactivate_item_host function receives three parameters

        1 Structural Pointer, Some Comprehensive Parameters of Host
            //dbcache.h 
            typedef struct
            {
                DC_HOST            host;
                DC_INTERFACE        interface;
                zbx_uint64_t        itemid;
                zbx_uint64_t        lastlogsize;
                zbx_uint64_t        valuemapid;
                unsigned char        type;
                unsigned char        value_type;
                unsigned char        state;
                unsigned char        snmpv3_securitylevel;
                unsigned char        authtype;
                unsigned char        flags;
                unsigned char        snmpv3_authprotocol;
                unsigned char        snmpv3_privprotocol;
                unsigned char        inventory_link;
                unsigned char        status;
                unsigned char        history;
                unsigned char        trends;
                unsigned char        follow_redirects;
                unsigned char        post_type;
                unsigned char        retrieve_mode;
                unsigned char        request_method;
                unsigned char        output_format;
                unsigned char        verify_peer;
                unsigned char        verify_host;
                unsigned char        allow_traps;
                char            key_orig[ITEM_KEY_LEN * ZBX_MAX_BYTES_IN_UTF8_CHAR + 1], *key;
                char            *units;
                char            *delay;
                int            history_sec;
                int            nextcheck;
                int            lastclock;
                int            mtime;
                char            trapper_hosts[ITEM_TRAPPER_HOSTS_LEN_MAX];
                char            logtimefmt[ITEM_LOGTIMEFMT_LEN_MAX];
                char            snmp_community_orig[ITEM_SNMP_COMMUNITY_LEN_MAX], *snmp_community;
                char            snmp_oid_orig[ITEM_SNMP_OID_LEN_MAX], *snmp_oid;
                char            snmpv3_securityname_orig[ITEM_SNMPV3_SECURITYNAME_LEN_MAX], *snmpv3_securityname;
                char            snmpv3_authpassphrase_orig[ITEM_SNMPV3_AUTHPASSPHRASE_LEN_MAX], *snmpv3_authpassphrase;
                char            snmpv3_privpassphrase_orig[ITEM_SNMPV3_PRIVPASSPHRASE_LEN_MAX], *snmpv3_privpassphrase;
                char            ipmi_sensor[ITEM_IPMI_SENSOR_LEN_MAX];
                char            *params;
                char            username_orig[ITEM_USERNAME_LEN_MAX], *username;
                char            publickey_orig[ITEM_PUBLICKEY_LEN_MAX], *publickey;
                char            privatekey_orig[ITEM_PRIVATEKEY_LEN_MAX], *privatekey;
                char            password_orig[ITEM_PASSWORD_LEN_MAX], *password;
                char            snmpv3_contextname_orig[ITEM_SNMPV3_CONTEXTNAME_LEN_MAX], *snmpv3_contextname;
                char            jmx_endpoint_orig[ITEM_JMX_ENDPOINT_LEN_MAX], *jmx_endpoint;
                char            timeout_orig[ITEM_TIMEOUT_LEN_MAX], *timeout;
                char            url_orig[ITEM_URL_LEN_MAX], *url;
                char            query_fields_orig[ITEM_QUERY_FIELDS_LEN_MAX], *query_fields;
                char            *posts;
                char            status_codes_orig[ITEM_STATUS_CODES_LEN_MAX], *status_codes;
                char            http_proxy_orig[ITEM_HTTP_PROXY_LEN_MAX], *http_proxy;
                char            *headers;
                char            ssl_cert_file_orig[ITEM_SSL_CERT_FILE_LEN_MAX], *ssl_cert_file;
                char            ssl_key_file_orig[ITEM_SSL_KEY_FILE_LEN_MAX], *ssl_key_file;
                char            ssl_key_password_orig[ITEM_SSL_KEY_PASSWORD_LEN_MAX], *ssl_key_password;
                char            *error;
            }
            DC_ITEM;
        2 Structure pointer
            //common.h
            typedef struct
            {
                int    sec;    /* seconds */
                int    ns;    /* nanoseconds */
            }
            zbx_timespec_t;
            
        3 error message

# 1 defines two structured arrays in and out

        //db.h
        typedef struct
        {
            /* flags specifying which fields are set, see ZBX_FLAGS_AGENT_STATUS_* defines */
            unsigned char    flags;

            /* agent availability fields */
            unsigned char    available;
            char        *error;
            int        errors_from;
            int        disable_until;
        }
        zbx_agent_availability_t;

        typedef struct
        {
            zbx_uint64_t            hostid;

            zbx_agent_availability_t    agents[ZBX_AGENT_MAX];         //There ZBX_AGENT_MAX 4, respectively. ZABBIX, SNMP, IPMI, JMX4 Species type
        }
        zbx_host_availability_t;

    //dbconfig.c
    void    zbx_host_availability_init(zbx_host_availability_t *availability, zbx_uint64_t hostid)
    {
        memset(availability, 0, sizeof(zbx_host_availability_t));
        availability->hostid = hostid;
    }

Like # 4, it’s just OUT.

# 6 assigns value to agent_type, if agent_type does not belong to the four types in # 1, jump to out

    1,host_availability_agent_by_item_type Be located poller.c，Receive item Of type Field to determine the type of monitoring
    //poller.c
        static unsigned char    host_availability_agent_by_item_type(unsigned char type)
        {
            switch (type)
            {
                case ITEM_TYPE_ZABBIX:
                    return ZBX_AGENT_ZABBIX;
                    break;
                case ITEM_TYPE_SNMPv1:
                case ITEM_TYPE_SNMPv2c:
                case ITEM_TYPE_SNMPv3:
                    return ZBX_AGENT_SNMP;
                    break;
                case ITEM_TYPE_IPMI:
                    return ZBX_AGENT_IPMI;
                    break;
                case ITEM_TYPE_JMX:
                    return ZBX_AGENT_JMX;
                    break;
                default:
                    return ZBX_AGENT_UNKNOWN;
            }
        }
    2,ZBX_AGENT_UNKNOWN Constant as 255 Corresponding to previous #2

#7 Judges the availability of the host based on agent_type, and the network device matches ZBX_AGENT_SNMP. The four values represent

    //poller.c
    static int    host_get_availability(const DC_HOST *dc_host, unsigned char agent, zbx_host_availability_t *ha)
    {
        zbx_agent_availability_t    *availability = &ha->agents[agent];

        availability->flags = ZBX_FLAGS_AGENT_STATUS;

        switch (agent)
        {
            case ZBX_AGENT_ZABBIX:
                availability->available = dc_host->available;
                availability->error = zbx_strdup(NULL, dc_host->error);
                availability->errors_from = dc_host->errors_from;
                availability->disable_until = dc_host->disable_until;
                break;
            case ZBX_AGENT_SNMP:
                availability->available = dc_host->snmp_available;  //Mainframe snmp Available state
                availability->error = zbx_strdup(NULL, dc_host->snmp_error);  //error message
                availability->errors_from = dc_host->snmp_errors_from;      //Error occurrence time
                availability->disable_until = dc_host->snmp_disable_until;  //Next Delay Detection Time
                break;
            case ZBX_AGENT_IPMI:
                availability->available = dc_host->ipmi_available;
                availability->error = zbx_strdup(NULL, dc_host->ipmi_error);
                availability->errors_from = dc_host->ipmi_errors_from;
                availability->disable_until = dc_host->ipmi_disable_until;
                break;
            case ZBX_AGENT_JMX:
                availability->available = dc_host->jmx_available;
                availability->error = zbx_strdup(NULL, dc_host->jmx_error);
                availability->disable_until = dc_host->jmx_disable_until;
                availability->errors_from = dc_host->jmx_errors_from;
                break;
            default:
                return FAIL;
        }

        ha->hostid = dc_host->hostid;

        return SUCCEED;
    }

    //dbcache.h
    typedef struct
    {
        zbx_uint64_t    hostid;
        zbx_uint64_t    proxy_hostid;
        char        host[HOST_HOST_LEN_MAX];
        char        name[HOST_NAME_LEN * ZBX_MAX_BYTES_IN_UTF8_CHAR + 1];
        unsigned char    maintenance_status;
        unsigned char    maintenance_type;
        int        maintenance_from;
        int        errors_from;
        unsigned char    available;
        int        disable_until;
        int        snmp_errors_from;
        unsigned char    snmp_available;
        int        snmp_disable_until;
        int        ipmi_errors_from;
        unsigned char    ipmi_available;
        int        ipmi_disable_until;
        signed char    ipmi_authtype;
        unsigned char    ipmi_privilege;
        char        ipmi_username[HOST_IPMI_USERNAME_LEN_MAX];
        char        ipmi_password[HOST_IPMI_PASSWORD_LEN_MAX];
        int        jmx_errors_from;
        unsigned char    jmx_available;
        int        jmx_disable_until;
        char        inventory_mode;
        unsigned char    status;
        unsigned char    tls_connect;
        unsigned char    tls_accept;
    #if defined(HAVE_POLARSSL) || defined(HAVE_GNUTLS) || defined(HAVE_OPENSSL)
        char        tls_issuer[HOST_TLS_ISSUER_LEN_MAX];
        char        tls_subject[HOST_TLS_SUBJECT_LEN_MAX];
        char        tls_psk_identity[HOST_TLS_PSK_IDENTITY_LEN_MAX];
        char        tls_psk[HOST_TLS_PSK_LEN_MAX];
    #endif
        char        error[HOST_ERROR_LEN_MAX];
        char        snmp_error[HOST_ERROR_LEN_MAX];
        char        ipmi_error[HOST_ERROR_LEN_MAX];
        char        jmx_error[HOST_ERROR_LEN_MAX];
    }
    DC_HOST;
    
    //db.h
    #define ZBX_FLAGS_AGENT_STATUS_AVAILABLE    0x00000001
    #define ZBX_FLAGS_AGENT_STATUS_ERROR        0x00000002
    #define ZBX_FLAGS_AGENT_STATUS_ERRORS_FROM    0x00000004
    #define ZBX_FLAGS_AGENT_STATUS_DISABLE_UNTIL    0x00000008
    #define ZBX_FLAGS_AGENT_STATUS        (ZBX_FLAGS_AGENT_STATUS_AVAILABLE |    
                        ZBX_FLAGS_AGENT_STATUS_ERROR |        
                        ZBX_FLAGS_AGENT_STATUS_ERRORS_FROM |    
                        ZBX_FLAGS_AGENT_STATUS_DISABLE_UNTIL) 

     
    //common.h
    #define    FAIL        -1

# 8 Setting the host status according to agent_type

    //dbconfig.c
    int    DChost_deactivate(zbx_uint64_t hostid, unsigned char agent_type, const zbx_timespec_t *ts,
            zbx_agent_availability_t *in, zbx_agent_availability_t *out, const char *error_msg)
    {
        int        ret = FAIL, errors_from,disable_until;
        const char    *error;
        unsigned char    available;
        ZBX_DC_HOST    *dc_host;


        /* don't try deactivating host if the unreachable delay has not passed since the first error */
        if (CONFIG_UNREACHABLE_DELAY > ts->sec - in->errors_from) 
            goto out;

        WRLOCK_CACHE;

        if (NULL == (dc_host = (ZBX_DC_HOST *)zbx_hashset_search(&config->hosts, &hostid)))
            goto unlock;

        /* Don't try deactivating host if:                */
        /* - (server, proxy) it's not monitored any more; */
        /* - (server) it's monitored by proxy.            */
        if ((0 != (program_type & ZBX_PROGRAM_TYPE_SERVER) && 0 != dc_host->proxy_hostid) ||
                HOST_STATUS_MONITORED != dc_host->status)
        {
            goto unlock;
        }

        DChost_get_agent_availability(dc_host, agent_type, in);

        available = in->available;
        error = in->error;

        if (0 == in->errors_from)
        {
            /* first error, schedule next unreachable check */
            errors_from = ts->sec;
            disable_until = ts->sec + CONFIG_UNREACHABLE_DELAY;
        }
        else
        {
            errors_from = in->errors_from;
            disable_until = in->disable_until;

            /* Check if other pollers haven't already attempted deactivating host. */
            /* In that case should wait the initial unreachable delay before       */
            /* trying to make it unavailable.                                      */
            if (CONFIG_UNREACHABLE_DELAY <= ts->sec - errors_from)
            {
                /* repeating error */
                if (CONFIG_UNREACHABLE_PERIOD > ts->sec - errors_from)
                {
                    /* leave host available, schedule next unreachable check */
                    disable_until = ts->sec + CONFIG_UNREACHABLE_DELAY;
                }
                else
                {
                    /* make host unavailable, schedule next unavailable check */
                    disable_until = ts->sec + CONFIG_UNAVAILABLE_DELAY;
                    available = HOST_AVAILABLE_FALSE;
                    error = error_msg;
                }
            }
        }

        zbx_agent_availability_init(out, available, error, errors_from, disable_until);
        DChost_set_agent_availability(dc_host, ts->sec, agent_type, out);

        if (ZBX_FLAGS_AGENT_STATUS_NONE != out->flags)
            ret = SUCCEED;
    unlock:
        UNLOCK_CACHE;
    out:
        return ret;
    }

Mainly look at this paragraph:

if (0 == in->errors_from)
        {
            /* first error, schedule next unreachable check */
            errors_from = ts->sec;
            disable_until = ts->sec + CONFIG_UNREACHABLE_DELAY;
        }
        else
        {
            errors_from = in->errors_from;
            disable_until = in->disable_until;

            /* Check if other pollers haven't already attempted deactivating host. */
            /* In that case should wait the initial unreachable delay before       */
            /* trying to make it unavailable.                                      */
            if (CONFIG_UNREACHABLE_DELAY <= ts->sec - errors_from)
            {
                /* repeating error */
                if (CONFIG_UNREACHABLE_PERIOD > ts->sec - errors_from)
                {
                    /* leave host available, schedule next unreachable check */
                    disable_until = ts->sec + CONFIG_UNREACHABLE_DELAY;
                }
                else
                {
                    /* make host unavailable, schedule next unavailable check */
                    disable_until = ts->sec + CONFIG_UNAVAILABLE_DELAY;
                    available = HOST_AVAILABLE_FALSE;
                    error = error_msg;
                }
            }
        }

        If the error occurs for the first time:
            Error occurrence time = check timestamp
            Next check time = timestamp + 15s
        Otherwise:
            Error occurrence time = in - > errors_from
            Next check time = in - > disable_until

            Check timestamp - error occurrence time >= 15s:
                Check timestamp - error occurrence time < 45s:
                    Next check time = check time stamp + 15s
                Otherwise:
                    Next check time = check timestamp + 15s
                    Host availability is unavailable
            

Configuration file is used to explain that if the project is not monitored in time due to network and other reasons, the first monitoring interval is Unreachable Delay time (15s). If this time also fails, then from the first failure to this inspection in Unreachable Period time, it will be monitored again after Unreachable Delay time.

# 9 Update Host Availability Information in the Database

    // poller.c
    static int    db_host_update_availability(const zbx_host_availability_t *ha)
    {
        char    *sql = NULL;
        size_t    sql_alloc = 0, sql_offset = 0;

        if (SUCCEED == zbx_sql_add_host_availability(&sql, &sql_alloc, &sql_offset, ha))
        {
            DBbegin();
            DBexecute("%s", sql);
            DBcommit();

            zbx_free(sql);

            return SUCCEED;
        }

        return FAIL;
    }

# 10 Setting Host Availability Information Based on agent_type

    //poller.c
    static int    host_set_availability(DC_HOST *dc_host, unsigned char agent, const zbx_host_availability_t *ha)
    {
        const zbx_agent_availability_t    *availability = &ha->agents[agent];
        unsigned char            *pavailable;
        int                *perrors_from, *pdisable_until;
        char                *perror;

        switch (agent)
        {
            case ZBX_AGENT_ZABBIX:
                pavailable = &dc_host->available;
                perror = dc_host->error;
                perrors_from = &dc_host->errors_from;
                pdisable_until = &dc_host->disable_until;
                break;
            case ZBX_AGENT_SNMP:
                pavailable = &dc_host->snmp_available;
                perror = dc_host->snmp_error;
                perrors_from = &dc_host->snmp_errors_from;
                pdisable_until = &dc_host->snmp_disable_until;
                break;
            case ZBX_AGENT_IPMI:
                pavailable = &dc_host->ipmi_available;
                perror = dc_host->ipmi_error;
                perrors_from = &dc_host->ipmi_errors_from;
                pdisable_until = &dc_host->ipmi_disable_until;
                break;
            case ZBX_AGENT_JMX:
                pavailable = &dc_host->jmx_available;
                perror = dc_host->jmx_error;
                pdisable_until = &dc_host->jmx_disable_until;
                perrors_from = &dc_host->jmx_errors_from;
                break;
            default:
                return FAIL;
        }

        if (0 != (availability->flags & ZBX_FLAGS_AGENT_STATUS_AVAILABLE))
            *pavailable = availability->available;

        if (0 != (availability->flags & ZBX_FLAGS_AGENT_STATUS_ERROR))
            zbx_strlcpy(perror, availability->error, HOST_ERROR_LEN_MAX);

        if (0 != (availability->flags & ZBX_FLAGS_AGENT_STATUS_ERRORS_FROM))
            *perrors_from = availability->errors_from;

        if (0 != (availability->flags & ZBX_FLAGS_AGENT_STATUS_DISABLE_UNTIL))
            *pdisable_until = availability->disable_until;

        return SUCCEED;
    }

#11-16
If it is the first inspection:
Log the first network error, wait for 15 seconds
Otherwise:
If the host in the database is available if displayed:
Log another network error, wait for 15 seconds
Otherwise
Log temporarily disabling (the green icon on the previous page turns red)

As can be seen from the above code, in the case of three middle schools, network errors, wait for 15s seconds logs are generated in the process of poller network errors, gateway problems, or check timeouts. In summary, the connection between zabbix server and ZABBIX agent and the sending and receiving of data can not succeed or occur when the time spent in a series of processing to obtain data exceeds the Timeout parameter of zabbix server.

The process from normal values to exception handling is as follows:

Unreachable Delay, Unreachable Delay, Unreachable Delay, Unnavailable Delay
                  |                                       |                              |
                  |                                       |                              |
                  ————————UnreachablePeriod————
    1             2                                                              3                                4                           5

Process, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log, Log

• 1. Obtaining normal monitoring data
  2. Error ————> first network
  Make another mistake.
  Set 4 as unavailable.
  5. Recovery ———-> resuming

• 1, network instability
• 2, device end problem
• 3, poller queued up.
• 4, Timeout is out of time.

• 1. Using public network to realize IDC interconnection, that is, the checked device and server are not in the same IDC. In this case, it is suggested to add proxy on the other end so that the detection of the end-to-end device is carried out in the intranet.
• 2. Using cloud-based network and using cloud-based network interconnection to connect cloud-based devices and IDC. This kind of network is a kind of black box for users, which can hardly be eliminated. If you use large-scale services, occasional log errors will occur, but it will not affect the use experience.

Circumstances of network device-side problems:

• 1. Equipment performance: How to judge the network device side problem? Deug snmp information can be used on the network device to see whether each packet has returned or misreported. This situation can increase the interval of snmp adoption.
• 2. The port bandwidth of the end-to-end and server connections is full

Above is my understanding and experience of using the log alarm wait for 15s seconds in zabbix. If the content of this article is helpful to you, please give me a compliment. If you find something wrong in the article, please leave a message to me too. Thank you.