PoWA archivist est l’extension centrale du logiciel PoWA. Son rôle est de capturer, échantilloner et stocker les informations fournies par les extensions de collectes.

Les actions de PoWA archivist sont gérées par un background worker, un processus dédié géré directement par PostgreSQL. Ce processus va capturer de façon régulière, suivant le paramétrage de l’extension, les métriques des collecteurs disponibles. Ces métriques sont ensuite échantillonnées grâce à des fonctions spécifiques. Les résultats sont stockés dans une base de données dédiée de l’instance. Les données stockées sont purgées pour ne garder que l’historique configuré.

Plus d’information sur les clés de configuration dans la documentation.

HypoPG est une extension développée pour PoWA. Elle ne fournit pas de statistiques supplémentaires. Elle permet de créer des index hypothétiques qui n’exisent pas sur disque. Leur création est donc instantanée et n’a aucun impact sur les disques ou la charge CPU. Couplée aux autres extensions de PoWA, HypoPG permet de tester si un nouvel index pourrait améliorer les performances d’une requête donnée.

Plus d’information dans la documentation du projet HypoPG.

PoWA fournit une interface web basée sur le framework Tornado : PoWA-web. Cette interface permet d’exploiter les données stockées par PoWA archivist, et donc d’observer en temps réel l’activité de l’instance. Cette activité est présentée sous forme de graphiques interactifs et de tableaux permettant de trier selon divers critères les différentes requêtes normalisées sur l’intervalle de temps sélectionné.

Une démo de cette interface est disponible sur le site : http://demo-powa.dalibo.com/.

PoWA est efficace car il est au plus près de l’instance. Son utilisation a cependant un impact indéniable sur les performances. Cet impact est dû à l’activation de l’extension pg_stat_statements et à la collecte des données par PoWA. Pour plus d’information, voir le comparatif fait par notre équipe.

PoWA s’installe comme une extension de PostgreSQL et stocke ses informations dans une base de données de l’instance. Une défaillance sur un outil externe ne posera pas de problème sur l’instance. Un problème sur n’importe quelle extension de PoWA peut conduire à un crash de votre instance. Il est important de bien tester l’outil avant de l’installer et de l’utiliser en production.

Les informations étant fournies par des extensions requérant un accès direct au moteur de chaque instance, l’utilisation de PoWA nécessite le stockage d’information sur chacune des instances que l’on souhaite gérer. Un serveur secondaire est en lecture seule. On ne peut donc pas y utiliser PoWA.

En cas d’incident sur une production, PoWA permet de détecter immédiatement la ou les requêtes posant problème. Il peut proposer des optimisations pour améliorer la situation.
Si la conservation d’un historique suffisant a été configuré, il permet de comparer les performances entre deux périodes données.

Les modules de collectes regroupent leurs métriques par requête normalisée, utilisateur et base de données. Toutes les informations récoltées par PoWA sont donc disponibles avec cette granularité.

temBoard est une console d’administration et de supervision d’instances PostgreSQL. Il offre une centralisation des interactions et accès aux données collectées, s’inscrivant ainsi dans une politique de gestion de parc.

L’outil est constitué de deux composants :

• un serveur, proposant une interface web au travers de laquelle les DBAs vont pouvoir interagir avec les instances Postgres;
• un agent, devant être déployé sur chaque hôte hébergeant une instance Postgres à surveiller.

Le serveur nécessite l’usage de sa propre base de données dans le but d’historiser les différentes données remontées par les agents.

Chaque fonctionnalité est implémentée sous forme de plugin, et peut être activée ou désactivée par instance.

L’interface utilisateur de temboard est développée en python 2.7 et repose sur le framework web Tornado.

Une base de données, appelée repository est nécessaire à son fonctionnement, en effet, celle-ci va permettre de stocker :

• la liste des comptes utilisateurs habilités à se connecter à l’interface;
• la liste des instances Postgres à gérer;
• l’historique des données collectées.

L’accès à cette interface est protégée par une authentification utilisateur.

