
Supervision
L’outil pgwatch est l’un des outils les plus populaires pour la supervision des instances PostgreSQL. Le projet a été initié par la société Cybertec pour ses propres besoins. Initialement en version 2, pgwatch2 a été réécrit récemment en version 3. Pavlo Golub est en charge du projet chez Cybertec.
Cette version 3 propose les mêmes fonctionnalités éprouvées de la version 2 avec quelques nouveautés, notamment le stockage en parallèle vers plusieurs stockages, l’utilisation de l’API v3 de Etcd, la factorisation du code et la dépréciation de certains types de stockage (InfluxDB par exemple), la mise à jour des versions de certains composants tels que Grafana ou les images Docker mises à disposition.
Pour rappel, pgwatch se base sur un collecteur écrit en go
qui vient récupérer une liste de métriques prédéfinies,
mais extensibles à souhait afin de récupérer des statistiques sur vos instances PostgreSQL et le système (moyennant l’utilisation de l’extension PL/Python
) quelque
soit leur nombre avec le minimum d’impact. Le stockage des métriques s’effectue sur PostgreSQL, mais il est aussi possible de choisir TimescaleDB, Prometheus ou des fichiers JSON.
Les tableaux de bord fournis sont utilisables dans l’outil Grafana, ce qui permet de les personnaliser finement, de créer des alertes, et de gérer finement les accès aux différents tableaux et données collectées.
pgwatch permet aussi de récupérer les statistiques des outils tels que PgBouncer
, Patroni
, Pgpool-II
, Prometheus
, de parser les logs de PostgreSQL, ou de récupérer des statistiques depuis des services managés de PostreSQL chez divers fournisseurs de solution cloud (AWS, Azure, GCP).
L’architecture de pgwatch est très modulaire et permet de s’adapter à votre infrastructure et à tous vos cas d’usage ou presque.
Quelques nouveautés
Remote Sinks
Une des nouveautés de la version 3 de pgwatch est le découplage de la partie stockage. L’introduction des remote sinks
avec la possibilité d’utiliser l’interface (basée sur RPC) mise à disposition pour implémenter un type de stockage particulier pour y pousser les métriques de pgwatch.
Mais aussi, la possibilité de disposer en parallèle de plusieurs stockages des métriques, par exemple vers une base de données et un fichier JSON.
Etcd
Autre grosse nouveauté, c’est le passage à la version 3 de l’API de etcd
.
En effet, jusqu’à la version 3.3 de etcd
, l’API par défaut était la version 2. Le protocole de la version 2 n’étant pas compatible avec la version 3 de ce dernier. Lors de l’utilisation d’un cluster Patroni et de la découverte automatique des noeuds, pgwatch se base sur le protocole d'etcd
.
Pour cette raison, pgwatch en version 3 utilise la version 3.5 de etcd
afin d’utiliser le protocole version 3 de l’API etcd
. Le protocole version 2 n’étant pas compatible avec le protocole en version 3, les clés/valeurs de la version 2 ne pourront être lues avec la version 3. Il faudra migrer en utilisant la procédure de migration donnée par etcd
ici. Côté patroni
, la migration repose sur le changement dans le fichier de configuration de la version de etcd
en indiquant etcd3
.
La documentation de pgwatch est disponible ici pour la version 3.
Migration vers pgwatch3
La question de la migration de pgwatch2 vers pgwatch3 se pose. Dans la documentation actuelle, rien n’y fait référence. Mais après discussion avec Pavlo Golub, il existe un utilitaire de conversion pour convertir des métriques personnalisées au format utilisé par pgwatch2 vers celui de pgwatch3.
Il est ainsi possible de récupérer vos anciennes métriques personnalisées pour les convertir dans le format utilisé par pgwatch avec un unique fichier .yaml
:
go run convert_metrics.go --src /home/projects/pgwatch2/pgwatch2/metrics/ --dst /tmp/metrics.yaml