Zabbix failed another network error

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

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

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

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

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

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


История: 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-е, в одной подсети.

Выглядит так:
zabbix-network-01

zabbix-network-02

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

Call "HostHealthStatusSystem.ResetSystemHealthInfo" for object "healthStatusSystem" on ESXi "x1" failed

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

  3116:20161128:113431.461 Zabbix agent item "system.cpu.load[percpu,avg5]" on host "V01" failed: first network error, wait for 15 seconds
  3084:20161128:113454.189 Zabbix agent item "system.cpu.load[percpu,avg15]" on host "V06" failed: first network error, wait for 15 seconds
  3171:20161128:113509.131 resuming Zabbix agent checks on host "V06": connection restored
  3103:20161128:113513.451 Zabbix agent item "net.if.out[WAN Miniport (IP)]" on host "V06" failed: first network error, wait for 15 seconds
  3179:20161128:113516.109 temporarily disabling Zabbix agent checks on host "V01": host unavailable
  3181:20161128:113558.159 temporarily disabling Zabbix agent checks on host "V06": host unavailable
  3194:20161128:113616.142 enabling Zabbix agent checks on host "V01": host became available
  3180:20161128:113646.146 Zabbix agent item "system.uptime" on host "V01" failed: first network error, wait for 15 seconds
  3183:20161128:113700.193 enabling Zabbix agent checks on host "V06": host became available
  3119:20161128:113701.141 Zabbix agent item "net.if.out[]" on host "V01" failed: another network error, wait for 15 seconds
  3117:20161128:113704.182 Zabbix agent item "vfs.fs.size[C:,pfree]" on host "V01" failed: another network error, wait for 15 seconds

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

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

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

# ping 192.168.112.56
PING 192.168.112.56 (192.168.112.56) 56(84) bytes of data.
64 bytes from 192.168.112.56: icmp_req=1 ttl=128 time=0.428 ms
64 bytes from 192.168.112.56: icmp_req=2 ttl=128 time=0.261 ms
64 bytes from 192.168.112.56: icmp_req=3 ttl=128 time=0.298 ms
64 bytes from 192.168.112.56: icmp_req=4 ttl=128 time=0.407 ms

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

# traceroute 192.168.112.56
traceroute to 192.168.112.56 (192.168.112.56), 30 hops max, 60 byte packets
 1  v06.domain.local (192.168.112.56)  0.148 ms * *

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

3743:20161128:100924.105 End of get_value_agent():NETWORK_ERROR
3743:20161128:100924.105 Item [V01:perf_counter[234(_Total)1404]] error: Get value from agent failed: cannot connect to [[192.168.112.51]:10050]: [4] Inte
rrupted system call
3743:20161128:100924.105 End of get_value():NETWORK_ERROR

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

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

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

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

[email protected]: # nc -v -z 192.168.112.56 10050
v06.domain.local [192.168.112.56] 10050 (zabbix-agent) open
[email protected]: # nc -v -z 192.168.112.56 10050
v06.domain.local [192.168.112.56] 10050 (zabbix-agent) : Connection timed out

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

Connection to 192.168.112.56 10050 port [tcp/*] succeeded!
[email protected]: # nc -v -z 192.168.112.56 10050
Connection to 192.168.112.56 10050 port [tcp/*] succeeded!
[email protected]: # nc -v -z 192.168.112.56 10050
Connection to 192.168.112.56 10050 port [tcp/*] succeeded!
[email protected]: # nc -v -z 192.168.112.56 10050
Connection to 192.168.112.56 10050 port [tcp/*] succeeded!

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

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

Настоящая причина не найдена.

Просмотров:
4,595

Profile picture for user Олег

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

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

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

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

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

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

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

Links

  • Homepage
  • zabbix 4 database schema
  • Zabbix compatibility matrix
  • https://www.digitalocean.com/community/tutorials/introduction-to-queries-mysql
  • compilation instructions
  • Documentation
  • Examples of Common Queries
  • Custom scripts
  • Various scripts to automate tasks in Zabbix
  • Tuning mysql for zabbix
  • https://huyabbix.com
  • Migrating zabbix database with minimal downtime
  • Bug tracker
  • Clean up database
  • Zabbix and selinux
  • Apache/SSL checks
  • Zabbix on RHEL/Centos
  • Grafana
  • https://blog.zabbix.com/zabbix-ha-cluster-setups/8264/ Zabbix HA cluster]
  • Active vs Passive
  • Very old network diagram
  • Fighting zabbix alert floods

Documentation

Triggers

  • Trigger functions

Function str() searches for substrings

Installation

  • Zabbix repositories
  • Zabbix on Gentoo

Installing Zabbix from git

git clone https://github.com/zabbix/zabbix.git
cd zabbix 
./bootstrap.sh

Zabbix API

  • The Zabbix API
  • API and python

Zabbix error codes

Z3005

Database issue

Items

Agent item keys

Item dialog

  • Item documentation
  • Zabbix agent items

Units

  • B
  • uptime
  • unixtime
  • s

proc.mem

proc.mem[<name>,<user>,<mode>,<cmdline>,<memtype>]

name

??

cmdline

regex like php-fpm:

memtype

  • Notes on proc.mem memtypes

Item preprocessing

Preprocessing regular expressions

Templates

  • Community templates

Template App MySQL

https://github.com/tiramiseb/zabbix-templates/blob/master/Template%20App%20MySQL.txt
TODO shouldn’t this be user zabbix?

mysql user account:

create user 'monitor'@'localhost' identified by auth_socket;
grant PROCESS,SHOW DATABASES,SHOW VIEW on *.* to 'monitor'@'localhost';
flush privileges;

Configuration

Zabbix agent active

On client

Have port 10051 open and:

ActiveServer zabbix.ser.ver

On server

Set Agent IP to 0.0.0.0

Zabbix and SQL

Find hosts with hostmacro defined

select h.host, m.macro, m.value from hosts h, hostmacro m where macro like '%FOO%' and h.hostid = m.hostid;

most frequent items in history_uint

select itemid,count(itemid) as freq from history_uint group by itemid order by freq desc limit 5;

and then

select name from items where itemid = whateveryoufind;

HOWTO

LLD with JSON

  • LLD with JSON and dependent items

if you want multiple keys, use jsonpath like

$[?(@.share=='{#FSTYPE}' && @.name=='{#NAME}')].size.first()

testing jsonpath preprocessing

In Value paste valid json, then name {#NAME} value somevalue

Test trapper

FAQ

SERVER

Adjust loglevel

zabbix_server --runtime-control log_level_increase=trapper
      

Reload zabbix server configuration

You can’t, but you might want

zabbix_server -c /etc/zabbix/zabbix_server.conf -R config_cache_reload

No media defined for user

The frontend does not match Zabbix database.

Probably version conflict between frontend and server

value cache working in low memory mode

Increase ValueCacheSize

PROXY

Zabbix Proxy

Front end

Round numbers

Preprocessing javascript
2 decimals:

return Math.round(value* 100) / 100

0 decimals:

return Math.round(value)

Visable name vs hostname

Visible name: {HOST.NAME}

Hostname: {HOST.HOST}

Host IP: (as defined in Interface->IP/DNS) {HOST.CONN}

Acknowledge multiple items

Monitor->Problems apply filters, select all, mass update

No permissions to referred object or it does not exist!

Graph no longer exists. Probably items no longer discovered

Cannot add host

??

SNMP

Cannot find host interface on «xxxhost» for item key foo

Might mean you’re trying to import an SNMP template before configuring SNMP for the host

No SNMP data

snmp_parse_oid(): cannot parse OID «IF-MIB::ifSpeed.3

Agent side ping check

UserParameter=pingtime[*],fping -e $1|sed 's/^.*(([0-9].*) ms).*$/1/g'
UserParameter=pingalive[*],fping $1|grep -q alive;echo $?

LLD/Discovery

Discover: value must be a JSON object

Could mean you need to escape slashes, check output with zabbix_get

Cannot create item: item with the same key

make sure the key containts «{#MACRONAME}»

Discovery data example

Output of a discovery script should look like:

{"data":[
  {"{#VAR1}":"value11","#{VAR2":"value12"},
  {"{#VAR1}":"value21","#{VAR2":"value22"}
]}

IPMI

IPMI Monitoring account for zabbix

https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool

ipmitool user set name 3 monitor
ipmitool user set password 3
ipmitool channel setaccess 1 3 link=on ipmi=on callin=on privilege=2
ipmitool user enable 3

cannot connect to IPMI host: [22] Operation canceled

Usually temporary because of broken ipmi lib, ignore it

cannot connect to IPMI host: [16777411] Unknown error 16777411

classic, probably authentication problem

cannot connect to IPMI host: [22] Invalid argument

zabbix_sender

processed: 0; failed: 1

Possible causes:

  • incorrect hostname
  • incorrect item key
  • item not in the server configuration cache yet
  • Allowed hosts in trapper item
  • phase of moon
  • aliens

Testing zabbix_sender

zabbix_sender stuff

Filters

The regular expressions referred to in discovery are found under Administration->General, and then «Regular expressions» in the dropdown at top right of the page

cannot connect to IPMI host: [125] Operation canceled

possibly authentication method issue

Calculated items

See Calculated items explained

Cannot create item: Invalid first parameter

Cannot create item, error in formula

Problably a calculated item, try doublequoting the item key:

last("foo[bar]")

Invalid parameter «/1/params»

Maybe forgot to use last()?
You might need to doublequote your items, or prepend with double slashes

Reset trigger/alert

For example when you changed the settings
Just disable, wait a bit and enable again.

Install recent zabbix on CentOS/RHEL

rpm -ivh https://repo.zabbix.com/zabbix/3.4/rhel/7/x86_64/zabbix-release-3.4-2.el7.noarch.rpm
yum install zabbix-agent

Backing up tables

https://www.zabbix.org/wiki/Docs/howto/mysql_backup_script

cannot send list of active checks

If in agent log: most likely ServerActive is defined in agent config, while not used at all

It is also possible agent is sending some active check to server while host is monitored via proxy.

active check configuration update started to fail

??

Latest 20 issues

DEFAULT_LATEST_ISSUES_CNT in/usr/share/zabbix/include/defines.inc.php

Zabbix unreachable poller processes more than 75% busy

Increase StartPollersUnreachable

Zabbix poller processes more than 75% busy

another mystery

More than 100 items having missing data for more than 10 minutes

Could be high load. Also check Administration->Queue

Zabbix escalator processes more than 75% busy

probably high system load overall

Check agent

zabbix_get -s my.host.com -k agent.version

ZBX_NOTSUPPORTED

Could be anything, enable logging on agent. It could be version mismatch. Check

zabbix_get -s yourhost -k agent.version

If that works, you’re calling for an undefined or unsupported key.

Incorrect trigger expression. Host «xx» does not exist or you have no access to this host.

Means there’s no related item.

zabbix_get returns nothing

best look at log on agent side

run playbook on single host

ansible_playbook -l somehost somplay.yml

Category:Monitoring

Zabbix server is not running: the information displayed may not be current

Might be selinux: http://sysads.co.uk/2013/11/zabbix-server-running-alert/

Monitoring vmware

vmware.hv.cpu.usage[{$URL},{HOST.HOST}]» became not supported: Couldn’t resolve host name

Set macro {$URL} to https://your.ip/sdk/ (shouldn't discovery figure that out from {$HOST} ?
      

Couldn’t resolve host name

Sometimes it’s a matter of waiting a few hours

vmware events collector returned empty result

???

No «vmware collector» processes started.

Check StartVMwareCollectors on server or proxy

unsupported item key

This might mean it’s expecting a value from the script you’re calling.

echo 1

became not supported: Not supported by Zabbix Agent

probably output by userparameter/script

ansible or API not showing host groups

Permissions!! See Administration->User Groups

failed to update local proxy configuration copy: invalid field name «items.lastlogsize»

check everything  :)

Received value [11] is not suitable for value type [Numeric (unsigned)] and data type [Decimal]

This probably means the agent returned 1n1

database is down: retrying in 10 seconds

try upping max_connections

[Incorrect key file for table ‘items’; try to repair it

Could be something /tmp related

another network error, wait for 8 seconds

UnreachableDelay=8

failed: first network error

Setting Timeout in server configuration

also Timeout in agents?

no active checks on server

  • Hostname in agent config (-kagent.hostname) must match name on server
  • simple no connection possible? firewall?

???

show cpu utilization

Monitoring->host->graphs

fuzzytime on command line

TS=lotsofseconds
  1. output in hours
echo $(( ($(date +%s) - $TS) / 3600 ))

duplicate entry adding user/group

Check table ‘ids’

В этой публикации я расскажу о том, как осуществляется установка агента Zabbix на Linux. Это очень не сложная процедура. Особенно в базовой конфигурации. Все что нужно – это установить исполняемые файлы агента и изменить одну строчку в файле конфигурации. В редких случаях необходимо изменить пару строк в файле конфигурации.

Но обо все по порядку. Начнем с описания окружения.

Описание окружения

Я буду использовать Zabbix сервер версии Zabbix 6.2.7, который установлен на сервере Ubuntu 22.04.

В качестве подопытного сервера я опять же буду использовать Ubuntu Server 22.04.

Версия агента Zabbix также 6.2.7.

Предварительные требования

Какие-то особых предварительных требований нет. Нужно только, чтобы был открыт порт TCP/10050, который Zabbix сервер использует для получения данных от Zabbix агента.

Если вы используете дистрибутив Ubuntu Server, и то там брандмауэр выключен по умолчанию и дополнительных действий не требуется.

Если вы используете какой-то другой дистрибутив или включили брандмауэр, то убедитесь, что порт TCP/10050 добавлен в исключения брандмауэра.

Установку Zabbix агента на сервере Ubuntu можно выполнить вот такой простой командой:

sudo apt install zabbix-agent

Сразу после установки достаточно скорректировать всего одну строчку в файле конфигурации агента, чтобы сервер Zabbix смог собирать данные с агента. Это строка с указанием адреса сервера Zabbix. Поскольку у меня сервер один, то я укажу только его:

Server=10.10.10.71

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

Перезапустим службу агента Zabbix:

sudo systemctl restart zabbix-agent.service

Добавление нового хоста на сервере Zabbix

После того, как мы установили агент и скорректировали его конфигурационный файл можно приступить к последнему шагу – добавление хоста в панели управления сервером Zabbix:

1. Переходим в веб панель администрирования сервера Zabbix.

2. Переходим в раздел “Configuration” – “Hosts”. Нажимаем кнопку “Create host”.

3. Указываем произвольное название хоста, группа хоста и его IP-адрес. Посрт оставляет стандартный – 10050. В качестве шаблона я укажу “Linux by Zabbix agent”.

4. Нажимает кнопку “Add”.

Если все настройки были выполнены корректно, то перейдя в раздел “Monitoring” – “Latest data” вы должны увидеть данные, которые сервер Zabbix запрашивает с агента:

Также вы должны увидеть соответствующую пиктограмму в разделе конфигурации добавления хоста:

Куда смотреть, если что-то пошло не так

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

Журналы на стороне агента Zabbix

На стороне агента журналы расположены вот в этом файле:

less /var/log/zabbix-agent/zabbix_agentd.log

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

3155:20230208:145205.275 failed to accept an incoming connection: connection from "10.10.10.71" rejected, allowed hosts: "10.10.10.75"
3157:20230208:145220.219 failed to accept an incoming connection: connection from "10.10.10.71" rejected, allowed hosts: "10.10.10.75"

Отслеживать события в журнале в режиме постоянного обновления можно вот этой командой:

tail -f /var/log/zabbix-agent/zabbix_agentd.log

Журналы на стороне сервера Zabbix

Несомненно, на стороне сервера есть свой отдельный журнал. В нем тоже можно попробовать найти ответ на вопрос “почему не удается подключиться в zabbix агенту”. Журнал расположен вот в этом файле:

less /var/log/zabbix/zabbix_server.log

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

1289:20230208:145205.255 Zabbix agent item "system.swap.size[,pfree]" on host "ubnt" failed: first network error, wait for 15 seconds
1292:20230208:145220.199 Zabbix agent item "system.cpu.util[,nice]" on host "ubnt" failed: another network error, wait for 15 seconds
1292:20230208:145235.211 Zabbix agent item "system.swap.size[,free]" on host "ubnt" failed: another network error, wait for 15 seconds
1292:20230208:145250.228 temporarily disabling Zabbix agent checks on host "ubnt": interface unavailable

Отслеживать события в журнале в режиме постоянного обновления можно вот этой командой:

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

Понравилась статья? Поделить с друзьями:

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

  • Zabbix error ssh2 library not found
  • Zabbix error in query
  • Zabbix error connecting to database too many connections
  • Zabbix error connecting to database mysql
  • Zabbix discoverer processes more than 75 busy как исправить

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии