On host zabbix server failed first network error wait for 15 seconds - Исправление ошибок и поиск оптимальных решений проблем

Zabbix

Заметил, что хосты очень плохо мониторятся через IPMI, никак не мог понять в чём дело. И вот сегодня звёзды сложились так, что удалось подметить некоторую закономерность в поведении хостов.

С помощью ipmitool получаем значения сенсоров одного из хостов. Получение информации о сенсорах IPMI с помощью ipmitool. В примере ниже это my_server_dns_name, не суть важно:

root@zabbix:~# ipmitool -I lanplus -H my_server_dns_name -U my_user -P my_password sensor list
***
FAN1             | 3200.000   | RPM        | ok    | 300.000   | 500.000   | 700.000   | 25300.000 | 25400.000 | 25500.000
FAN2             | 3100.000   | RPM        | ok    | 300.000   | 500.000   | 700.000   | 25300.000 | 25400.000 | 25500.000
FAN3             | 3100.000   | RPM        | ok    | 300.000   | 500.000   | 700.000   | 25300.000 | 25400.000 | 25500.000
FAN4             | na         |            | na    | na        | na        | na        | na        | na        | na
FAN5             | 3200.000   | RPM        | ok    | 300.000   | 500.000   | 700.000   | 25300.000 | 25400.000 | 25500.000
FAN6             | 3100.000   | RPM        | ok    | 300.000   | 500.000   | 700.000   | 25300.000 | 25400.000 | 25500.000
***

В качестве примера я оставил только сенсоры вентиляторов.

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

Третий пункт: в заббиксе относительно нормально отображаются значения первых трёх вентиляторов, хотя график всё равно рваный. А пятый и шестой почти не отображаются или не отображаются вовсе. Думал, что IPMI сервис плохо работает на серверах, но нет.

Случайно заметил в логах zabbix-сервера такую картину:

1174:20180816 IPMI agent item "ipmi.supermicro.fan4" on host "server1" failed: first network error, wait for 15 seconds
1174:20180816 IPMI agent item "ipmi.supermicro.fan4" on host "server2" failed: first network error, wait for 15 seconds
1174:20180816 resuming IPMI agent checks on host "server55": connection restored
1174:20180816 resuming IPMI agent checks on host "server66": connection restored
1174:20180816 IPMI agent item "ipmi.supermicro.fan4" on host "server3" failed: first network error, wait for 15 seconds

Это четвёртый пункт. Странность заключается в том, что сенсор один и тот же, а сервера разные.

Если обобщить все странности, то получается следующее:

Zabbix-сервер имеет таблицу IPMI сенсоров и бежит циклом по этим сенсорам в алфавитном порядке.
Берет FAN1, получает значение этого сенсора для каждого хоста, которому это значение нужно получить.
Пишет полученные значения, потом берет следующий сенсор FAN2, потом FAN3, пока всё в порядке.
Доходит до сенсора в состоянии «na» — у нас это FAN 4 — не находит его на server1 и пишет «first network error, wait for 15 seconds».
И получение IPMI сенсоров для server1 останавливается на 15 секунд, для всех IPMI сенсоров!
Дальше zabbix-сервер пытается найти FAN4 у server2, если его не находит, то » wait for 15 seconds».
Пробегает по всем остальным хостам, уже не важно находит он у них FAN4 или нет, хосты заканчиваются.
Zabbix-сервер берет FAN5, бежит по серверам, доходит до server1. А хост-то всё ещё » wait for 15 seconds», 15 секунд не прошли, заббикс пропускает этот сервер.
В итоге для server1 значение FAN5 не записывается, хотя сенсор прекрасно работает.
С FAN6 та же история, если 15 секунд не прошли, то значение не записывается.
Потом 15 секунд простоя истекают, хост дальше нормально мониторится.

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

Что делать? Избавляться от «na» сенсоров. Проанализируем наши шаблоны. Если все сервера внутри шаблона имеют одинаковую конфигурацию, то ставим все сенсоры «na» в disabled. Если сервера имеют разную конфигурацию (у кого-то сенсор работает, у кого-то нет), то ставим все сенсоры «na» в disabled уже на каждом конкретном хосте.

