Cбор диагностики Glaber

Сервер

1.Падения сервера

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

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

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

Эту информацию, а также информацию о содержании регистров и указателей нужно приложить в issue / оптправить разработчикам

2.Проблемы с логикой сбора метрик, поллингом, работы триггеров

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

Для этого в интерфейс Администрирование—>Отладка ( Administartion->Debug ) нужно указать идентификатор проблемной метрики в поле Debug Item или триггера в поле Debug Tigger. Указывать нужно ID (идентификатор) объекта, который можно скопировать в строке URL браузера при реадктировании метрики или триггера.

Перезапуска сервера не требуется, сервер сразу начнет писать отладку только указанной метрики в лог файл (типично это /var/log/zabbix/zabbix_server.log)

Нужно собрать журнал за период времени равный 3-5 интервалам сбора метрики. Аналогичным образом можно сделать логгирование функционала триггера. В issue или разработчикам предоставить отладочную информацию из лога:

cat /var/log/zabbix/zabbix_server.log | grep debug

При перезагрузке сервера отладочная инфомрмаяция перестанет собироваться. Если требуется информация с момента старта сервера, то можно включить отладку для метрики или триггера на уровне конфигурации сервера в zabbix_server.conf файле:

DebugItem=234525
DebugTrigger=3456453

Функционал выборочной отладки включается путем включение модуля Сustom Debug. https://docs.glaber.io/extending/

3. Веб интерфейс и API:

При возникновении ошибок информация о точке и стеке вызова есть в error журнале веб сервера. Эту информацию необходимо приложить в issue. Также можно включить режим отладки в UI и при нажатии на кнопку Отладка (Debug) получить журнал работы с API и статистику SQL запросов.

4. Дополнительные источники для отладочной инфрмации

Сервер периодически делает дамп Кеша значений. Кеш значений сохраняется в jsonl формате со сжатием .gz.

C помощью утилит zcat и grep по идентификатору метрики можно выбрать актуальные но момент сохранения кеша значений метрики по идентификатору.

5. Диагностика проблем с низкой производительностью сервера

Запустить команду strace:

timeout strace  -w -c p <номер пид нужного процесса>

такая соберет статистику, сколько реального времени проводит тот или иной процесс в системных вызовах

timeout strace  -c p <номер пид нужного процесса>

Аналогично, но - сколько системного времени.

Также полезно предоставить вывод команды

top -c