Supervision graphique en PostgreSQL

Quels outils pour quels problèmes ?

Dalibo & Contributors

Supervision en PostgreSQL

PostgreSQL

Au programme

  • Supervision : quoi et pourquoi ?
  • Trois outils de supervision graphique :
    • PoWA
    • pgBadger
    • temBoard

Superviser ?

| sy.pɛʁ.vi.ze |

« Se placer au-dessus pour voir, remarquer, prendre des mesures »

Que superviser ?

  • Superviser PostgreSQL et le système
  • Deux types de supervision :
    • automatique,
    • occasionnelle.

Politique de supervision

  • Pour quoi ?
  • Pour qui ?
  • Quels critères ?
  • Quels outils ?

Objectifs de la supervision

  • Améliorer / mesurer les performances
  • Améliorer l’applicatif
  • Anticiper / prévenir les incidents
  • Réagir vite en cas de crash

Acteurs concernés

  • Développeur
    • correction et optimisation de requêtes
  • Administrateur de bases de données
    • surveillance, performance
    • mise à jour
  • Administrateur système
    • surveillance, qualité de service

Indicateurs côté système d’exploitation

  • Charge CPU
  • Entrées/sorties disque
  • Espace disque
  • Sur-activité et inactivité du serveur
  • Temps de réponse

Indicateurs côté base de données

  • Nombre de connexions
  • Requêtes lentes et/ou fréquentes
  • Nombre de transactions par seconde
  • Ratio d’utilisation du cache
  • Retard de réplication

Informations internes

  • PostgreSQL propose deux canaux d’informations :
    • les statistiques d’activité
    • les traces
  • Mais rien pour les conserver, les historiser

Outils externes

  • Nécessaire pour conserver les informations
  • … et exécuter automatiquement des actions dessus :
    • Génération de graphiques
    • Envoi d’alertes

Outils graphiques

  • Beaucoup d’outils existent
  • Deux types :
    • en temps réel : PoWA et temboard
    • rétro-analyse : pgBadger

pgBadger

pgBadger

  • Script Perl
  • site officiel : https://pgbadger.darold.net/
  • Traite les journaux applicatifs de PostgreSQL
  • Génére un rapport HTML très détaillé

Configurer PostgreSQL pour pgBadger

  • Utilisation des traces applicatives
  • Où tracer ?
  • Quel niveau de traces ?
  • Tracer les requêtes
  • Tracer certains comportements

Configuration minimale

  • traces en anglais
    • lc_messages='C'
  • ajouter le plus d’information possible
    • log_line_prefix = '%t [%p]: user=%u,db=%d,app=%a,client=%h '

Tracer certains comportements

  • log_connections, log_disconnections
  • log_autovacuum_min_duration
  • log_checkpoints
  • log_lock_waits
  • log_temp_files

Tracer les requêtes

  • log_min_duration_statement
  • en production, trace les requêtes longues
    • 10000 pour les requêtes de plus de 10 secondes
  • pour un audit, à 0 : trace toutes les requêtes

Création d’un rapport pgBadger

$ pgbadger postgresql-11-main.log

  • Rapport dans le fichier out.html
  • Très nombreuses options :
    • fichier de sortie : --outfile
    • filtrage par date : --begin, --end
    • autres filtrages : --dbname, --dbuser, --appname, …

PoWA

PoWA

  • PostgreSQL Workload Analyzer
  • site officiel : https://github.com/powa-team/powa
  • Capture régulière de métriques diverses
  • Stockage efficace des données
  • Interface graphique permettant d’exploiter ces informations

Extensions de collecte

  • pg_stat_statements : métriques côté PostgreSQL
  • pg_stat_kcache : métriques côté système
  • pg_qualstats : informations sur les prédicats
  • extension en développement (ne pas utiliser en production) :
    • pg_sortstats : informations sur la mémoire pour les tris
    • pg_wait_sampling : statistiques sur les évènements en attente

PoWA archivist

  • Extension de PostgreSQL
  • Capture régulière des statistiques
  • Stockage efficace des données

HypoPG

  • Extension de PostgreSQL
  • Créer des index hypothétiques
  • Permet la proposition de nouveaux index

PoWA-web

  • Interface graphique web
  • Permet d’observer en temps réel l’activité des requêtes

Points faibles de PoWA

  • Impact sur les performances
  • Installation de plusieurs extensions sur les instances de production
  • Pas d’informations sur les serveurs secondaires
    • développement en cours pour déporter PoWA sur sa propre instance

Points forts de PoWA

  • Information en temps réel
    • et dans le passé
  • Granularité des informations jusqu’à la requête
    • voire jusqu’au prédicat

temBoard

temBoard

  • Adresse: https://github.com/dalibo/temboard
  • Console centrale d’administration et de supervision
  • Architecture serveur (interface) / agent
  • Historisation des données et temps réel
  • Extensible

temBoard - Serveur

  • Interface Web
    • Python 2.7 / Tornado / SQLALchemy
  • Base de données historique et metadonnées
    • PostgreSQL 9.4+
  • Authentification
  • Disponible sur PyPI et packagé pour :
    • CentOS / RHEL 7
    • debian jessie et stretch

temBoard - Agent

  • Mono-instance
  • Pas de dépendances
  • API REST
  • Authentification
  • Disponible sur PyPI et packagé pour :
    • centos / RHEL (6 et 7)
    • debian (7 à 10)

temBoard - Fonctionnalités

  • Tableau de bord
  • Activité
  • Supervision / Alerting
  • Statut
  • Configuration
  • Maintenance
  • Notifications

Plugin Dashboard : tableau de bord

  • Vision en temps réel de l’état du système
  • Présentation de quelques métriques de l’instance

Plugin Activity : activité

  • liste des requêtes SQL en cours d’exécution
  • permet de terminer un processus serveur

Plugin Monitoring : supervision

  • Affichage des données de supervision
  • au niveau du système :
    • CPU, mémoire, occupation disque…
  • au niveau PostgreSQL :
    • TPS, tailles, cache hit ratio, verrous…

Plugin Monitoring : alerting

  • Envoi d’alerte en cas de dépassement de seuils
  • Par mail ou par SMS
  • Configuration possible par utilisateur

Plugin Status

  • Vision synthétique de l’état des sondes
  • Accès au graphique détaillé

Plugin Configuration 

  • Visualisation des paramètres de l’instance
  • Modification par l’ordre SQL ALTER SYSTEM
  • Recharge de la configuration possible

Plugin Maintenance

  • Volume disque par :
    • base de données / schéma / table
  • des tables, index, toast et fragmentation
  • Lancement d’opérations deANALYSE, VACUUM ou REINDEX

Plugin Notifications 

  • Visualisation des opérations effectuées depuis temBoard

Points faibles de temBoard

  • Pas de gestion des sauvegardes
  • Pas cloud public ready
  • Pas d’accès en observateur au niveau de l’agent
    • accès administrateur uniquement

Points forts de temBoard

  • Outil multi-fonctionnalités
  • Accès centralisés
  • Orienté PostgreSQL uniquement

Conclusion

  • Un système est pérenne s’il est bien supervisé
  • Supervision automatique importante
  • Utiliser le bon outil suivant la problématique

Travaux Pratiques