Сделал так в рамках одного из шаблонов, — провалы прекратились, полёт нормальный.

Источник

Диагностика работы сервера и агента 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!

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

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

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

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

Источник

Recommended: ASR Pro

1. Download and install ASR Pro

2. Open the program and click «Scan»

3. Click «Repair» to start the repair process

Download this software and fix your PC in minutes.

In the past few days, some users reported that they faced the first network error from zabbix.

 6024: 20200313: 153058.081 SNMP agent element 'net.if.status [ifOperStatus.232]' on node 'sw-isp-1.domain.net' failed: first network error, please wait 15 seconds 5887: 20200313: 150425.014 Error of Zabbix agent element "net.if.in [xenbr3]" when building "xen-qa-5.srv.domain": first network error, hang for 15 seconds  6024: 20200313: 150425.029 Zabbix insurance agent item "system.boottime" on host "xen-qa-2.srv.domain" failed: first network error, wait 11 seconds  6048: 20200313: 150425.072 Zabbix agent module "vfs.fs.size [/ var / log, pfree]" on host "xen-qa-1.srv.domain" failed: first network error, wait 13 seconds  5906: 20200313: 150425.101 Zabbix agent entry "net.if.in [vive10.2]" on host "xen-qa-6.srv.domain" failed first: market error, please wait 15 seconds  6052: 20200313: 150449.791 Zabbix resumes agent checks via host "xen-qa-1.srv.domain": connection reestablished  6128: 20200313: 150449.791 Return to Zabbix agent when checking table "xen-qa-6.srv.domain": connection restored  6073: 20200313: 150449.791 Returns to Zabbix agent "xen-qa-2.srv.domain": connection has been restored  6094: 20200313: 150449.797 Continue checking host Zabbix agent for "xen-qa-5.srv.domain": port restored  6009: 20200313: 150842.939 Zabbix agent target "net.if.out [eth2]" on host "xen-qa-1.srv.domain" failed: network error firstbka wait 17 seconds 5981: 20200313: 150842 .946 Zabbix agent item "net.if.out [vive16.0]" on host "xen-qa-5.srv.domain" failed: first website 2.0 error, please wait 15 seconds  5928: 20200313: 150843.096 Zabbix agent item "net.if.out [vive26.3]" failed on host "xen-qa-4.srv.domain": first web 2.0 error, wait seconds 15 6129: 20200313: 150859.177 Returning to Zabbix agent checks many "xen-qa-5.srv.domain": connection reestablished  6077: 20200313: 150859.177 Zabbix agent type "xen-qa-1.srv.domain" is being checked: connection reestablished  6118: 20200313: 150859.188 Zabbix falls back to agent checks on host "xen-qa-4.srv.domain": greetings restored  5927: 20200313: 151413.109 Zabbix agent "net.if.in [vive1.3]" on host "xen-qa-4.srv.domain" does not work at first: network error, please wait 17 seconds  5955: 20200313: 151413.138 Zabbix agent program 'net.if.in [vive17.3]' failed on host 'xen-qa-5.srv.domain': transient error, network wait 15 seconds  6013: 20200313: 151413.156 Zabbix agent item "vfs.fs.size [/ var / log, used]" failed on host "xen-qa-6.srv.domain": first internet connection error, please wait 15 seconds  5929: 20200313: 151413.163 Failure of Zabbix agent item "net.if.out [vive28.1]" on host server "xen-qa-3.srv.domain": first network error, 15 seconds delay  6126: 20200313: 151428.459 ReturnGo to agent Zabbix checks host on your "xen-qa-6.srv.domain": connection reestablished  6055: 20200313: 151428.462 Zabbix agent continuation to check host "xen-qa-4.srv.domain": greetings restored  6126: 20200313: 151428.468 Continue checking by Zabbix employee on host "xen-qa-5.srv.domain": add-on restored  6099: 20200313: 151428.470 will continue checking the Zabbix agent host for "xen-qa-3.srv.domain": connection reestablished

I may have found out that there is more, but I think mine might be a little different, so I’ll make another post …

