PostgreSQL 10 vient tout juste de sortir et apporte une nouveauté
significative concernant la supervision d'une instance. Grâce au travail de
Dave Page, PostgreSQL 10 amène un rôle système pg_monitor qui
permet d'accéder à toutes les fonctions de supervision sans nécessiter d'être
super-utilisateur.
La sonde check_pgactivity permet naturellement de tirer partie de cette nouvelle possibilité avec votre environnement de supervision Nagios ou compatible.
check_pgactivity 2.3 beta 1
La sonde de supervision check_pgactivity arrive en version 2.3 beta 1 et intègre le support de PostgreSQL 10.
En plus de cela, le service backend_status accepte maintenant
des seuils exprimés avec des unités de temps, par exemple pour détecter les
transactions en attente d'un verrou depuis plus d'un certain temps. Un bug
assez ancien a par ailleurs été corrigé dans ce même service.
Le service sequences_exhausted a été corrigé de manière à
accepter les séquences rattachées à une colonne d'un type non-numérique.
Enfin, pour les personnes souhaitant contribuer au projet, une nouvelle documentation vous permettra de mettre le pied à l'étrier.
Changements majeurs dans PostgreSQL 10
Dans toutes les versions précédentes, il fallait nécessairement être super-utilisateur pour pouvoir superviser une instance PostgreSQL.
Dave Page a répondu à cette problématique en proposant un rôle système
pg_monitor qui permet de bénéficier des droits pour accéder aux
vues pg_stat_* et utiliser les fonctions
pg_database_size() et pg_tablespace_size(). Le commit
25fff40798fc4ac11a241bfd9ab0c45c085e2212 vous permettra d'avoir de plus
amples explications.
Le second changement important concerne le renommage de XLOG en WAL. Ainsi,
le répertoire pg_xlog, qui contient les journaux de transaction,
est renommé en pg_wal. Toutes les fonctions contenant le terme
xlog sont renommées de la même façon, comme
pg_current_xlog_location() qui devient
pg_current_wal_lsn(). À noter que location devient
lsn, mais je ne détaille pas ce changement. Etc.
Enfin, un dernier changement important concerne l'arrivée de la fonction
pg_ls_waldir() pour pouvoir lister le contenu du répertoire
pg_wal. Pour ce faire, nous utilisions auparavant la fonction
pg_ls_dir().
Pour en savoir plus sur tous ces changements, je vous invite à consulter les notes de version de PostgreSQL 10.
Mise en œuvre de la supervision
Création d'un utilisateur de supervision
Commençons par créer un rôle monitor qui ne dispose pas de
privilèges particuliers, mais qui est membre de
pg_monitor :
CREATE ROLE monitor LOGIN IN ROLE pg_monitor;
Pour permettre aux services btree_bloat et
table_bloat de fonctionner, il faut aussi permettre au rôle
monitor d'effectuer un SELECT sur
pg_statistic, dans toutes les bases de données de
l'instance :
GRANT SELECT ON pg_statistic TO monitor;
À noter que vous devrez configurer l'authentification par vous-même, en affectant un mot de passe ou non, à votre guise.
Supervision d'un service
Le service wal_files se connecte à une instance en utilisant le
rôle monitor créé plus haut. Il permet de superviser le nombre de
journaux de transaction présents dans le répertoire
$PGDATA/pg_wal. Nous utilisons la sortie human pour
obtenir un résultat lisible par le commun des mortels :
$ ./check_pgactivity -h localhost -p 5432 -U monitor -F human -s wal_files Service : POSTGRES_WAL_FILES Returns : 0 (OK) Message : 45 WAL files Perfdata : total_wal=45 Perfdata : recycled_wal=44 Perfdata : tli=1 Perfdata : written_wal=1 Perfdata : kept_wal=0 Perfdata : wal_rate=74.45Bps
Si vous utilisez la sonde check_pgactivity avec Nagios, vous
choisirez évidemment le format de sortie nagios, qui est d'ailleurs le
format de sortie par défaut.
Incompatibilités
Comme vu plus haut, les services btree_bloat et
table_bloat doivent avoir accès au catalogue
pg_statistic. Sans cet accès, il n'est pas possible de calculer
une estimation de la fragmentation des index et des tables le plus rapidement
possible dans toutes les situations. Nous avions rencontré un gros problème de
performance sur une base disposant de plusieurs milliers de tables lorsque nous
utilisions encore la vue pg_stats.
Ainsi, nous devons donc donner le privilège de SELECT sur
pg_statisticà notre rôle monitor (ou à
pg_monitor si l'on souhaite être moins restrictif) :
GRANT SELECT ON pg_statistic TO monitor;
UPDATE Le service temp_files, qui permet de
superviser le volume de fichiers temporaires créés, nécessite les privilèges de
super-utilisateur car il utilise la fonction pg_ls_dir(). La sonde
va être corrigée ultérieurement pour qu'elle fonctionne avec PostgreSQL 10,
mais il ne sera plus possible de superviser les fichiers temporaires créés en
"live".
À vous !
N'hésitez pas à nous remonter les problèmes que vous avez pu rencontrer avec
cette dernière version check_pgactivity. Si nous n'avons aucun
retour négatif, la version 2.3 stable va suivre d'ici quelques jours.
Téléchargement
Rendez-vous sur github :
- version 2.3 beta 1 : https://github.com/OPMDG/check_pgac...
- site et documentation du projet : https://github.com/OPMDG/check_pgac...