Grafana sur Ubuntu : installation APT et configuration initiale

Table des matières :

1. Cadrer l’installation : Grafana sur Ubuntu via APT, sans bricolage
2. Ajouter le dépôt APT Grafana proprement (keyring) et installer Grafana OSS
3. Démarrage systemd et configuration initiale : ce que Grafana ne fait pas pour vous
4. Exposer Grafana correctement : reverse proxy, WebSocket, et TLS sans surprise
5. Premier run utile : datasources, dashboards, et alerting (sans tomber dans l’usine à gaz)
6. Provisioning “as code” : arrêter de cliquer, versionner, et rendre la supervision reproductible
7. Plugins, mises à jour APT, sauvegardes : la partie ingrate qui fait la différence

Cadrer l’installation : Grafana sur Ubuntu via APT, sans bricolage

Installer Grafana sur Ubuntu en passant par APT n’est pas “juste un apt install”. En production, la partie qui fait mal n’est pas l’installation, mais la configuration initiale : service systemd, exposition réseau, reverse proxy, persistance, et surtout le durcissement des paramètres par défaut. Les exemples ci-dessous sont testés sur Ubuntu 24.04 LTS (mêmes commandes sur 22.04 LTS), avec Grafana OSS installé depuis le dépôt officiel Grafana.

Pré-requis minimaux : accès root (ou sudo), résolution DNS correcte, et un pare-feu cohérent. Grafana écoute par défaut sur TCP/3000 et, selon la configuration, peut écouter sur toutes les interfaces si vous ne le contraignez pas. Exposer 3000 directement sur Internet est un piège classique : vous perdez un TLS géré proprement, vous gérez mal les en-têtes X-Forwarded-*, et vous ouvrez la porte à des erreurs de configuration (root_url, cookies, SameSite, CSP, etc.). En pratique, on place Grafana derrière Nginx ou HAProxy (cf. l’article interne sur le déploiement : HAProxy 3.2 : déploiement systemd, configuration frontend/backend, ACL).

Avant de taper des commandes, prenez 5 minutes pour cadrer les décisions “non-négociables” (ça évite la reconfig en urgence après l’ouverture aux utilisateurs) :

• URL d’accès : sous-domaine dédié (grafana.exemple.tld) plutôt qu’un sous-chemin.
• Qui y accède : VPN/SSO uniquement, ou Internet + MFA ?
• Où tourne la base Grafana : SQLite (POC), ou PostgreSQL/MySQL (prod, HA, backups).
• Port d’écoute : localhost uniquement (recommandé si reverse proxy local), ou IP privée.
• Rétention et périmètre : dashboards “opérationnels” d’abord, puis enrichissements.

Côté stockage, Grafana démarre en SQLite. Cela fonctionne pour un POC ou un petit service, mais c’est une mauvaise habitude en environnement avec sauvegardes strictes, volumes éphémères, ou montée en charge (verrouillages, I/O, corruption plus pénible à diagnostiquer). Si vous êtes dans une architecture e-commerce, vous avez déjà une discipline de sauvegarde (MySQL, configs, secrets). Appliquez la même rigueur à Grafana : base PostgreSQL dédiée ou, au minimum, sauvegarde contrôlée du fichier SQLite.

Un point souvent oublié (et très concret en alerting) : la synchronisation NTP. Des horloges décalées entre serveurs (Grafana, Prometheus, exporters) produisent des graphes “en dents de scie” et des alertes incohérentes. Sur Ubuntu, assurez-vous que systemd-timesyncd ou chrony est en place et stable.

Documentation officielle : https://grafana.com/docs/grafana/latest/

Ajouter le dépôt APT Grafana proprement (keyring) et installer Grafana OSS

L’installation “propre” en 2026 passe par un keyring dans /etc/apt/keyrings (on évite l’ancien apt-key, déprécié). On commence par s’assurer d’avoir les outils nécessaires :

sudo apt update
sudo apt install -y ca-certificates curl gnupg

On importe ensuite la clé GPG du dépôt Grafana et on crée le fichier sources.list.d. Les URL officielles sont documentées ici : https://grafana.com/docs/grafana/latest/setup-grafana/installation/debian/

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://apt.grafana.com/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/grafana.gpg
sudo chmod a+r /etc/apt/keyrings/grafana.gpg

echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | \
  sudo tee /etc/apt/sources.list.d/grafana.list > /dev/null

sudo apt update
sudo apt install -y grafana

Deux vérifications rapides (qui évitent les surprises “ça a installé un vieux paquet depuis un miroir”) :

apt-cache policy grafana
dpkg -l | grep -E '^ii\s+grafana\s'

En environnement contrôlé, vous ne laissez pas APT “prendre la dernière version” sans garde-fou. Deux options rationnelles : (1) pinning APT (priorité de version), ou (2) gel de version (apt-mark hold grafana) avec une fenêtre de patching planifiée. Grafana bouge vite (front, auth, alerting, plugins) et les régressions arrivent ; votre CI/CD et vos runbooks de supervision doivent prévoir un rollback (snapshot VM, image, ou paquet précédent dans un repo interne).

Exemple minimal de pinning (à adapter à votre politique : l’idée est de contrôler la source et la priorité). Créez /etc/apt/preferences.d/grafana.pref :

Package: grafana
Pin: origin apt.grafana.com
Pin-Priority: 700

Puis contrôlez l’origine effectivement utilisée :

apt-cache policy grafana | sed -n '1,120p'

Enfin, notez qu’il existe aussi un paquet Enterprise (grafana-enterprise) dans l’écosystème Grafana ; ici on reste sur grafana (OSS) comme indiqué.

Démarrage systemd et configuration initiale : ce que Grafana ne fait pas pour vous

Une fois installé, Grafana fournit un service systemd grafana-server. Activation et démarrage :

sudo systemctl daemon-reload
sudo systemctl enable --now grafana-server
sudo systemctl status grafana-server --no-pager

Avant même d’ouvrir le navigateur, validez que le process répond localement (ça distingue rapidement un problème réseau d’un problème applicatif) :

curl -sSf http://127.0.0.1:3000/api/health

Vous devez obtenir un JSON indiquant typiquement database: ok et une version.

Le cœur de la configuration est dans /etc/grafana/grafana.ini (et des overrides possibles via variables d’environnement). Trois points à traiter immédiatement : (1) admin password (par défaut, c’est souvent admin/admin selon les modes d’installation), (2) root_url / domain si vous êtes derrière un reverse proxy, (3) désactivation des inscriptions et du mode anonyme si ce n’est pas volontaire.

• Ne pas exposer Grafana directement : faites-le écouter sur 127.0.0.1 si le reverse proxy est sur la même VM.
• Centraliser les secrets (mot de passe admin initial, tokens) dans un mécanisme cohérent : fichier d’environnement protégé, vault, ou outil de déploiement.

Exemple minimal (à adapter) dans /etc/grafana/grafana.ini :

[server]
domain = grafana.exemple.tld
root_url = https://grafana.exemple.tld/
; écoute uniquement en local si Nginx/HAProxy tourne sur la même machine
http_addr = 127.0.0.1
http_port = 3000
; si vous servez Grafana sous un sous-chemin, activez serve_from_sub_path
; serve_from_sub_path = true

[security]
admin_user = admin
; changez le mot de passe via l’UI puis stockez le secret en gestion de config
; (ou via env GF_SECURITY_ADMIN_PASSWORD)
disable_gravatar = true
cookie_secure = true
cookie_samesite = lax

[users]
allow_sign_up = false
allow_org_create = false

[auth.anonymous]
enabled = false

Pour initialiser/forcer le mot de passe admin sans passer par l’UI, utilisez une variable d’environnement (utile en bootstrap automatisé). Sur Ubuntu, le paquet s’appuie classiquement sur un fichier d’environnement ; selon votre installation, vérifiez le service :

systemctl cat grafana-server | sed -n '1,200p'

Vous pouvez ensuite mettre un override systemd (pratique si vous gérez les secrets via un fichier root-only) :

sudo systemctl edit grafana-server

[Service]
Environment="GF_SECURITY_ADMIN_PASSWORD=change-moi-proprement"

Puis :

sudo systemctl restart grafana-server

Sur le plan OS, vous allez tôt ou tard tomber sur des limites de fichiers ouverts, surtout si vous activez des datasources qui multiplient les connexions (Prometheus + Loki + MySQL/PostgreSQL + plugins). Le problème est connu côté stack web aussi : voir PrestaShop 9 : corriger l’erreur « too many open files » pour la méthode de diagnostic et l’approche systemd. Grafana se règle pareil : override systemd avec LimitNOFILE.

sudo systemctl edit grafana-server

[Service]
LimitNOFILE=65536

Puis :

sudo systemctl restart grafana-server

Enfin, gardez un réflexe simple : quand “Grafana ne marche pas”, commencez par les logs du service (avant de toucher 10 paramètres au hasard) :

journalctl -u grafana-server -n 200 --no-pager

Selon la config des chemins, vous pouvez aussi avoir un log applicatif dans /var/log/grafana/.

Exposer Grafana correctement : reverse proxy, WebSocket, et TLS sans surprise

Mettre Grafana derrière un reverse proxy n’est pas “optionnel”. L’UI, Grafana Live (stream), et certaines intégrations utilisent des connexions persistantes (WebSocket/HTTP2 selon les cas). Si vous ratez les headers, vous aurez des symptômes classiques : redirections en HTTP, boucles de login, cookies invalides, ou erreurs CSP.

Avant de configurer le proxy, clarifiez les flux réseau attendus (utile en contexte “landing zone”, ou quand vous devez justifier l’ouverture de ports) :

Flux	Source → Destination	Port	Recommandation
Utilisateurs	Internet/VPN → Reverse proxy	443	Ouvert (selon politique)
Reverse proxy → Grafana	Nginx/HAProxy → 127.0.0.1:3000	3000	Local uniquement
Grafana → Datasources	Grafana → Prometheus/Loki/DB	9090/3100/5432…	Privé/VPN, filtré

Avec Nginx, un vhost minimal ressemble à ça (TLS non inclus ici) :

server {
  listen 80;
  server_name grafana.exemple.tld;

  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # évite certains timeouts sur connexions longues (dashboards, live, etc.)
    proxy_read_timeout 3600s;

    proxy_pass http://127.0.0.1:3000;
  }
}

Deux détails qui évitent des bugs “bizarres” :

• Assurez-vous que root_url côté Grafana correspond exactement à l’URL publique (schéma https, bon hostname, slash final cohérent).
• Si vous faites de la terminaison TLS en amont (load balancer, HAProxy), X-Forwarded-Proto doit refléter https, sinon Grafana génère des redirections en http.

