Очень неприятная ситуация для DBA: «что-то происходит с СУБД, но что именно — нет информации». Первый и иногда достаточный способ избежать неопределенности — всегда иметь полную информацию о нештатных ситуациях в работе СУБД на текущий период и в истории. Для решения этой в общем то стандартной задачи и нужно мониторить и анализировать лог СУБД. PostgreSQL в данном случае не исключение.

К рассмотрению предлагается один из способов мониторинга ошибок СУБД PostgreSQL и получением итоговой информации, используя Zabbix. Данная статья не tutorial и не roadmap, скорее как эскиз для обмена мнениями с коллегами.

Мониторинг ошибок СУБД

Способ мониторинга СУБД очень простой — постоянный парсинг лога СУБД и оповещение о появлении ошибки.

В основе сервисного скрипта, который выполняется по cron — положена очень простая конструкция:

cat $log_file | grep -E 'FATAL|ВАЖНО|PANIC|ПАНИКА|ERROR|ОШИБКА' 

Данную конструкцию можно выполнять используя возможности агента Zabbix, но в этом случае есть несколько моментов:

1. Агент Zabbix должен иметь доступ на чтение к папке лога СУБД
2. Агент Zabbix имеет ограничения по timeout и в случае повышенной нагрузки на сервер и аварийной ситуации с инфраструктурой могут быть пробелы в мониторинга. А как раз в таких сценариях мониторинг ошибок особенно важен.

Поэтому используется несколько другой способ — агент Zabbix не выполняет парсинг лога СУБД, а всего лишь считывает значение метрики из файлов, которые формируются простым скриптом bash по расписанию cron:

# ERROR | ОШИБКА
cat $log_file | grep -E 'ERROR|ОШИБКА' | wc -l > /tmp/error.count

# FATAL | ВАЖНО
cat $log_file | grep -E 'FATAL|ВАЖНО' | wc -l > /tmp/fatal.count

# PANIC | ПАНИКА
cat $log_file | grep -E 'PANIC|ПАНИКА' | wc -l > /tmp/panic.count

В результате — не нужны никакие дополнительных настроек для работы агента Zabbix, да и накладные расходы на получение данных — минимальны.

Для более углубленного анализа, для некоторых кодов ошибок можно и нужно сформировать отдельные файлы:

#Класс 53 — Нехватка ресурсов
cat $log_file | grep -E 'FATAL|ВАЖНО|PANIC|ПАНИКА|ERROR|ОШИБКА' | grep -E ' 53000\|| 53100\|| 53200\|| 53400\|| 53500\|' | wc -l > /tmp/error53.count

# Класс 58 — Ошибка системы (ошибка, внешняя по отношению к PostgreSQL)
cat $log_file | grep -E 'FATAL|ВАЖНО|PANIC|ПАНИКА|ERROR|ОШИБКА' | grep -E ' 58000\|| 58030\|| 58P01\|| 58P02\|' | wc -l > /tmp/error58.count

# Класс<h3></h3> XX — Внутренняя ошибка
cat $log_file | grep -E 'FATAL|ВАЖНО|PANIC|ПАНИКА|ERROR|ОШИБКА' | grep -E ' XX000\|| XX001\|| XX002\|' | wc -l > /tmp/errorXX.count

Для оперативного реагирования на ошибки — можно и нужно настроить стандартное оповещение Zabbix:

Problem started at HH:MI:SS on YYYY.DD.MM
Problem name: ERRORXX
Host: ХХХ
...

Метрики Zabbix

В результате добавления метрик Zabbix получается вполне доступная для оперативного и исторического анализа картина:

Итог

Развитием идеи, является парсинг и анализ части(или всего) лога СУБД для получения сводного отчета по кодам ошибок:

Класс 25 — Неверное состояние транзакции:48
Класс 42 — Ошибка синтаксиса или нарушение правила доступа:453
Класс 57 — Вмешательство оператора:186
...