Il est possible d’installer temBoard en utilisant PyPI, ou bien

L’installation de temBoard est possible soit le gestionnaire de paquets pip via PyPI. Des paquets sont également disponible sur les dépôt yum et apt de dalibo pour les systèmes d’exploitation CentOS/RHEL en version 7 et debian en version jessie et stretch.

L’agent temboard doit quant à lui être déployé sur chaque hôte qui héberge une instance PostgreSQL. Celui-ci ne peut gérer qu’une seule instance PostgreSQL.

Il est développé en python et est compatible avec des versions 2.6+ et 3.5+.

Il est interrogeable et contrôlable au travers d’une API REST (HTTPS) et peut facilement entrer en interaction avec des outils tiers.

Documentation de l’API : https://temboard-agent.readthedocs.io/en/latest/api.html

L’agent embarque son propre système d’authentification, qui est indépendant de celui de l’interface utilisateur. La sécurité des échanges est garantie par le protocole sécurisé HTTPS.

De nombreuses fonctionnalités sont disponibles.

Donne une vision en temps réel (rafraîchissement toutes les 2 secondes) de l’état du système et de l’instance Postgres en mettant en évidence certaines données :

• Métriques système : usage CPU, mémoire, loadaverage.
• Métriques Postgres : Cache Hit Ratio, Sessions, TPS.
• Statut de chaque métrique calculé selon des seuils (alerting).

Ce plugin permet de consulter en temps réel la liste des requêtes SQL en cours d’exécution, les requêtes bloquées ou les requêtes bloquantes. La liste affichée des backends contient les informations suivantes :

• PID du processus,
• nom de la base,
• utilisateur,
• usage CPU,
• usage mémoire,
• I/O,
• si le backend est en attente de verrou,
• durée d’execution,
• requête SQL.

Il permet également de mettre en pause le rafraichissement automatique et de terminer un backend.

L’agent collecte périodiquement des données de métrologie que ce soit au niveau du système (CPU, mémoire, occupation disque, charge) ou au niveau de l’instance Postgres (TPS, tailles, cache hit ratio, verrous, taux d’écriture des WAL, etc). Ces données sont ensuite envoyées à l’interface puis historisées dans le repository.

L’interface offre au DBA une consultation de ces données sous forme de graphiques, navigables dans le temps. Ces données sont également comparées lors de la réception à des seuils (configurables) afin de déclencher une alerte si la valeur excède le seuil défini. Ces alertes sont visibles soit sur le dashboard, soit sur une page dédiée appelée Status. L’historique des alertes est également navigable dans le temps.

Le plugin Monitoring permet également d’envoyer des alertes en cas de dépassement de seuils des sondes. Ces alertes peuvent être faites par mail ou par SMS. Les notification par SMS sont effectuées grâce au service Twilio.

On peut activer / désactiver les alertes pour chaque utilisateur.

La vue Status permet d’afficher l’état des différentes sondes de l’instance sur une seule page. Pour chaque sonde, les niveaux d’alertes Warning et Critical sont précisés.

On cliquant sur la sonde, on accède au graphique historique. On peut à partir de cette vue :

• changer son nom,
• activer / désactiver la sonde,
• modifier les niveau d’alertes Warning et Critical.

Permet un accès simplifié en lecture et écriture aux paramètres de configuration de l’instance Postgres. La modification des paramètres s’effectue avec l’ordre SQL ALTER SYSTEM.

Dans le cas où une modification de paramètre nécessite le redémarrage de l’instance, une alerte s’affiche en haut de cette page.

Ce module permet de visualiser pour chaque objet de l’instance le volume des tables et des index. Pour chacun de ces types d’objets, il permet de voir le volume de fragmentation présent.

On peut naviguer dans les histogrammes des volumes de plus en plus finement :

• par base de données,
• par schéma d’une base de données,
• par table et index d’un schéma.

On peut choisir de trier les objets selon différents critères : nom, taille totale, taille des tables, taille des index, volume de fragmentation…

En sélectionnant une table, on peut y lancer des opérations de maintenance :