I have installed Zabbix 2.2.4. I have nvps 24 so it doesn’t really matter. I think even the processor and terminals are fine …

Recommended: ASR Pro

Are you tired of your computer running slowly? Is it riddled with viruses and malware? Fear not, my friend, for ASR Pro is here to save the day! This powerful tool is designed to diagnose and repair all manner of Windows issues, while also boosting performance, optimizing memory, and keeping your PC running like new. So don’t wait any longer — download ASR Pro today!

1. Download and install ASR Pro

2. Open the program and click «Scan»

3. Click «Repair» to start the repair process

The problem is that I have more hosts with the disease, as explained, specifically for one host:

The host has more than 300 titles (about 330). I check the connection with the internet host every 4 seconds and look for its “nameStation” every 10 seconds. The rest of the items are read every 150 seconds.

The problem starts when Zabbix starts up with a host request for more than 300 items … As far as tcpdump performance is concerned, there are manyo requests that are answered almost simultaneously, but only occasionally by snmp. And after an error occurs and Zabbix does not read any new values, perhaps the host (late) even triggers snmp responses …

After a while you continue and the situation repeats itself. This works until Zabbix wants to install these 300+ items. It’s almost 5 minutes …

1823: 20140904: 123638.996 Host SNMP agent part ‘rTxFrequency’ on ‘X’ failed: error in first circle, please wait 15 seconds
1893: 20140904: 123653.913 Resume SNMP Management Agent if Host X: Connection Reestablished
1824: 20140904: 124138.988 SNMP Agent Element Node ‘ifType [1]’ found on ‘X’ failed: first network error held for 15 seconds
1888: 20140904: 124154.005 Return to SNMP agent checks on storage “X”: connection restored
1857: 20140904: 124638.970 SNMP Alternate Agent “stTermServNumber” on Host “X” Broken: First Network Error, Wait 15 Seconds
1884: 20140904: 124654.137 Resuming SNMP advisor checks on host “X”: ownership restored

Can I somehow configure Not zabbix so that you want to have all the values ”withonce “?

(I think maybe changing the repetition to other values could solve your problem? Instead of 300 seconds, set yourself to 290 seconds, 291 seconds, 292 seconds, …)

Or in newer Zabbix (2 version 4), where there is a hint in the exception notes (for the beta provided by the experts), the snmp-bulk request would be customizable … so I could say “just ask to find 5 values in the big quantity of another request “?

Download this software and fix your PC in minutes.

Zabbix 첫 번째 네트워크 오류
Pervaya Setevaya Oshibka Zabbix
Zabbix Erster Netzwerkfehler
Primer Error De Red De Zabbix
Zabbix Eerste Netwerkfout
Zabbix Forsta Natverksfel
Zabbix Pierwszy Blad Sieci

Источник

Содержание

Диагностика работы Zabbix
Проблемы, проблемы, проблемы…
Как себя чувствует сервер
Логи наше все
Мониторинг системы мониторинга
Все в очередь
База данных требует внимания
Агент еще жив
Решение некоторых проблем
Немного опечатались
Ребут и агента нет
Особые проблемы со счетчиками
Таймаут выполнения скриптов
Продолжение следует
Будьте в курсе
Zabbix — проблема с получением значений некоторых IPMI сенсоров

Диагностика работы Zabbix

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

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

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

Логи наше все

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

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

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

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

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

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

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

Все в очередь

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

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

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

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

Агент еще жив

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Zabbix — проблема с получением значений некоторых IPMI сенсоров

В качестве примера я оставил только сенсоры вентиляторов.

Случайно заметил в логах zabbix-сервера такую картину:

Это четвёртый пункт. Странность заключается в том, что сенсор один и тот же, а сервера разные.

Если обобщить все странности, то получается следующее:

