Comments 7
В основе сервисного скрипта, который выполняется по cron положена очень простая конструкция:
агент Zabbix не выполняет парсинг лога СУБД
cat $log_file | grep -E 'ERROR|ОШИБКА' | wc -l > /tmp/error.count
То есть парсинг, но по крону и в файл.
Не то чтобы такая конструкция не работала, причем настолько, что кто-то минусит сходу, не поясняя что не так, так что плюсану, но.
Нет чего то по типу
https://github.com/prometheus-community/postgres_exporter/
или
https://www.perfectscale.io/blog/monitoring-postgresql-with-prometheus-operator ?
А какой величины может быть лог файл? Если по несколько/много гиг, то парсить всё каждый раз по крону, да еще отдельно для каждой ошибки - ну просто жалко ресурсов.
При детекте фиталити мы полочим лог с ошибкой. И даже после решения проблемы в логе она останется и будет постоянно выскакивать. Или надо обрезать логи после каждого парсинга?
Zabbix из коробки умеет парсить логи. Зачем писать обертку с кроном про который можно забыть?
Причем из коробки лог будет читаться с последнего места чтения и мы будем видеть картину временную как есть. То есть поставили сбор данных раз в минуту, то количество ошибок мы увидим за минуту.
Один из методов мониторинга и анализа ошибок СУБД