• ANALYSE
• VACUUM
• REINDEX de la table ou d’un index

Des messages d’information alertent le DBA du besoin d’exécution de certaines opérations.

La page Notifications permette de réaliser un audit des connections et actions effectuées depuis l’interface de temBoard.

temBoard est encore en phase de développement, certaines fonctionnalités intéressantes ne sont pas encore implémentées mais devraient l’être dans un avenir proche.

Par exemple, temBoard ne gère pas les sauvegardes physiques ou logiques. Il ne sait pas non plus alerter en cas d’erreur sur des sauvegardes.

L’agent doit être colocalisé avec l’instance. Ce n’est pas possible dans le cloud public.

Une autre problématique est que tout accès à l’agent se fait avec des droits d’administration. Il n’est pas possible de donner uniquement des droits d’observation à un utilisateur authentifié auprès d’un agent.

L’objectif de temBoard est de proposer un seul et unique outil permettant l’administration courante et la supervision d’un parc d’instance Postgres. Il reste encore du chemin pour atteindre ce but, mais le développement est actif.

Une bonne politique de supervision est la clef de voûte d’un système pérenne. Pour cela, il faut tout d’abord s’assurer que les traces et les statistiques sont bien configurées. Ensuite, l’installation d’un outil d’historisation, de création de graphes et de génération d’alertes, est obligatoire pour pouvoir tirer profit des informations fournies par PostgreSQL.

Les trois outils graphiques présentés demandent une configuration préalable. S’ils ne sont pas utiles pour alerter en cas de problèmes, leur utilisation permet de découvrir rapidement les origines du problème et de le corriger :

• pgBadger analyse les logs de l’instance et permet de pointer les erreurs et axes d’améliorations des applications.
• PoWA analyse en temps réel de l’intérieur de l’instance, les requêtes s’y exécutant. Il permet de pointer les requêtes lentes et peut même proposer la création d’index.
• temBoard analyse lui aussi en temps réel l’activité de l’instance, mais aussi du système l’hébergeant. Il permet également d’agir sur l’instance en modifiant ses paramètres ou en stoppant des requêtes.

pgBadger

Installation

Suivant les outils à disposition sur votre ordinateur, vous avez 2 moyens à disposition pour installer le blaireau : utiliser le paquet sur le dépôt communautaire ou récupérer le projet github.

Installer le paquet sur debian sera aussi simple qu’un :

$ apt install --yes pgbadger
$ pgbadger --version
pgBadger version 11.1

Si Perl est disponible sur votre ordinateur, vous pouvez opter pour la récupération du projet sur github et le lancement du script en direct :

$ git clone https://github.com/darold/pgbadger.git
$ export PATH="$PATH:$(pwd)/pgbadger/pgbadger"
$ pgbadger --version
pgBadger version 11.1

Les logs PostgreSQL utilisés pour le TP sont stockés dans le répertoire ~dalibo/Documents.

Dans tous les cas, vous pouvez également récupérer ces logs en suivant le lien suivant : https://public.dalibo.com/workshop/workshop_supervision/logs_postgresql.tgz.

L’archive contient 9 fichiers de traces de 135 Mo chacun :

$ tar xzf logs_postgresql.tgz
$ cd logs_postgresql
$ du -sh *
135M    postgresql-11-main.1.log
135M    postgresql-11-main.2.log
135M    postgresql-11-main.3.log
135M    postgresql-11-main.4.log
135M    postgresql-11-main.5.log
135M    postgresql-11-main.6.log
135M    postgresql-11-main.7.log
135M    postgresql-11-main.8.log
135M    postgresql-11-main.9.log

Premier rapport

Nous allons commencer par créer un premier rapport à partir du premier fichier de logs. L’option -j est à fixer à votre nombre de processeurs :

Si vous utiliser le script Perl :

$ pgbadger -j 4 postgresql-11-main.1.log

Le fichier de rapport out.html est créé dans le répertoire courant. Avant de l’ouvrir dans le navigateur, lançons la création du rapport complet :

$ pgbadger -j 4 --outfile rapport_complet.html postgresql-11-main.*.log

Pendant la création du rapport complet, ouvrez-le fichier out.html dans votre navigateur. Parcourir les différents onglets et graphiques.

Une fois le rapport complet créé, ouvrez le dans votre navigateur.

On peut observer dans les sections Connections et Sessions un nombre de sessions et de connexions proches. Chaque session doit ouvrir une nouvelle connexion. Ceci est assez coûteux, un processus et de la mémoire devant être alloués.

La section Checkpoints montre une activité d’écriture normale.

La section Temp Files permet, grâce au graphique temporel, de vérifier si un ralentissement de l’instance est corrélé à un volume important d’écriture de fichiers temporaires. Le rapport permet également de lister les requêtes ayant généré des fichiers temporaires. Suivant les cas, on pourra tenter une optimisation de la requête ou bien un ajustement de la mémoire de travail, work_mem.

La section Vacuums liste les différentes tables ayant fait l’objet d’un VACUUM.

Le section Locks permet d’obtenir les requêtes normalisées ayant le plus fait l’objet d’attente sur verrou. Le rapport pgBadger ne permet pas toujours de connaître la raison de ces attentes.

La section Queries fournit une connaissance du type d’activité sur chaque base de données : application web, OLTP, data warehouse. Elle permet également, si le paramètre log_line_prefix le précise bien, de connaître la répartition des requêtes selon la base de données, l’utilisateur, l’hôte ou l’application.

La section Top est très intéressante. Elle permet de lister les requêtes normalisées ayant pris le plus de temps. Fixer le paramètre log_min_duration_statement à 0 permet de lister toutes les requêtes exécutées. Une requête peut ne mettre que quelques dizaines de millisecondes à s’exécuter. Mais si elle est lancée des millions de fois par heure, une optimisation de quelques pourcent peut avoir un impact non négligeable.

Dans la section Top, normalisée les plus lentes et le nombre de fois où elles ont été exécutées.

Format des logs

Dans certains cas, pgBadger peut ne pas réussir à détecter automatiquement le format du fichier ou le préfixe des lignes. Pour le format du fichier, on pourra utiliser l’option --format. On pourra par exemple préciser que le fichier est au format csv ou bien qu’il s’agit d’un log de pgbouncer.
Pour le préfixe des lignes, on pourra utiliser l’option --prefix. En cas de doute sur la configuration et si l’accès à l’instance est possible, on pourra récupérer l’information via la requête :

$ psql -At -c 'show log_line_prefix'
%t [%p]: user=%u,db=%d,app=%a,client=%h 

Rapport précis

La vue des verrous nous informe d’un problème sur la base de données bank vers 16h50. Nous allons réaliser un rapport spécifique sur cette base de données et cette période :

$ pgbadger -j 4 --outfile rapport_bank.html --dbname bank        \
   --begin "2018-11-12 16:45:00 CET" --end "2018-11-12 16:55:00 CET"  \
   postgresql-11-main.*.log

Nous voulons connaître plus précisément quelles requêtes venant de l’IP 192.168.0.84 et avoir une vue plus fine des graphiques. Nous allons créer un rapport en filtrant par client et en calculant les moyennes par minute :

$ pgbadger -j 4 --outfile rapport_host_89.html --dbclient 192.168.0.89 \
   --average 1 postgresql-11-main.*.log

Il est également possible de filtrer par application avec l’option --appname.

Mode incrémental

Les fichiers de logs sont volumineux. On ne peut pas toujours conserver un historique assez important. pgBadger peut parser les fichiers de log et stocker les informations dans des fichiers binaires. Un rapport peut-être construit à tout moment en précisant les fichiers binaires à utiliser.

$ mkdir /tmp/incr_report
$ pgbadger -j 4 -I --noreport -O /tmp/incr_report/ postgresql-11-main.1.log
$ tree /tmp/incr_report
/tmp/incr_report
├── 2018
│   └── 11
│       └── 12
│           ├── 2018-11-12-25869.bin
│           ├── 2018-11-12-25871.bin
│           ├── 2018-11-12-25872.bin
│           └── 2018-11-12-25873.bin
└── LAST_PARSED