Zabbix-сервер имеет таблицу IPMI сенсоров и бежит циклом по этим сенсорам в алфавитном порядке.
Берет FAN1, получает значение этого сенсора для каждого хоста, которому это значение нужно получить.
Пишет полученные значения, потом берет следующий сенсор FAN2, потом FAN3, пока всё в порядке.
Доходит до сенсора в состоянии «na» — у нас это FAN 4 — не находит его на server1 и пишет «first network error, wait for 15 seconds».
И получение IPMI сенсоров для server1 останавливается на 15 секунд, для всех IPMI сенсоров!
Дальше zabbix-сервер пытается найти FAN4 у server2, если его не находит, то » wait for 15 seconds».
Пробегает по всем остальным хостам, уже не важно находит он у них FAN4 или нет, хосты заканчиваются.
Zabbix-сервер берет FAN5, бежит по серверам, доходит до server1. А хост-то всё ещё » wait for 15 seconds», 15 секунд не прошли, заббикс пропускает этот сервер.
В итоге для server1 значение FAN5 не записывается, хотя сенсор прекрасно работает.
С FAN6 та же история, если 15 секунд не прошли, то значение не записывается.
Потом 15 секунд простоя истекают, хост дальше нормально мониторится.

Сделал так в рамках одного из шаблонов, — провалы прекратились, полёт нормальный.

Источник

I would say I troubleshot this for days and I mean that as a way of saying this was hard for me to pinpoint, but I understand that «days» could also be taken as, «oh, wow, it took him way too long to find this.»

Let me start off by saying, this Zabbix service is something I maintain in my free time, and free time comes at a premium these days.

Ok, the error: ...item [item] on host [host] failed: first network error, wait for 15 seconds.

When I built the server that hosts most of my services at home, I was in a hurry. As I said above, free time is limited so I needed to get this system up and running as fast as possible. The problem with this is that I didn’t have any time to tune things. Not for ZFS, not for mysql, nothing.

Everything had been running just fine for months and then the Zabbix error started, flooding my inbox with warnings. In a rush, I power cycled the system. I don’t know why, maybe my repressed Windows sysadmin days were itching to resurface, but I did it. This seemed to resolve the issue for a few days but then it was back. The next time, I started to troubleshoot like a proper unix admin:

Firewall — No blocks to MySQL or 10050
tcpdump — TCP packets on port 10050 are present
ZFS
- IOPS not saturated (zpool iostat)
- Tuned for database zvol:
  - zfs set recordsize=16k [db zvol]
  - zfs set primarycache=metadata [db zvol]
  - zfs set logbias=throughput [db zvol]
MySQL — tuned to leverage ZFS
- Added innodb_doublewrite = 0 to my.cnf
- Moved MySQL data to a tuned zvol

Everything looked fine, however, as I was refreshing the Zabbix webui, I occasionally received a php - php_network_getaddresses: getaddrinfo failed error. To access the Zabbix UI, I have to pass through an Nginx TLS engine & reverse proxy. All of these sit on the same server, just in separate jails with seperate FIBs for each.

This got me digging into the firewall. Since each jail communicates to neighboring jails via the firewall (router on a stick), I started looking at the states present on the firewall.

When I first deployed Zabbix, I was hitting nearly 20K states. During my troubleshooting, it was only reporting 12K states. The firewall should be able to handle 1.5 million states so it wasn’t the firewall.

Turns out, pf on FreeBSD has a default state limit…

(pts/0)[user@server2:~]# pfctl -sm
states        hard limit    10000
src-nodes     hard limit    10000
frags         hard limit     5000
table-entries hard limit   200000

And there it is! My 10K state bottleneck.

After adding set limit { states 40000, frags 20000, src-nodes 30000 } to /etc/pf.conf and issuing a service pf reload, I had plenty of room!

Zabbix health graphs quickly returned to normal while the server returned to processing 130 values per second, the firewall started displaying 20K+ states again, and the PHP errors were gone!

Subscribe to Haraschak Blog

Get the latest posts delivered right to your inbox

Great! Check your inbox and click the link to confirm your subscription.

Please enter a valid email address!

Источник

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

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

Логи наше все

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

Все в очередь

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

Агент еще жив

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

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

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

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

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

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

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

Recommended: ASR Pro

Recommended: ASR Pro

Диагностика работы Zabbix

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

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

Логи наше все

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

Все в очередь

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

Агент еще жив

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

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

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

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

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

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

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

Zabbix — проблема с получением значений некоторых IPMI сенсоров

Subscribe to Haraschak Blog

Читайте также: