Monitoring avec Grafana : Guide Complet pour Superviser Votre Infrastructure IT
Maîtrisez Grafana pour superviser votre infrastructure IT : architecture, dashboards, alerting, intégrations Prometheus/Loki/Tempo et bonnes pratiques SRE.
Monitoring avec Grafana : Guide Complet pour Superviser Votre Infrastructure IT
Le monitoring moderne exige de la visibilité en temps réel sur l'ensemble de votre infrastructure. Grafana s'est imposé comme la solution leader pour visualiser métriques, logs et traces dans un écosystème observabilité unifié. Que vous supervisiez un cluster Kubernetes, une stack microservices ou des bases de données, Grafana transforme les données brutes en dashboards exploitables.
Ce guide complet explore l'architecture Grafana, ses intégrations avec Prometheus, Loki et Tempo, et les meilleures pratiques pour mettre en place un monitoring efficace.
Pourquoi Grafana ?
Écosystème Open Source Mature
Grafana Labs (fondé en 2014) développe un stack observabilité complet : Grafana (visualisation), Prometheus (métriques), Loki (logs), Tempo (traces). Cette stack LGTM (Loki-Grafana-Tempo-Mimir) rivalise avec les solutions commerciales (Datadog, New Relic) mais reste entièrement open source et self-hosted.
Visualisation Unifiée
Plutôt que de jongler entre plusieurs outils (Kibana pour logs, Prometheus UI pour métriques, Jaeger pour traces), Grafana centralise tout dans une interface unique. Corrélation immédiate : passer d'un pic de latence (métrique) aux logs de l'erreur, puis au span de trace distribué.
Alerting Intelligent
Le système d'alerting Grafana évalue des règles complexes sur plusieurs datasources, route les notifications selon la sévérité, et supporte les escalations PagerDuty. Plus besoin d'Alertmanager séparé, tout est intégré.
Annotations et Contexte
Marquez vos graphiques avec des annotations pour corréler les métriques avec les événements système : déploiements, incidents, maintenances planifiées. Ces marqueurs visuels facilitent l'analyse post-mortem.
Architecture et Composants
Grafana Core
Le cœur de Grafana est un serveur web écrit en Go qui sert l'interface utilisateur React et expose une API REST. Il stocke sa configuration (dashboards, users, datasources) dans une base de données (SQLite par défaut, ou PostgreSQL/MySQL en production).
Configuration Typique Production
# grafana.ini [server] protocol = https http_port = 3000 domain = grafana.example.com root_url = https://grafana.example.com [database] type = postgres host = postgres.internal:5432 name = grafana user = grafana password = ${DB_PASSWORD} [auth] disable_login_form = false oauth_auto_login = true [auth.generic_oauth] enabled = true name = OAuth allow_sign_up = true client_id = ${OAUTH_CLIENT_ID} client_secret = ${OAUTH_CLIENT_SECRET} scopes = openid profile email auth_url = https://auth.example.com/oauth/authorize token_url = https://auth.example.com/oauth/token [smtp] enabled = true host = smtp.example.com:587 user = grafana@example.com password = ${SMTP_PASSWORD} from_address = grafana@example.com
Data Sources Principales
Prometheus - Le Standard pour les Métriques
Prometheus est la source de données la plus populaire avec Grafana. Il collecte des métriques en pull mode depuis les applications exposant un endpoint /metrics. Grafana utilise PromQL pour interroger ces données.
Métriques typiques monitorées :
- CPU, mémoire, disque, réseau des serveurs
- Latences HTTP (p50, p95, p99)
- Taux d'erreurs 5xx, 4xx
- Queues de messages (RabbitMQ, Kafka)
- Connexions DB actives/idle
Loki - Les Logs Sans Index Loki est le "Prometheus pour les logs". Contrairement à Elasticsearch qui indexe tout le contenu des logs (coûteux), Loki n'indexe que les labels (comme Prometheus). Les logs sont stockés compressés, et la recherche se fait via LogQL.
Cas d'usage :
- Agréger les logs de 100+ microservices
- Corrélation logs ↔ métriques (même labels)
- Recherche d'erreurs sans infrastructure lourde
Tempo - Le Tracing Distribué Tempo stocke les traces OpenTelemetry/Jaeger pour suivre une requête à travers plusieurs services. Grafana peut corréler automatiquement une métrique → logs → traces : vous voyez un pic de latence, cliquez pour voir les logs, puis le span trace complet.
Cloud Providers AWS CloudWatch, Azure Monitor, Google Cloud Monitoring s'intègrent nativement pour monitorer vos ressources cloud : EC2, RDS, Lambda, App Service, Cloud Run.
Cas d'Usage Concrets
Monitoring Infrastructure Kubernetes
Dashboard Cluster Overview Créez une vue d'ensemble de votre cluster Kubernetes avec Prometheus + kube-state-metrics :
Métriques clés :
- Nombre de nodes (Ready vs NotReady)
- CPU/Memory usage du cluster (total et par node)
- Nombre de pods par namespace
- Pods pending, failed, crashlooping
- Persistent volumes usage
Queries PromQL Essentielles
# Nodes Ready sum(kube_node_status_condition{condition="Ready",status="true"}) # CPU usage par node 100 - (avg by (node) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) # Memory usage cluster (sum(node_memory_MemTotal_bytes) - sum(node_memory_MemAvailable_bytes)) / sum(node_memory_MemTotal_bytes) * 100 # Pods par namespace sum by (namespace) (kube_pod_info) # Top 10 pods par CPU topk(10, sum by (pod) (rate(container_cpu_usage_seconds_total[5m])))
Alertes Kubernetes Critiques
# Alertes recommandées pour K8s groups: - name: kubernetes-alerts rules: - alert: NodeNotReady expr: kube_node_status_condition{condition="Ready",status="true"} == 0 for: 5m labels: severity: critical annotations: summary: "Node {{ $labels.node }} is not ready" description: "Node has been NotReady for more than 5 minutes" - alert: PodCrashLooping expr: rate(kube_pod_container_status_restarts_total[15m]) > 0 for: 5m labels: severity: warning annotations: summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping" description: "Pod has restarted {{ $value }} times in the last 15 minutes" - alert: PVCAlmostFull expr: (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) > 0.9 for: 10m labels: severity: warning annotations: summary: "PV {{ $labels.persistentvolumeclaim }} is 90% full" description: "Persistent volume {{ $labels.namespace }}/{{ $labels.persistentvolumeclaim }} is {{ $value | humanizePercentage }} full"
Monitoring Applications Web
Dashboard Application Performance Pour une application web moderne (Node.js, Python, Java), créez un dashboard centré sur l'expérience utilisateur :
Golden Signals (SRE Google)
-
Latency : Temps de réponse HTTP
- p50, p95, p99 par endpoint
- Heatmap de distribution des latences
-
Traffic : Volume de requêtes
- Requests per second (RPS) par endpoint
- Répartition GET/POST/PUT/DELETE
-
Errors : Taux d'erreur
- 5xx (erreurs serveur)
- 4xx (erreurs client)
- Taux d'erreur global (%)
-
Saturation : Utilisation ressources
- CPU, RAM, connexions DB
- Queue length (workers, jobs)
Instrumentation Application Node.js
// Express + prom-client const express = require('express'); const promClient = require('prom-client'); const app = express(); // Créer un registre Prometheus const register = new promClient.Registry(); // Métriques par défaut (CPU, RAM, etc.) promClient.collectDefaultMetrics({ register }); // Métrique custom : histogram de latences HTTP const httpRequestDuration = new promClient.Histogram({ name: 'http_request_duration_seconds', help: 'Duration of HTTP requests in seconds', labelNames: ['method', 'route', 'status_code'], buckets: [0.01, 0.05, 0.1, 0.5, 1, 2, 5] }); register.registerMetric(httpRequestDuration); // Middleware de mesure app.use((req, res, next) => { const start = Date.now(); res.on('finish', () => { const duration = (Date.now() - start) / 1000; httpRequestDuration.labels(req.method, req.route?.path || req.path, res.statusCode).observe(duration); }); next(); }); // Endpoint /metrics pour Prometheus app.get('/metrics', async (req, res) => { res.set('Content-Type', register.contentType); res.end(await register.metrics()); }); app.listen(3000);
Monitoring Bases de Données
PostgreSQL avec pg_exporter Supervisez vos bases PostgreSQL avec des métriques détaillées :
Métriques critiques :
- Connexions actives/idle/max
- Taux de cache hit (>95% recommandé)
- Durée des requêtes lentes (p95, p99)
- Taille des bases/tables
- Réplication lag (réplicas)
- Vacuum/analyze status
Dashboard PostgreSQL Panels essentiels :
- Connexions par état (active, idle, idle in transaction)
- Query duration distribution (heatmap)
- Cache hit ratio (buffer, index)
- Transaction rate (commits, rollbacks)
- Locks par type (AccessShare, RowExclusive, etc.)
Alertes PostgreSQL
- alert: PostgreSQLDown expr: pg_up == 0 for: 1m labels: severity: critical annotations: summary: "PostgreSQL instance {{ $labels.instance }} is down" - alert: PostgreSQLTooManyConnections expr: sum by (instance) (pg_stat_activity_count) > pg_settings_max_connections * 0.8 for: 5m labels: severity: warning annotations: summary: "PostgreSQL {{ $labels.instance }} is using 80% of max connections" - alert: PostgreSQLSlowQueries expr: rate(pg_stat_activity_max_tx_duration{state="active"}[5m]) > 60 for: 5m labels: severity: warning annotations: summary: "PostgreSQL {{ $labels.instance }} has slow queries (>60s)"
Dashboards Avancés
Variables de Dashboard
Créez des dashboards dynamiques avec des variables pour filtrer par environnement, région, service :
# Variable: Environment
Type: Query
Query: label_values(up, environment)
Multi-value: true
Regex: .*
# Variable: Namespace (K8s)
Type: Query
Query: label_values(kube_pod_info, namespace)
All value: .*
# Variable: Instance
Type: Query
Query: label_values(up{environment="$environment"}, instance)
Utilisez les variables dans vos queries :
rate(http_requests_total{environment=~"$environment", instance=~"$instance"}[5m])
Transformations de Données
Grafana offre des transformations puissantes pour manipuler les données avant l'affichage :
Join by Field Combinez plusieurs queries par un champ commun :
Query A: node_cpu_usage{instance="server1"}
Query B: node_memory_usage{instance="server1"}
Transform: Join by field "instance"
Result: Single row with CPU + Memory for each server
Calculate Field Créez des champs calculés :
Query A: http_requests_total (counter)
Query B: http_requests_errors (counter)
Transformation:
- Add field from calculation
- Field: error_rate
- Calculation: (A / B) * 100
Alerting Avancé
Alert Rules Complexes
Composite Conditions Combinez plusieurs conditions :
(avg(cpu_usage) > 80 AND avg(memory_usage) > 90)
OR
(disk_space_free < 10%)
Alert Contact Points Configurez plusieurs canaux de notification :
- PagerDuty : Alertes critiques (réveil astreinte 24/7)
- Slack : Warnings dans #alerts
- Email : Notifications info pour l'équipe ops
- Webhook : Intégration custom (ticketing)
Notification Policies (Routing)
# Routage sophistiqué - match: severity: critical contact_point: pagerduty continue: true - match: severity: warning team: backend contact_point: slack-backend group_wait: 30s group_interval: 5m - match: severity: info contact_point: email group_wait: 5m
Silences et Maintenance Windows Créez des silences pour éviter les fausses alertes pendant les maintenances :
# Silence pendant déploiement
Matcher: environment = production AND service = api
Duration: 30 minutes
Comment: "Déploiement v2.4.0"
Plugins et Extensions
Plugins Populaires
- Worldmap Panel : Visualiser les métriques sur une carte mondiale
- Pie Chart Panel : Graphiques en camembert pour répartitions
- Boom Table : Tables avec thresholds colorés
- FlowCharting : Diagrammes de flux interactifs
- Statusmap Panel : Heatmap de statuts sur timeline
Installation Plugin
# Via grafana-cli grafana-cli plugins install grafana-worldmap-panel # Ou dans Dockerfile RUN grafana-cli plugins install grafana-piechart-panel
Data Sources Additionnelles
- MySQL/PostgreSQL : Requêtes SQL directes
- InfluxDB : Time series DB alternatif
- Elasticsearch : Logs et recherche full-text
- CloudWatch : AWS metrics
- Azure Monitor : Azure metrics
- Google Cloud Monitoring : GCP metrics
Provisioning Automatisé
Automatisez le déploiement de Grafana avec du provisioning as code :
Datasources
# provisioning/datasources/prometheus.yml apiVersion: 1 datasources: - name: Prometheus type: prometheus access: proxy url: http://prometheus:9090 isDefault: true editable: false jsonData: timeInterval: 15s
Dashboards
# provisioning/dashboards/dashboards.yml apiVersion: 1 providers: - name: 'default' orgId: 1 folder: 'Infrastructure' type: file disableDeletion: true updateIntervalSeconds: 30 options: path: /etc/grafana/dashboards
Alerting
# provisioning/alerting/rules.yml groups: - name: HighCPU interval: 1m rules: - uid: cpu-high title: High CPU Usage condition: A data: - refId: A queryType: prometheus model: expr: avg(cpu_usage) > 80 for: 5m annotations: summary: "CPU usage above 80%"
Best Practices
Organisation des Dashboards
Folder Structure
📁 Infrastructure
├── 📊 Kubernetes Cluster Overview
├── 📊 Node Exporter Detailed
└── 📊 Network Monitoring
📁 Applications
├── 📊 API Gateway
├── 📊 Microservices Overview
└── 📊 Application Performance
📁 Databases
├── 📊 PostgreSQL
├── 📊 Redis
└── 📊 MongoDB
📁 Business Metrics
├── 📊 User Signups
├── 📊 Revenue Dashboard
└── 📊 Conversion Funnel
Dashboard Naming Convention
[Category] - [Target] - [Type]
Infrastructure - Kubernetes - Overview
Application - API - Performance
Database - PostgreSQL - Production
Performance et Optimisation
Query Optimization
- Évitez les queries trop larges (sans filtres)
- Utilisez des time ranges raisonnables (pas 1 an de données)
- Préférez
rate()àincrease()pour le calcul de taux - Utilisez
sum(),avg()pour agréger avant d'afficher
Caching et Refresh
Dashboard settings:
- Refresh: 30s (pas 1s, trop de charge)
- Cache timeout: 1m
- Max data points: 1000 (pas plus pour fluidité)
Réduire la Charge Prometheus
- Scrape interval raisonnable (15s-30s)
- Retention adaptée (15-30 jours max pour HA)
- Remote write vers Thanos/Cortex pour long-term storage
- Utiliser recording rules pour queries lourdes
Sécurité
HTTPS Obligatoire
[server] protocol = https cert_file = /etc/grafana/ssl/cert.pem cert_key = /etc/grafana/ssl/key.pem
Authentification
- OAuth2/OIDC (Google, GitHub, Okta)
- LDAP/Active Directory pour entreprises
- Désactiver anonymous access en production
RBAC (Role-Based Access Control)
Roles:
- Admin: Tout accès (gestion users, datasources, dashboards)
- Editor: Créer/éditer dashboards, pas d'admin
- Viewer: Lecture seule (pour la majorité des users)
API Keys et Service Accounts Pour les intégrations externes (CI/CD, scripts) :
# Créer un service account avec rôle Viewer curl -X POST http://grafana:3000/api/serviceaccounts \ -H "Authorization: Bearer $ADMIN_TOKEN" \ -d '{"name": "monitoring-bot", "role": "Viewer"}'
Backup et Disaster Recovery
Backup des Dashboards
# Export tous les dashboards via API for uid in $(curl -s http://grafana:3000/api/search | jq -r '.[] | select(.type=="dash-db") | .uid'); do curl -s http://grafana:3000/api/dashboards/uid/$uid | jq .dashboard > $uid.json done
Database Backup
# PostgreSQL pg_dump -h postgres -U grafana grafana > grafana_backup_$(date +%Y%m%d).sql # Restore psql -h postgres -U grafana grafana < grafana_backup_20240115.sql
Infrastructure as Code Stockez tout dans Git :
- Provisioning configs (datasources, dashboards, alerting)
- Dashboard JSON exports
- Grafana.ini configuration
- Docker Compose / Kubernetes manifests
Conclusion
Grafana est bien plus qu'un simple outil de visualisation : c'est le hub central de votre observabilité. En combinant métriques (Prometheus), logs (Loki) et traces (Tempo), vous obtenez une vision complète de votre système.
Les points clés à retenir :
- Architecture unifiée : Corrélation métriques ↔ logs ↔ traces dans une seule interface
- Alerting intelligent : Routing sophistiqué, escalations, silences programmés
- Extensibilité : Plugins, API, provisioning automatisé
- Open source mature : Communauté active, mises à jour fréquentes, support entreprise disponible
Pour démarrer :
- Déployez la stack LGTM (Loki-Grafana-Tempo-Mimir) en 5 minutes avec Docker Compose
- Configurez Prometheus pour scraper vos applications
- Importez des dashboards pré-faits depuis grafana.com (ID 1860 pour Node Exporter, 6417 pour Kubernetes)
- Configurez les alertes critiques (services down, CPU/RAM high)
- Itérez : ajoutez des métriques custom, créez des dashboards business
Le monitoring n'est jamais "terminé", c'est un processus continu d'amélioration. Commencez simple, mesurez ce qui compte, et affinez progressivement.
Besoin d'aide pour mettre en place Grafana ? Contactez-nous pour un audit de votre observabilité et un accompagnement personnalisé.