§ Zabbix troubleshoot

У меня все работает, а Zabbix пишет что нет!!!

При работе с Zabbix иногда приходится сталкиваться с такими проблемами, которые можно описать так "заббикс пишет что на сервере Х проблема, хотя я захожу туда и там все работает!". Особенно на начальном этапе знакомства с как с системой мониторинга, так и при реализации какого то нового мониторинга.
Для решения таких проблем у меня выработался вполне четкий алгоритм поиска проблемы. Тут стоит отметить, что этот алгоритм не является универсальным решением всех проблем возникающих в Zabbix, а решает только определенную часть проблем, которые можно описать заголовком статьи. Сам алгоритм умещается в несколько шагов:
Определение имени триггера. Собственно это то отчего нужно отталкиваться. 
Определение ключа который соответствует триггеру. В настройках хоста нужно найти этот триггер и определить имя ключа который вызвал сработку.
Проверка ключа с помощью zabbix_get. Нужно выяснить какое значение отдает агент и с правильного ли сервера забирается значение.
Проверка правильности UserParameter который назначен этому ключу. На сервере где запущен агент, нужно выяснить нет ли ошибки в конфигурации агента, относительно проблемного ключа.
Попытка запуска скрипта или тех действий которые определены в UserParameter. Нужно запустить скрипт или описанные в конфигурации действия, чтобы понять правильно ли работает скрипт.
Запуск тех же действий из под аккаунта zabbix. Нужно выяснить имеются ли права у агента zabbix для выполнения действий определенных в ключе.
Разбор проблемы в объекте наблюдения. Как правило на этом этапе поиск проблемы заканчивается, проблема становится более менее понятной и ее решение уже не затрагивает вмешательства в работу агента zabbix.

Опишу вполне конкретный случай поиска проблемы.
Один мой друг, только осваивающий Zabbix, обнаружил с утра, что на двух серверах из трех сломалась проверка MySQL, хотя сам сервис работал в штатном режиме. То есть видим типичное "заббикс пишет что на сервере Х проблема, хотя я захожу туда и там все работает!"
Смотрим что за триггер, триггер называется "Mysql: is dead on mysql.sw.dev". 
Дальше заходим в настройки хоста mysql.sw.dev и ищем триггер с именем "Mysql: is dead on {HOSTNAME}".
Нашли, смотрим его описание и выясняем что этому триггеру соответствует ключ mysql[alive]. При проверке, сервер отправляет агенту запрос в котором указывает этот ключ. Агент выполняет какие-то действия и по итогу отправляет серверу ответ. В нашем случае агент вернул значение 0 и сервер забил тревогу.
Идем в консоль сервера и выполняем запрос к агенту с именем ключа 
# zabbix_get -s mysql.sw.dev -k mysql[alive]
0
Действительно отдается значение при котором должен сработать триггер.
Заходим в консоль сервера mysql.sw.dev. Здесь нам нужно посмотреть что соответствует UserParameter'у mysql[alive]. За обработку этого параметра отвечает скрипт /etc/zabbix/scripts/mysql_stats.sh
Теперь нужно проверить что он исполняемый и то что он отрабатывает как положено при передаче ему аргументов.
Скрипт должен иметь права запуска из под аккаунта zabbix (стандартный аккаунт для агента). Самый лучший вариант для скриптов zabbix'а это zabbix:zabbix битовая маска 750
# chown zabbix: /etc/zabbix/scripts/ -R
# chmod 750 /etc/zabbix/scripts/*
Скрипт оказался исполняемым и при запуске с аргументами возвращал правильное значение, при котором сервер не должен бить тревогу. Теперь этот скрипт нужно запустить от имени zabbix. По умолчанию у zabbix отключен нормальный шелл, поэтому его следует включить (например bash) и затем выполнить скрипт.
# usermod -s /bin/bash zabbix
# su - zabbix
$ /etc/zabbix/scripts/mysql_stats.sh alive admin password
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13)'
Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!
0
$ ls -l /var/lib/mysql/mysql.sock
ls: cannot access /var/lib/mysql/mysql.sock: Permission denied

Вот и ответ, для аккаунта zabbix нет возможности подключаться к сокету mysql.sock. 
Как оказалось позже, человек выполнил переинициализацию кластера через "mysql_install_db --user=mysql" что с его слов, привело к таким правам.
Таким образом правка прав доступа к сокету решила проблему.

Подведя итог всем действиям которые выполнялись в процессе поиска, можно составить краткий алгоритм поиска и решения проблемы.
-> определение имени триггера
 -> определение ключа соответствующего триггеру
  -> проверка ключа с помощью zabbix_get
   -> проверка правильности UserParameter который назначен этому ключу
    -> попытка запуска скрипта или тех действий которые определены в UserParameter
     -> запуск тех же действий из под аккаунта zabbix
      -> разбор проблемы в объекте наблюдения.

На главную "Virtualizing Linux"