3 directories, 5 files
$ cat /tmp/incr_report/LAST_PARSED 
2018-11-12 16:36:39 141351476   2018-11-12 16:36:39 CET [17303]: user=banquier,
  db=bank,app=gestion,client=192.168.0.84 LOG:  duration: 0.2

Le fichier LAST_PARSE stocke la dernière ligne analysée. Dans le cas d’un fichier de log en cours d’écriture, pgBadger commencera son analyse au prochain lancement de ,

Le fichier postgresql-11-main.1.log occupe 135 Mo. On peut le compresser pour le réduire à 7 Mo. Voyons l’espace occupé par les fichiers incrémentaux de pgBadger :

$ mkdir /tmp/incr_report
$ pgbadger -j 4 -I --noreport -O /tmp/incr_report/ postgresql-11-main.1.log
$ du -sh /tmp/incr_report/
340K    /tmp/incr_report/

On pourra reconstruire à tout moment les rapports avec la commande :

$ pgbadger -I -O /tmp/incr_report/ --rebuild

Ce mode permet de plus construire des rapports réguliers journalier et hebdomadaire. Vous pouvez vous référer à la documentation pour en savoir plus sur ce mode incrémental.

PoWA

Afin de créer de l’activité SQL sur notre environnement PoWA, nous allons générer du trafic SQL via l’outil pgbench. Pour cela, nous allons lancer les commandes suivantes dans un terminal :

$ sudo -iu postgres
postgres$ pgbench -c 4 -T 1000 bench

Installation

L’installation d’un environnement fonctionnel PoWA en version 3.2 a été effectué sur la machine virtuelle.

En attendant que l’activité soit visible, étudions comment nous avons mis en place PoWA sur la machine virtuelle. Nous avons tout d’abord installé powa-archivist sur le serveur hébergeant l’instance :

# installation de powa et des différents modules disponible
apt install postgresql-12-powa postgresql-12-pg-qualstats \
            postgresql-12-pg-stat-kcache postgresql-12-hypopg

La configuration de l’instance a été mise à jour pour charger les modules au démarrage, récupérer les temps d’accès des entrées / sorties et récupérer des métriques dans PoWA toutes les 15 secondes :

shared_preload_libraries = 'pg_stat_statements,pg_stat_kcache,pg_qualstats,powa'
track_io_timing = on
powa.frequency = '15s'

L’instance a ensuite été redémarrée :

# systemctl restart postgresql@12-main.service

Nous avons ensuite procédé, via l’utilisateur postgres à l’installation de la base de données PoWA :

postgres$ psql -c 'CREATE DATABASE powa'
postgres$ psql -d powa -c 'CREATE EXTENSION btree_gist'
postgres$ psql -d powa -c 'CREATE EXTENSION pg_stat_statements'
postgres$ psql -d powa -c 'CREATE EXTENSION pg_qualstats'
postgres$ psql -d powa -c 'CREATE EXTENSION pg_stat_kcache'
postgres$ psql -d powa -c 'CREATE EXTENSION powa'
postgres$ psql -d powa -c 'CREATE EXTENSION hypopg'

Puis créé l’utilisateur powa_user :

postgres$ psql -c "CREATE ROLE powa_user LOGIN SUPERUSER PASSWORD 'powa'"

Nous avons ensuite mis en place la base de données bench sur laquelle nous sommes en train de générer de l’activité :

postgres$ psql -c "CREATE DATABASE bench;"
postgres$ pgbench -i bench

Pour montrer l’intérêt de PoWA pour la suggestion d’index, nous avons supprimé une contrainte :

postgres$ psql -d bench \
    -c "ALTER TABLE pgbench_accounts DROP CONSTRAINT pgbench_accounts_pkey"

Nous avons ensuite procédé à l’installation de powa-web à partir du dépôt git :