Pour TLS, le choix le plus simple côté Ubuntu est Let’s Encrypt via certbot (docs officielles : https://certbot.eff.org/). En entreprise, vous terminerez plutôt TLS sur un load balancer (HAProxy, NLB cloud, appliance) et vous imposerez des politiques HSTS. Si vous êtes déjà dans une démarche d’architecture réseau (segmentation, hub-and-spoke, HA firewall), vous voulez que Grafana respecte le design, pas l’inverse ; l’article Landing zone OVHcloud : architecture hub-and-spoke avec OPNsense HA donne un cadre réaliste pour éviter les “serveurs de monitoring” exposés n’importe comment.

En complément, côté pare-feu (exemple simple avec UFW), l’idée est de n’exposer que 80/443 au reverse proxy et de laisser 3000 inaccessible depuis l’extérieur :

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw deny 3000/tcp
sudo ufw status verbose

Enfin, si vous servez Grafana sous un sous-chemin (ex: https://exemple.tld/grafana/), vous devez aligner trois choses : root_url, serve_from_sub_path=true, et la config du reverse proxy (rewrite + proxy_pass cohérent). C’est typiquement le genre de détail qui fait perdre une heure pour une erreur de slash final. Si vous avez le choix, préférez un sous-domaine dédié : moins de pièges, moins de subtilités CSP, et cookies plus propres.

Premier run utile : datasources, dashboards, et alerting (sans tomber dans l’usine à gaz)

Une “configuration initiale” Grafana qui sert à quelque chose consiste à brancher des sources de vérité exploitables, puis à poser des dashboards qui répondent à des questions opérationnelles. Sur une stack PrestaShop, vous voulez au minimum : (1) métriques système (CPU/RAM/disk/IO), (2) métriques HTTP (latences, codes, erreurs), (3) métriques PHP-FPM et MySQL, (4) métriques cache/proxy si vous avez Varnish/Redis. Pour le cadrage et les KPI pertinents, l’article interne PrestaShop performance : monitoring, tests de charge et runbooks soldes est directement actionnable.

Le trio fréquent en 2026 : Prometheus pour les métriques, Loki pour les logs, Grafana en UI/alerting. La définition Prometheus est claire :

« Prometheus implements a highly dimensional data model. Time series are identified by a metric name and a set of key-value pairs. » — Documentation Prometheus
Source : https://prometheus.io/docs/concepts/data_model/

Concrètement, dans Grafana : Connections → Data sources → Add data source. Ajoutez Prometheus (URL interne type http://prometheus:9090 ou via VPN), puis importez un dashboard Node Exporter (ou équivalent) pour valider la chaîne. La validation ne se fait pas “à l’œil”, mais sur un check simple : une requête up doit retourner 1 pour vos targets, et vos panels doivent afficher des séries avec un pas cohérent (scrape 15s/30s typiquement).

Mini-scénario (utile pour éviter le “dashboard vitrine”) : vous préparez une opération commerciale type soldes. Vos questions avant l’incident sont connues, donc vos dashboards doivent y répondre en 30 secondes :

• La latence p95 HTTP augmente-t-elle (et sur quelles routes) ?
• Les 5xx montent-ils côté Nginx, PHP-FPM, ou applicatif ?
• La DB est-elle en saturation CPU, I/O, locks, ou connexions ?
• Le cache (Redis/Varnish) est-il efficace ou bypassé ?

Exemples d’alertes “orientées impact” (à adapter à vos SLO et à votre trafic) :

Signal	Exemple d’intention	Pourquoi c’est utile
Taux de 5xx	“> 1% sur 5 minutes”	Indique une dégradation client immédiate
Latence p95	“p95 > 800 ms sur 10 minutes”	Détecte un ralentissement réel (pas un pic isolé)
Saturation DB	“connexions proches du max / locks”	Souvent cause racine avant les 5xx
Disk plein	“< 10% free”	Évite la panne brutale (logs, DB, spool)
FD usage	“limite proche”	Précurseur d’incidents réseau/DB
Targets down	“up==0”	Détecte rupture de collecte / panne

Pour MySQL (si vous observez les symptômes côté PrestaShop), branchez soit une datasource MySQL directe (utile pour requêtes ad hoc), soit — mieux — un exporter + Prometheus afin d’éviter de transformer Grafana en client SQL long-lived. Si vous faites déjà de l’optimisation MySQL, vous savez que les mauvaises requêtes tuent des instances ; la page Index MySQL : optimiser WHERE, JOIN et ORDER BY avec EXPLAIN rappelle pourquoi il faut garder une discipline sur les accès.

Dernier point “qui coûte cher” : la cardinalité. Trop de labels (ex: user_id, cart_id, URL complètes, IDs de commande) font exploser Prometheus et rendent les requêtes PromQL lentes ; Grafana n’est alors que le révélateur. Gardez des labels stables, agrégés, et pensés pour des questions opérationnelles.

Provisioning “as code” : arrêter de cliquer, versionner, et rendre la supervision reproductible

Grafana sait provisionner datasources, dashboards et alerting via des fichiers dans /etc/grafana/provisioning/. C’est indispensable dès que vous avez plus d’un environnement (dev/staging/prod) ou plus d’un nœud Grafana. Le clic dans l’UI ne laisse pas de trace, et vous finissez avec des divergences impossibles à auditer.

Exemple de provisioning datasource Prometheus : /etc/grafana/provisioning/datasources/prometheus.yaml

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://127.0.0.1:9090
    isDefault: true
    editable: false

Deux détails pratiques pour que le provisioning reste “sans surprise” :

• Droits et propriétaire : les fichiers doivent être lisibles par le service Grafana (souvent l’utilisateur grafana). Un chmod trop restrictif ou un répertoire mal possédé suffit à faire “disparaître” une datasource au restart.
• Secrets hors Git : si vous provisionnez des datasources qui nécessitent un mot de passe/token, privilégiez l’injection via variables d’environnement (ou un outil de secrets), plutôt que de committer des credentials dans un YAML.

Pour les dashboards, vous provisionnez un répertoire (ex: /var/lib/grafana/dashboards) et vous y déployez des JSON versionnés. Ce modèle colle très bien avec une démarche CI : build d’artefact, déploiement, puis smoke test. Si vous êtes déjà dans cette logique pour vos builds e-commerce, transposez-la : Intégration continue PrestaShop : BuildKit, GitHub Actions et build reproductible donne la méthode pour éliminer les “ça marche sur mon serveur”.

Dernier point : l’alerting. Grafana (Unified Alerting) fonctionne, mais il ne faut pas le confondre avec une stratégie d’astreinte. Définissez des alertes orientées impact (latence p95, taux 5xx, saturation DB, file descriptor usage), pas “CPU > 80%” en permanence. Et documentez les runbooks associés : une alerte sans action claire = bruit. Pour une démarche structurée, repartez d’un audit performance reproductible : Audit performance PrestaShop : méthode en 6 étapes reproductibles.

Plugins, mises à jour APT, sauvegardes : la partie ingrate qui fait la différence

Les plugins Grafana (datasources, panels, apps) sont un vecteur de risques : surface d’attaque front, dépendances, et compatibilité de version. Installez-les via grafana-cli seulement si vous maîtrisez le cycle de mise à jour et la validation. Exemple :

sudo grafana-cli plugins list-remote
sudo grafana-cli plugins install grafana-clock-panel
sudo systemctl restart grafana-server

Point sécurité très concret : évitez de charger des plugins non maîtrisés/“exotiques”, et ne contournez pas les mécanismes de sécurité sans raison. Par exemple, le paramètre allow_loading_unsigned_plugins existe, mais l’utiliser “pour tester vite” en prod est une dette de sécurité (et un futur incident).

Pour les mises à jour, vous avez deux stratégies rationnelles : (1) patching régulier avec validation en staging, (2) pinning et fenêtre de maintenance plus large. Dans les deux cas, vous devez surveiller les correctifs de sécurité (Grafana publie régulièrement des mises à jour). Sur Ubuntu, APT + unattended-upgrades peut être utile, mais pas sans tests : une mise à jour Grafana peut casser un plugin ou une API. Si vous avez une culture sécurité déjà en place côté PrestaShop (WAF, journalisation, moindre privilège), alignez Grafana : Sécurité PrestaShop : protéger API backoffice, WAF et journalisation SIEM et Automatisation PrestaShop : sécurité RGPD, moindre privilège et journaux d’audit donnent les patterns (logs, audit trail, séparation des rôles).

Côté exploitation, ajoutez une routine simple “avant/après upgrade” :

• export/snapshot VM ou sauvegarde DB + /etc/grafana/ + plugins
• upgrade en staging
• ouverture des dashboards critiques (temps de rendu, panels vides)
• vérification alerting (règles actives, notifications)
• seulement ensuite upgrade en prod

La sauvegarde dépend du backend de Grafana :

• SQLite : sauvegarde du fichier (souvent /var/lib/grafana/grafana.db) après arrêt du service pour éviter un snapshot incohérent.
• PostgreSQL/MySQL : dump standard (pg_dump/mysqldump) + sauvegarde des répertoires provisioning/, plugins/ et de la conf grafana.ini.

Ajoutez un contrôle simple : vérifier que votre provisioning est réellement la “source de vérité”. Sinon, vous sauvegardez “un disque” sans savoir si vous pourrez restaurer fonctionnellement. Deux commandes utiles en vérification post-restauration :

sudo systemctl status grafana-server --no-pager
curl -sSf http://127.0.0.1:3000/api/health

Enfin, surveillez aussi Grafana lui-même : logs systemd (journalctl -u grafana-server), consommation mémoire, et latence d’accès à la base Grafana. Si vos utilisateurs voient des dashboards qui mettent 10 secondes à s’afficher, le problème est souvent côté datasource (requêtes PromQL trop lourdes, cardinalité explosée, backends sous-dimensionnés) plutôt que Grafana. Les mêmes réflexes que sur une boutique s’appliquent : isoler la cause, mesurer, corriger — et ne pas confondre “observabilité” avec “collection compulsive de métriques”.