La surveillance de la réplication PostgreSQL avec Nagios et check_postgres montre un timeout intermittent

J'ai une configuration principale et chaude avec PostgreSQL 9.3 et je tente de surveiller l'état de réplication en mode veille à l'aide de l'outil check_postgres et de l'action "hot_standby_delay". Cela semble fonctionner en calculant la différence d'octets entre la position xlog sur le maître et la veille.

Dans de nombreux exemples en ligne, j'ai vu des seuils d'avertissement et critiques pour cela dans la gamme <1 Mo. La command exacte que nous utilisons dans Nagios est:

/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

Ce qui devrait définir un avertissement à environ 1 Mo et une panne à environ 5 Mo. Cependant, sur nos servers, nous le voyons régulièrement jusqu'à un niveau élevé, comme ceci:

 [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 

Suivi de la prochaine vérification de Nagios avec:

 [1417719893] SERVICE ALERT: host;PostgreSQL: Replication Delay;OK;SOFT;4;POSTGRES_HOT_STANDBY_DELAY OK: DB "monitoring" (host:host.example.com) 0 

Donc, dans le sens général, il semble que la réplication fonctionne (et même si une mise à jour de données sur le maître voit des résultats immédiats en mode veille).

Malheureusement, ce scénario rend la surveillance inutile car elle triggers un faux positif plusieurs fois par jour. À partir de ce que j'ai trouvé entre la documentation et d'autres exemples d'utilisation, ce résultat n'est pas typique, et la plupart des personnes sont en mesure de définir un seuil de 1 Mo ou less et de ne voir que des erreurs quand il y a des erreurs.

Est-ce que quelqu'un a une idée de ce que je pourrais essayer avec la configuration pour remédier à cela? Sur cette installation particulière, nous n'avons changé que quelques parameters, et de ceux-là, seuls les wal_keep_segments semblent même liés à distance (et nous avons configuré 128).

Le maître et le mode veille sont hébergés dans EC2 dans la même zone de disponibilité et il ne semble pas y avoir de timeout de communication entre eux. Il s'agit également d'une database à très faible trafic, de sorte que je suis incertain quant à la façon dont le xlog delta pourrait être très loin pour commencer, à less que je me manque d'un fait très critique.

Une vérification qui returnne SOFT CRITICAL ne triggers pas de notifications car elle n'a pas atteint le seuil max_check_attempts . Ce n'est pas un faux positif; Nagios fonctionne comme prévu. C'est assez normal (pour de nombreux services, pas seulement pour votre cas). C'est exactement pourquoi existe max_check_attempts.

Dans votre cas, il revient à la normale dans les 3 minutes suivant le résultat de la vérification initiale non correcte. Pour certains services, ce time de synchronisation est acceptable, mais ce n'est peut-être pas pour votre cas d'utilisation. Je ne sais pas assez sur la réplication Postgres pour dire définitivement si cela révèle un problème sous-jacent ou non.