Quelles métriques de votre déploiement PostgreSQL devriez-vous surveiller ? Cette série d'articles de blog vise à fournir un ensemble minimal et initial d'actions de surveillance essentielles que vous devez mettre en œuvre pour assurer la santé et la stabilité de vos serveurs Postgres.
La première partie couvre les paramètres au niveau du cluster.
Partie 1 :Niveau cluster
Dans le jargon Postgres, un cluster est un ensemble de bases de données gérées par une seule instance de serveur Postgres. Des fonctionnalités telles que la réplication et l'archivage WAL fonctionnent au niveau du cluster.
1. Plage d'ID de transaction
Du point de vue d'un client normal, les fichiers de données d'un cluster PostgreSQL sembleront contenir l'instantané des données telles que modifiées par la dernière transaction validée. Cependant, en raison de l'architecture MVCC de Postgres, les fichiers physiques contiennent non seulement les données de la transaction la plus récente, mais aussi celles d'une série de transactions se terminant par la dernière. (Passage à l'aspirateur régulier supprime les données des anciennes transactions.)
Chaque transaction possède un identifiant entier unique de 32 bits, appelé ID de transaction. . Pour diverses raisons, la différence entre le premier et le dernier ID de transaction doit être inférieure à 2, soit environ 2 milliards. Maintenir la plage bien en dessous de cette limite est un must – lisez cette histoire vraie de ce qui se passe autrement.
Action :surveiller en permanence la plage d'ID de transaction, alerter si la valeur dépasse un seuil défini.
Comment :
-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
FROM pg_control_checkpoint();
-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
FROM pg_database;2. Nombre de back-ends
Chaque backend représente soit un client connecté au serveur, soit un processus systembackend (comme un aspirateur automatique, un écrivain en arrière-plan, etc.). Chaque backend est également un processus du système d'exploitation qui consomme des ressources du système d'exploitation telles que la mémoire, les descripteurs de fichiers ouverts, etc. P>
Action :surveillez le nombre maximal de backends chaque jour/semaine, étudiez les tendances à la hausse.
Comment :
-- returns the count of currently running backends
SELECT count(*)
FROM pg_stat_activity;3. Emplacements de réplication inactifs
Les slots de réplication sont marqués comme « inactifs » lorsque le client de réplication connecté au slot se déconnecte. Les slots de réplication inactifs entraînent la conservation des fichiers WAL, car ils devront être envoyés au client lorsqu'il se reconnectera et que les slots deviendront actifs. En effet, la première chose à vérifier si votre nombre de fichiers WAL ne diminue pas est de voir si vous avez des slots de réplication inactifs.
Souvent, les emplacements de réplication inactifs sont le résultat d'un client de sauvegarde qui a été supprimé, d'un esclave qui a été retiré, de promotions, de basculements, etc.
Action :vérifier en permanence les emplacements de réplication inactifs, alerter le cas échéant.
Comment :
-- returns the count of inactive replication slots
SELECT count(*)
FROM pg_replication_slots
WHERE NOT active;4. Backends en attente de verrous
Les instructions SQL peuvent explicitement ou implicitement provoquer l'attente d'autres instructions SQL. rencontrer le verrou devra attendre que la première instruction renonce au verrou, avant de poursuivre son exécution.
Cela peut se manifester par des performances d'application lentes lors des exécutions de rapports hebdomadaires, des transactions/pages Web expirées, etc.
Bien qu'une certaine quantité de verrouillage ne puisse être évitée, une tendance croissante des backends à attendre des verrous nécessite généralement une restructuration des requêtes ou de la logique d'application.
Action :surveillez le nombre maximal de backends en attente de verrouillage chaque jour/semaine, étudiez les tendances à la hausse.
Comment :
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE wait_event = 'Lock';5. Backends inactifs dans la transaction
Les transactions de longue durée ne sont pas très agréables à avoir dans le monde PostgreSQL. Elles peuvent entraîner l'accumulation de fichiers WAL, empêcher le vide automatique et le vide manuel, et utiliser des ressources. On ne peut pas faire grand-chose à propos des transactions authentiques qui prennent beaucoup de temps à se terminer, mais il existe des cas comme des applications/scripts qui se comportent mal et le client psql occasionnel qui démarre des transactions mais ne les ferme pas. Les backends qui desservent ces clients apparaissent comme "inactifs dans la transaction".
Les backends inactifs dans les transactions doivent être détectés et arrêtés avant qu'ils ne commencent à affecter la stabilité du système.
Action :surveillez en permanence le nombre de backends inactifs dans la transaction, vérifiez s'il y en a.
Comment :
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE state = 'idle in transaction';6. Délai de réplication pour les connexions actives
Lorsqu'il y a des clients de réplication en continu actifs (comme des serveurs de secours) ou des clients de réplication logique actifs, Postgres exécute un backend système appelé unexpéditeur WAL pour chaque client actif (connecté). L'expéditeur WAL est responsable de l'envoi des données d'enregistrement WAL dont le client a besoin.
Les clients de réplication essaient généralement de suivre autant qu'ils le peuvent le primaire. Parfois, cependant, le taux de génération de WAL du côté primaire peut devenir supérieur au taux auquel le client est capable de les consommer. Cela entraîne un décalage de réplication pour chaque connexion de réplication.
PostgreSQL fournit un mécanisme pour interroger le décalage d'écriture (nombre d'octets envoyés mais non écrits sur le disque du client), le décalage de vidage (nombre d'octets écrits mais non vidés sur le disque du client) et le retard de relecture (nombre d'octets vidés mais non relus sur le disque du client). fichiers de base de données) pour chaque expéditeur WAL actif.
Action :surveiller en permanence les délais de réplication pour les connexions actives, alerter si les valeurs dépassent les seuils définis.
Comment :
-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
flush_lsn - write_lsn AS flush_lag,
replay_lsn - flush_lsn AS replay_lag
FROM pg_stat_replication;7. Délai de réplication pour les slots de réplication
Non seulement les clients de réplication peuvent être retardés, mais ils peuvent également disparaître complètement en raison de plantages, de changements de topologie ou d'erreurs humaines. Cela peut également être dû à la conception, où les clients ne sont pas toujours en ligne.
Si le client est soutenu par un slot de réplication, alors tous les fichiers WAL nécessaires pour que le client reprenne à partir du point où il s'était arrêté sont conservés par PostgreSQL. Les fichiers WAL seront conservés indéfiniment - il n'y a aucun moyen de fixer une limite. Lorsque le client se reconnecte, toutes les données conservées doivent d'abord être transmises au client, ce qui peut impliquer beaucoup de trafic disque et réseau sur le serveur principal. Pour ces raisons, vous devriez également surveiller le décalage au niveau des emplacements.
(Remarque :le processus d'envoi WAL ne s'exécute que lorsqu'un client est connecté et il se termine lorsque le client se déconnecte. La méthode d'envoi WAL pour mesurer la distance derrière un client ne fonctionne pas lorsqu'un client est déconnecté.)
Action :surveiller en permanence les retards de réplication pour les emplacements de réplication logiques, alerter si les valeurs dépassent un seuil défini.
Comment :
-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
FROM pg_replication_slots;8. Nombre de fichiers WAL
La gestion des fichiers WAL peut être une tâche exaspérante, surtout si vous avez des clients d'archivage WAL ou de réplication en continu. Le nombre de fichiers WAL peut commencer à augmenter sans raison apparente, le processus d'archivage WAL peut ne pas suivre le rythme de génération des WAL et la taille totale des fichiers WAL peut atteindre des téraoctets.
Au minimum, vous devez surveiller le nombre de fichiers WAL présents dans votre répertoire de base de données et vous assurer que le nombre semble raisonnable pour votre déploiement.
Action :surveiller en permanence le nombre de fichiers WAL, alerter si la valeur dépasse un seuil défini.
Comment :
-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
FROM pg_ls_waldir();
-- same, for v9.x
SELECT count(*)
FROM pg_ls_dir('pg_xlog')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';
-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'9. Nombre de fichiers WAL prêts à être archivés
Lorsque l'archivage WAL est activé, PostgreSQL invoque un script utilisateur chaque fois qu'un nouveau fichier WAL est généré. Le script est censé « archiver » le fichier WAL unique pour lequel il a été invoqué (il le copie généralement sur un autre serveur ou un compartiment S3). Si le script prend trop de temps pour faire son travail, ou s'il échoue, l'ensemble de fichiers WAL à être archivé s'accumule.
Action :surveiller en permanence le nombre de fichiers WAL prêts à être archivés, alerter si la valeur dépasse un seuil défini.
Comment :
-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
FROM pg_ls_archive_statusdir()
WHERE name ~ '^[0-9A-F]{24}.ready$';
-- same, for v10+
SELECT count(*)
FROM pg_ls_dir('pg_wal/archive_status')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';
-- same, for v9.x
SELECT count(*)
FROM pg_ls_dir('pg_xlog/archive_status')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';
-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .readyCollecte de ces métriques
Les sections ci-dessus fournissent des instructions SQL pour extraire les métriques nécessaires d'un serveur Postgres en cours d'exécution. Si vous préférez ne pas écrire les scripts vous-même, consultez l'outil open source pgmetrics. Il peut collecter les métriques ci-dessus, et plus encore, et les rapporter aux formats texte et JSON.
Vous pouvez envoyer directement les rapports pgmetrics à notre offre commerciale, pgDash, qui stocke et traite ces rapports pour afficher des graphiques et effectuer des alertes.
Suivant
D'autres parties de cette série couvriront les métriques au niveau de la base de données, au niveau de la table, au niveau de l'index et au niveau du système. Restez à l'écoute !