dalibo:~/git$ git clone https://github.com/powa-team/powa-web.git
dalibo:~/git$ cd powa-web
dalibo:~/git/powa-web$ git checkout 682d0a78311e9ef44f8f355d0903657b189cac4a
dalibo:~/git/powa-web$ cp powa-web.conf-dist powa-web.conf

Nous avons installé les paquets python nécessaire à son fonctionnement :

# apt install python-tornado python-sqlalchemy python-psycopg2

Visualisation

Nous devons lancer le logiciel powa-web :

dalibo:~/$ cd /git/powa-web
dalibo:~/git/powa-web$ ./powa-web
[I 191107 15:45:46 powa-web:12] Starting powa-web on http://0.0.0.0:8888

Ouvrir votre navigateur à l’adresse http://127.0.0.1:8888

Pour l’authentification, le nom d’utilisateur est « powa_user », le mot de passe « powa ».

La page principale vous pouvez maintenant permet de visualiser les différentes métriques par base de données.

En sélectionnant une base de données, on accède aux métriques par requêtes.

La sélection d’une requête permet d’accéder à des informations spécifique pour cette requête. Cette vue permet de voir si une requête change de comportement au cours du temps.

Choisir la base de données bench. Cliquer sur le bouton Optimize Database. Que constate-t’on ?

Choisir une requête qui procède à des mises à jour de la table pgbench_accounts. Naviguer dans l’onglet Predicates. Quel serait le gain si l’index suggéré était utilisé ?

temBoard

L’installation d’un environnement fonctionnel temBoard en version 4.1 a été effectué sur la machine virtuelle.

Pour créer de l’activité SQL pour notre environnement temBoard, nous allons de nouveau générer du trafic SQL via l’outil pgbench. Pour cela, lancer les commandes suivantes dans un nouveau terminal :

$ sudo -iu postgres
postgres$ psql -p 5433 -c "CREATE DATABASE bench;"
postgres$ pgbench -p 5433 -i bench
postgres$ pgbench -p 5433 -c 2 -T 500 bench

Stopper le trafic lancée lors du TP PoWA sur l’instance en version 12 et le relancer avec plus de sessions :

postgres$ pgbench -c 8 -T 200 bench

Installation

En attendant que l’activité soit visible, étudions comment nous avons mis en place temBoard sur la machine virtuelle. L’installation d’un environnement fonctionnel temBoard a été effectuée grâce à pip :

apt install python-pip
pip install psycopg2-binary temboard temboard-agent

Pour bien fonctionner, temBoard a besoin d’un FQDN bien fonctionnel. On l’a défini dans le fichier /etc/hosts :

# hostname --fqdn
supervision
# sed -i 's/127.0.1.1\tsupervision/127.0.1.1\tsupervision.ws\tsupervision/' /etc/hosts
# hostname --fqdn
supervision.ws

Nous avons ensuite initié temBoard. Le script temBoard auto_configure.sh a créé la base de données et la configuration du logiciel :

# /usr/local/share/temboard/auto_configure.sh 
Creating Postgres user, database and schema.
Creating system user temBoard.
Configuring temboard in /etc/temboard.
Using snake-oil SSL certificate.

Success. You can now start temboard using:

    systemctl start temboard

Remember to replace default admin user!!!

PoWA utilise le port 8888. Nous allons faire tourner temBoard sur le port 9999. Nous ajoutons la clé de configuration du port dans la section [temboard] du fichier /etc/temboard/temboard.conf :

port = 9999

Nous avons ensuite configuré le service pour qu’il démarre de façon automatique :

# systemctl enable temboard
# systemctl start temboard

Dans l’interface de temBoard, nous avons déclaré un nouvel utilisateur administrateur pour l’accès aux agents, login : tmbagent, mot de passe : temboard.

Une fois l’interface utilisateur installée, il faut installer un agent par instance PostgreSQL à superviser. Nous avons installé un agent pour l’instance PostgreSQL 12-main en utilisant l’utilisateur tmbagent créé ci-dessus :

