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.
Ceci est la deuxième partie d'une série de blogs et couvre les paramètres au niveau de la base de données. Le premier couvrait les paramètres au niveau du cluster.
Partie 2 :Niveau de la base de données
Dans cette partie, nous examinons les métriques et les informations qui doivent être surveillées pour chaque base de données importante que vous utilisez.
La plupart des requêtes SQL répertoriées ci-dessous doivent être exécutées en étant connecté à la base de données en question.
1. Clients connectés
Les clients connectés occupent les ressources du système d'exploitation et du système. Postgres a une architecture processus par client, et trop de clients peuvent ralentir les temps de réponse aux requêtes pour tout le monde. Envisagez d'utiliser PgBouncer orpgpool pour réduire le nombre de connexions que le serveur Postgres devra gérer.
Gardez un œil sur les modifications de la ligne de base après les mises à jour de l'application et les pics de connexion en raison de l'augmentation du trafic.
Action :surveiller le nombre maximum de clients connectés chaque jour/semaine, étudier les changements de tendance.
Comment :
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Taille
La taille réelle du disque utilisé par la base de données doit être surveillée. Dans la plupart des cas, la taille de la base de données ne cesse de croître, c'est donc le taux de croissance qui est le plus intéressant. Encore une fois, méfiez-vous du taux de croissance accru après la sortie de nouvelles applications.
Action :Surveiller la croissance de la taille de la base de données au cours de chaque semaine/mois, étudier les tendances, réapprovisionner.
Comment :
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Gonflement des tables sur toutes les tables
En raison de l'architecture MVCC de Postgres, les anciennes versions des lignes se trouvent dans les fichiers de données physiques pour chaque table et sont appelées bloat . L'opération pour éliminer les versions de lignes obsolètes s'appelle vacuum . Postgres exécute un processus d'arrière-plan appelé autovacuum , qui récupère les tables candidates (basées sur des paramètres configurables) et les aspire pour vous.
Bloat ralentit les opérations de table et gaspille de l'espace disque, et peut s'enfuir même avec l'autovacuum. La surveillance du gonflement, sous la forme d'un nombre absolu d'octets ainsi que d'un pourcentage (des données mortes par rapport aux données totales), est requise. Cela peut être fait au niveau de la base de données sous la forme d'un total sur toutes les tables, avec la possibilité d'explorer les "tables les plus gonflées".
Action :surveillez en permanence le gonflement total en octets et en pourcentage, alertez si les valeurs dépassent un seuil défini.
Comment :
Utilisez check_postgres orpgmetrics pour obtenir des estimations de gonflement. Voir le wiki pour plus d'informations.
4. Index gonflé sur tous les index
Les index gonflés peuvent ralentir les insertions et réduire les performances de recherche. Surveillez le gonflement des index à la fois en valeur absolue (nombre d'octets) et en pourcentage. Les index devront être reconstruits lorsqu'ils seront trop gonflés.
Action :surveillez en permanence le gonflement total en octets et en pourcentage, alertez si les valeurs dépassent un seuil défini.
Comment :
Utilisez check_postgres orpgmetrics pour obtenir des estimations de gonflement. Voir le wiki pour plus d'informations.
5. Transactions de longue durée
Les transactions ouvertes trop longtemps ne sont pas une bonne nouvelle pour PostgreSQL. Les transactions de longue durée peuvent entraîner la rétention des fichiers WAL, peuvent s'accrocher aux verrous et empêcher le vide. Les applications doivent être conçues pour maintenir la durée des transactions aussi courte que possible.
Un backend exécutant une transaction de longue durée peut être tué avec pg_cancel_backend() et pg_terminate_backend() fonctions.
Action :surveiller en permanence le nombre de transactions qui ont été exécutées pendant plus d'une durée définie, alerter si les valeurs dépassent un seuil défini.
Comment :
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. Blocages
Dans PostgreSQL, les backends placent implicitement des verrous sur les lignes et les tables lorsqu'ils exécutent des requêtes qui modifient les lignes. Les requêtes peuvent également placer des verrous explicites (comme SELECT .. FOR UPDATE ). Tout comme dans la programmation multithread, deux transactions plaçant des verrous, implicitement ou explicitement, dans un ordre opposé peuvent entraîner un blocage.
PostgreSQL détectera les interblocages et annulera l'une des transactions impliquées (tous les verrous détenus par une transaction sont libérés lorsqu'elle est validée ou annulée). Les détails seront enregistrés dans la destination de journalisation PostgreSQL.
Les applications doivent être conçues pour éviter la possibilité d'un blocage. Ils peuvent également choisir de réessayer une transaction en cas de blocage.
Action :surveillez le nombre de blocages chaque jour/semaine, reconcevez l'application pour réduire le nombre, examinez les modifications.
Comment :
Les occurrences de blocages, ainsi que des informations supplémentaires, sont consignées dans le fichier journal PostgreSQL. Utilisez pgmetrics, pgbadger ou d'autres outils de traitement de journaux spécifiques à PostgreSQL pour extraire ces informations.
7. Aspirateur le plus ancien
L'aspiration régulière des tables, soit avec autovacuum, soit avec des tâches planifiées, soit manuellement est indispensable pour maintenir la rapidité des opérations sur les tables. Les aspirateurs peuvent échouer pour diverses raisons, y compris les transactions de longue durée, les emplacements de réplication inactifs, etc.
Étant donné que le nettoyage régulier des tables est très important dans le monde Postgres, il est préférable de vérifier régulièrement si toutes les tables ont été nettoyées au moins une fois dans un intervalle défini.
Et bien qu'elles aient tendance à être hors de vue et hors de l'esprit, les tables du catalogue système doivent également être aspirées.
Action :vérifier en permanence si une table n'a pas été aspirée au cours du dernier nombre d'heures/jours défini, alerter le cas échéant.
Comment :
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Analyse la plus ancienne
Afin d'exécuter vos requêtes SELECT, le planificateur de requêtes prépare unplan d'exécution qui décrit quels index et tables doivent être lus, et comment. Ces informations statistiques sur les données d'un tableau sont collectées et conservées par analyze opérations. Les tables avec des statistiques à jour entraînent des requêtes plus rapides et moins d'E/S.
Le processus d'autovacuum mentionné ci-dessus exécute généralement également ANALYZE sur la table, il passe l'aspirateur pour maintenir ces informations à jour. Cependant, cela seul peut ne pas fournir une couverture d'analyse suffisante pour vos tables. Vous voudrez compléter en exécutant ANALYZE en tant que tâches planifiées ou après d'importantes mutations de table.
Dans l'intérêt des performances des requêtes, il est préférable de vérifier en permanence si toutes les tables ont été analysées au moins une fois dans un intervalle défini.
Action :vérifier en permanence si une table n'a pas été analysée au cours du dernier nombre d'heures/jours défini, alerter le cas échéant.
Comment :
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;Collecte 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
La prochaine partie de cette série couvrira les métriques au niveau de la table, de l'index et du système. Restez à l'écoute !
