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 troisième et dernière partie d'une série de blogs et couvre les métriques au niveau des tables, des index et du système. Le premier couvrait les métriques au niveau du cluster et le second couvrait les métriques au niveau de la base de données.
Niveau tableau
En règle générale, les données d'une base de données suivent la règle 80-20. 20 % des tables contiennent la plupart des données et sont les plus consultées ou mutées. La configuration d'une surveillance supplémentaire uniquement pour ces tables peut fournir des informations importantes mais peu volumineuses.
Voici quelques statistiques au niveau du tableau qui valent la peine d'être examinées :
1. Taille du tableau
La taille réelle du disque utilisé par la table doit être surveillée. Dans la plupart des cas, le tableau ne cesse de croître, c'est donc le taux de croissance qui est le plus intéressant.
Il arrive souvent que le taux de croissance change après le déploiement d'une nouvelle version de l'application, ou un changement de base dans les modèles de trafic/charge/entrée de l'application elle-même. De tels changements doivent être étudiés, au moins pour vérifier que le nouveau débit est supporté par le matériel provisionné.
Action :surveillez l'augmentation de la taille du tableau au cours de chaque semaine/mois, examinez les changements brusques.
Comment :
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Ballonnement de table
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.
Cette métrique peut être surveillée soit au niveau de la table individuelle, soit sous forme d'agrégat sur les tables sélectionnées, soit au niveau de la base de données.
Action :surveillez en permanence le gonflement de la table en octets et en pourcentage, alertez si les valeurs dépassent un seuil défini, VACUUM si nécessaire.
Comment :
Utilisez check_postgres orpgmetrics pour obtenir des estimations de gonflement. Voir le wiki pour plus d'informations.
3. Analyses séquentielles
Lorsque des requêtes sont exécutées qui n'utilisent pas de manière optimale les index disponibles, ou si les informations statistiques associées à une table sont trop obsolètes, Postgres peut finir par devoir parcourir chaque ligne de la table. C'est ce qu'on appelle un balayage séquentiel , et n'est pas très souhaitable dans le cas général. Ce qu'il serait préférable d'avoir, c'est un balayage d'index , où les lignes d'une table sont accessibles indirectement via la recherche d'index.
PostgreSQL peut vous dire combien de fois une table a été analysée de manière séquentielle et combien de fois un index a été utilisé. Vous pouvez l'utiliser pour surveiller soit le nombre d'analyses séquentielles (si vous souhaitez les éviter totalement), soit un pourcentage du nombre total d'analyses.
Action :Surveillez en permanence la suite. nombre ou pourcentage d'analyses, alerte si la valeur dépasse un seuil défini.
Comment :
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Niveau d'indexation
1. Taille de l'index
Les index peuvent occuper un espace disque considérable. Chaque index d'une table peut lui-même potentiellement avoir autant d'empreinte disque que la table elle-même. Il est utile de garder un œil sur la taille totale des index dans une base de données ou sur les index des tables importantes, en particulier dans les déploiements où les index peuvent être créés via des processus automatiques.
Des index déraisonnablement volumineux peuvent être dus à un gonflement ou simplement à un index mal conçu. Dans les deux cas, la résolution de la cause (soit en reconstruisant l'index, soit en refactorisant la requête/l'index) peut accélérer les temps de requête, il vaut donc la peine d'étudier les index volumineux.
Action :surveiller la taille totale des index intéressants au cours de chaque semaine/mois, enquêter lorsqu'ils sont déraisonnablement importants.
Comment :
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Gonflement de l'index
Les index peuvent également être gonflés. Il y a beaucoup trop de facteurs, y compris la charge de travail de la table, le type d'index, la version de Postgres et plus encore, qui décident de la façon dont un index devient gonflé. Les index gonflés peuvent ralentir les insertions et réduire les performances de recherche. Surveillez le gonflement des index sous forme de valeur absolue (nombre d'octets) et de pourcentage. Les index devront être reconstruits lorsqu'ils seront trop gonflés.
Action :surveillez en permanence le gonflement de l'index 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.
3. Taux d'accès au cache
PostgreSQL met en cache en mémoire les régions d'index (ainsi que les tables) fréquemment consultées. Si vous avez réglé vos requêtes pour qu'elles ne touchent pas les tables, sauf pour la récupération des lignes, l'étape suivante consiste à assurer une résidence maximale du cache pour ces index importants qui accélèrent vraiment vos requêtes.
L'utilisation du cache d'un index peut être mesurée par le taux d'accès au cache, qui est le pourcentage de blocs de l'index qui ont été lus à partir du cache par rapport au nombre total de blocs lus.
Action :surveiller en permanence le pourcentage de taux d'accès au cache, alerter si la valeur tombe en dessous d'un seuil défini. Examinez les valeurs faibles pour les index importants.
Comment :
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Niveau système
Outre les métriques PostgreSQL, il est important de garder une trace de quelques métriques de la machine ou de la machine virtuelle sur laquelle vous exécutez votre Postgres. Vous pouvez utiliser n'importe quelle solution de surveillance populaire pour cela, ou même les saisir et les suivre vous-même.
1. Mémoire utilisée
Les systèmes Linux modernes ont une comptabilité mémoire complexe. Nous vous recommandons de surveiller la "mémoire utilisée", qui est la mémoire restante après prise en compte de la mémoire marquée comme libre , en tant que tampons , comme mis en cache , et comme dalle . Les tampons et le cache céderont sous la pression, tout comme la plupart (généralement plus de 95 %) de la dalle.
La mémoire utilisée doit cependant être mesurée sur une période suffisamment longue. Si vous avez des travaux par lots, des rapports, ETL, etc. qui s'exécutent le week-end, la période serait d'une semaine. La véritable mesure que vous devrez surveiller est la mémoire maximale utilisée sur cette période.
En règle générale, à mesure que la taille de votre base de données augmente, cette valeur a tendance à augmenter. Vous devrez vous assurer que l'utilisation maximale de la mémoire se situe dans une limite confortable de mémoire disponible, par exemple 60 à 80 %. Négliger cela entraînerait l'échec de vos charges de travail analytiques/OLAP par manque de mémoire.
Action :Surveiller la mémoire maximale utilisée sur une semaine/quinzaine, alerter si elle dépasse un seuil défini, reprovisionner.
Comment faire :
La mémoire utilisée est donnée par MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab ,où le Mem* les champs proviennent de /proc/meminfo . Pour plus d'informations, consultez cet article RedHat.
2. Charge moyenne
La valeur moyenne de charge simple reste le moyen le plus simple et le plus rapide d'estimer la charge sur un serveur. Cela est particulièrement vrai pour les serveurs Postgres, car chaque backend est un processus de système d'exploitation distinct, et le fait d'en avoir plusieurs dans un état exécutable augmentera la valeur moyenne de la charge.
Pour un serveur Postgres donné, la charge moyenne doit rester dans une plage raisonnable sur un cycle économique (comme une semaine, y compris les exécutions de tâches par lots).
Action :surveillez la moyenne de charge maximale sur chaque jour/semaine, en examinant les tendances à la hausse.
Comment faire :
Les moyennes de charge sur 1 minute, 5 minutes et 15 minutes sont les 3 premiers champs de la première ligne du fichier /proc/loadavg .
3. Espace disque libre
Le dernier élément de notre liste est l'élément le plus évident à surveiller :la quantité d'espace disque libre dans chaque système de fichiers utilisé par votre serveur PostgreSQL, y compris les espaces de table, les répertoires de fichiers WAL, les répertoires de sauvegarde et les fichiers journaux du serveur. Dans les cas où trop de fichiers (des centaines de millions) sont créés dans un seul système de fichiers, assurez-vous que le nombre d'inodes libres est également surveillé. Le manque d'inodes est également signalé comme un espace disque insuffisant.
Action :surveillez en permanence l'espace disque libre et l'utilisation des inodes sur tous les systèmes de fichiers pertinents, alertez si les valeurs tombent en dessous d'un seuil défini.
Comment faire :
L'espace disque libre dans un système de fichiers n'est pas récupérable directement en lisant n'importe quel fichier dans /proc . Vous pouvez utiliser stat -f /path/to/mount ou même df pour trouver l'espace disque utilisé, libre et réservé pour un système de fichiers monté spécifique.
Référence rapide
Voici une liste complète de toutes les métriques dont nous avons discuté jusqu'à présent dans cette série. N'oubliez pas qu'il ne s'agit que de l'ensemble minimal et essentiel de métriques que vous devez surveiller afin de détecter quand les choses sont sur le point de se gâter avec votre déploiement PostgreSQL.
Niveau du cluster
- Plage d'ID de transaction
- Nombre de backends
- Emplacements de réplication inactifs
- Backends en attente de verrous
- Backends inactifs dans la transaction
- Délai de réplication pour les connexions actives
- Délai de réplication pour les emplacements de réplication
- Nombre de fichiers WAL
- Nombre de fichiers WAL prêts à être archivés
Niveau de la base de données
- Clients connectés
- Taille
- Tableau gonflé sur tous les tableaux
- Bouffée d'index sur tous les index
- Transactions de longue durée
- Interblocages
- Le plus ancien aspirateur
- Analyse la plus ancienne
Niveau tableau
- Taille du tableau
- Tableau ballonné
- Analyses séquentielles
Niveau d'indexation
- Taille de l'index
- Bouffée d'index
- Taux d'accès au cache
Niveau système
- Mémoire utilisée
- Moyenne de charge
- Espace disque libre
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.
