Контроль репликации PostgreSQL с Nagios и check_postgres показывает неустойчивую задержку
У меня есть установка основного и горячего резервирования с PostgreSQL 9.3, и я пытаюсь контролировать состояние репликации на резервном устройстве с помощью check_postgres инструмент и "hot_standby_delay" действие. Это, кажется, работает путем вычисления различия в байтах между xlog позицией относительно ведущего устройства и резервным устройством.
В многочисленных примерах онлайн я видел предупреждение и критические пороги для этого в <диапазон 1 МБ. Точная команда, которую мы используем в Nagios:
/usr/local/bin/check_postgres.pl --action=hot_standby_delay --host=$HOSTNOTES$,$HOSTADDRESS$ --port=5432 --dbname=monitoring --dbuser=monitoring --dbpass=monitoring --warning=1000000 --critical=5000000
Который должен установить предупреждение на уровне примерно 1 МБ и отключение электричества на уровне примерно 5 МБ. Однако на наших серверах мы обычно видим, что он пронзает к высокому уровню, как это:
[1417719713] SERVICE ALERT: host;PostgreSQL: Replication Delay;CRITICAL;SOFT;1;POSTGRES_HOT_STANDBY_DELAY CRITICAL: DB "monitoring" (host:host.example.com) 121175880
[1417719773] SERVICE ALERT: host;PostgreSQL: Replication Delay;CRITICAL;SOFT;2;POSTGRES_HOT_STANDBY_DELAY CRITICAL: DB "monitoring" (host:host.example.com) 132780968
[1417719833] SERVICE ALERT: host;PostgreSQL: Replication Delay;CRITICAL;SOFT;3;POSTGRES_HOT_STANDBY_DELAY CRITICAL: DB "monitoring" (host:host.example.com) 21412936
Развитый следующий Nagios сверьтесь:
[1417719893] SERVICE ALERT: host;PostgreSQL: Replication Delay;OK;SOFT;4;POSTGRES_HOT_STANDBY_DELAY OK: DB "monitoring" (host:host.example.com) 0
Таким образом в общем смысле кажется, что репликация работает (и действительно, выполнение обновления данных на ведущем устройстве видит непосредственные результаты на резервном устройстве).
К сожалению, этот сценарий делает контроль бесполезным, так как он инициировал ложь, положительную много раз день. Из того, что я нашел между документацией и другими примерами использования этого, этот результат не типичен, и большинство людей может установить порог 1 МБ или меньше и только видеть ошибки, когда существуют на самом деле ошибки.
У кого-либо есть какая-либо идея того, что я мог попытаться конфигурацией исправить это? На этой конкретной установке мы изменили только несколько параметров, и тех, только wal_keep_segments кажется даже удаленно связанным (и у нас есть тот набор к 128).
И ведущее устройство и резервное устройство размещаются в EC2 в той же зоне доступности и там, кажется, не коммуникационные задержки между ними. Это - также база данных очень низкого трафика, таким образом, я не уверен относительно того, как xlog дельта могла быть то, что далеко для начала, если я не пропускаю некоторый очень критический факт.
Проверка, которая возвращает SOFT CRITICAL, не запускает уведомления, поскольку она не достигла порогового значения max_check_attempts . Это не ложное срабатывание; это Nagios, работающий так, как задумано. Это вполне нормально (для многих сервисов, а не только для вашего случая). Именно поэтому существует max_check_attempts.
В вашем случае он возвращается в нормальное состояние в течение 3 минут после первоначального результата проверки, который не соответствует норме. Для некоторых служб такое время рассинхронизации допустимо, но может не подходить для вашего варианта использования. Я недостаточно знаю о репликации Postgres, чтобы с уверенностью сказать, указывает ли она на основную проблему или нет.