# export PGPORT=5432
# /usr/local/share/temboard-agent/auto_configure.sh https://supervision.ws:9999
# sudo -u postgres temboard-agent-adduser -c /etc/temboard-agent/12/main/temboard-agent.conf
# systemctl enable temboard-agent@12-main.service
# systemctl start temboard-agent@12-main.service
# sudo -u postgres temboard-agent-register \ 
    -c /etc/temboard-agent/12/main/temboard-agent.conf --host $(hostname --fqdn) \
    --port 3345 --groups default https://supervision.ws:9999

Nous avons procédéde même pour l’agent pour de l’instance PostgreSQL 11-main :

# export PGPORT=5433
# /usr/local/share/temboard-agent/auto_configure.sh https://supervision.ws:9999
# sudo -u postgres temboard-agent-adduser -c /etc/temboard-agent/11/main/temboard-agent.conf
# systemctl enable temboard-agent@11-main.service
# systemctl start temboard-agent@11-main.service
# sudo -u postgres temboard-agent-register \ 
    -c /etc/temboard-agent/11/main/temboard-agent.conf --host $(hostname --fqdn) \ 
    --port 3345 --groups default https://supervision.ws:9999

Visualisation

Ouvrir votre navigateur à l’adresse https://127.0.0.1:9999

Pour l’authentification, le nom d’utilisateur est admin, mot de passe admin.

Les instances sont nommées par leurs noms d’hôte. Les 2 instances sont donc nommées supervision.ws. Ici, le numéro de port et la version de PostgreSQL permettent de différencier entre les instances supervisées.

Cliquez sur supervision.ws de la version 12, et étudiez les différents modules.

Nous allons à présent verrouiller de manière exclusive un table de la base bench dans le but de bloquer l’activité. Pour cela, dans un autre onglet du terminal :

$ sudo -iu postgres psql bench

bench=# BEGIN;

bench=# LOCK TABLE pgbench_tellers IN EXCLUSIVE MODE;

Revenir sur le Dashboard temboard et attendre quelques instants, que constate-t-on ?

Cliquer sur Status, puis sur Waiting sessions.

Aller sur la vue Activity et naviguer entre les onglets Running, Waiting, Blocking.

Depuis l’onglet Blocking, cocher la ligne de la requête bloquante, puis cliquer sur Terminate, enfin confirmer.

Revenir sur le Dashboard, attendre quelques instants. Que constate-t-on ?

Nous allons maintenant ajouter un nouvel utilisateur, alice, qui aura accès uniquement à l’instance PostgreSQL en version 10 sur le port 5434.

Commençons par installer l’agent pour l’instance en version 10 en suivant la procédure utilisée pour les 2 autres agents. Utilisez l’utilisateur tmbagent pour connecter l’agent à l’UI.

Une fois l’agent installé et l’instance visible dans l’UI temBoard, nous allons ajouter une nouvelle utilisatrice et un nouveau groupe. Pour se faire, cliquer sur le bouton « Settings » en haut à droite de l’interface.

Nous allons créer :

• un nouveau groupe d’utilisatrices « user_pg10 »,
• une nouvelle utilisatrice « alice » dans le groupe « user_pg10 »,
• un nouveau groupe d’instances « instance_pg10 » accessibles par le groupe « user_pg10 »,
• enfin, ajouter l’instance en version 10 dans le groups d’instances « instance_pg10 ».

Déconnectons nous et vérifions ce que l’utilisatrice alice peut visualiser.

Nous constatons que l’utilisatrice ne peut pas modifier le paramétrage de l’instance avec ses identifiants de connexion.

Si nous voulons que alice puisse agir sur l’instance, nous devons la déclarer au niveau de l’agent. Nous pouvons le faire via le script temboard-agent-adduser :

# export PGPORT=5434
# sudo -u postgres temboard-agent-adduser -c /etc/temboard-agent/10/main/temboard-agent.conf

Vérifions ensuite que alice peut agir sur les paramètres de l’instance.