Le bouclier de Prometheus pour VPN : comment nous avons fait collaborer Prometheus et Grafana en 2026

Pourquoi surveiller son VPN en 2026 n’est pas un luxe, mais une vraie armure

Les dangers de l’invisibilité des tunnels

Quand un VPN tourne dans son coin, on découvre les problèmes au pire moment possible. Annulation d’une réunion, interruption de la facturation, perte de télémétrie des nœuds distants… En 2026, le trafic passe de plus en plus par des tunnels chiffrés, donc réagir vite en cas de panne est crucial. On ne peut pas se permettre de garder des « boîtes noires ». Il faut des métriques, des tableaux de bord et des alertes qui se déclenchent avant que les utilisateurs n’écrivent dans le chat « rien ne s’ouvre ». Et oui, c’est faisable.

Un VPN sans surveillance, c’est comme une voiture sans tableau de bord. On roule tant que ça avance. Mais c’est une voie sans retour. Nous intégrons Prometheus et Grafana pour voir non seulement la vitesse, mais aussi la température du moteur, le niveau d’essence, la pression des pneus. Oui, c’est une métaphore, mais parfaitement adaptée. Les métriques des tunnels sont notre langage d’alerte précoce.

Quels KPI et SLO sont vraiment efficaces

On aime les chiffres qui ont du sens. Pour un VPN, ça veut dire : disponibilité des tunnels, latence moyenne et p95 du handshake, taux de succès des connexions, erreurs de chiffrement, bande passante dans les deux sens, nombre de pairs et clients actifs, temps de rotation des clés, charge CPU liée à la cryptographie. Pour les SLO ? Par exemple, 99,9 % de disponibilité et moins de 0,1 % de tentatives de connexion erronées sur 28 jours. Simple, mesurable et utile.

Les métriques ne doivent pas être là « pour faire joli ». Elles servent à prendre des décisions : augmenter les limites, ajouter des nœuds, ajuster la fréquence de rotation des clés, basculer une partie du trafic vers une région de secours. Une fois les SLO définis, les débats d’ingénieurs du type « tout va bien, non ? » disparaissent. Et avec eux, les réunions nocturnes inutiles.

Ce qui a changé en 2026

Trois grandes évolutions. D’abord, les histogrammes natifs dans Prometheus sont devenus la norme pour les métriques réseau, ce qui simplifie le stockage et l’analyse des quantiles. Ensuite, les approches eBPF offrent une observabilité à faible overhead et une visibilité fine jusque sur les flux et paquets. Enfin, OpenTelemetry et Prometheus cohabitent harmonieusement à travers OTEL Collector, remote_write et export au format unifié. Ce ne sont plus des tendances, mais du quotidien dans les équipes matures.

Architecture : Prometheus et Grafana pour VPN sans douleur

Schéma de base et rôles des composants

Le classique : sur les passerelles VPN tournent des exportateurs, Prometheus collecte les métriques en mode pull, les stocke et pousse vers un stockage long terme via remote_write, Grafana crée les tableaux de bord et gère les alertes, Alertmanager filtre le bruit et route les notifications. Un maximum de contrôle avec un minimum de magie. Plus c’est simple, plus c’est fiable.

On ajoute Node Exporter sur chaque passerelle pour surveiller CPU, disques, mémoire et interfaces réseau. Pour diagnostiquer la couche liaison, on maintient Blackbox Exporter qui teste la disponibilité des ports VPN depuis l’extérieur. Et pour un réseau avancé, on déploie des agents eBPF basés sur Cilium ou équivalents afin de détecter les goulots d’étranglement au niveau des paquets. Pas de surcharge, mais pas dans le noir non plus.

Flux de données, stockage et rétention

Les métriques VPN sont souvent très fréquentes : connexions qui montent et descendent, rotation des clés, changements de pairs. On fixe des intervalles de scraping de 5 à 15 secondes pour les indicateurs critiques, et de 30 à 60 secondes pour le fond. La rétention locale dans Prometheus est courte, environ 15 jours, tandis que les historiques partent vers un stockage distant ou un service TSDB compatible via remote_write. La règle est simple : rapidité locale, profondeur historique distante.

Par où commencer ? Par une liste : définir les métriques essentielles, décrire les SLO, choisir les rétentions, activer l’échantillonnage pour les métriques coûteuses. Et surtout, répartir les scrapes par jobs — cela facilite l’ajustement des fréquences et timeouts selon protocoles et zones.

Choisir les métriques et fréquences de collecte

Le principe est le suivant : les métriques symptômes sont collectées plus souvent, les causes moins. Par exemple, nombre de pairs actifs, erreurs de handshake et latences des entêtes toutes les 5-10 secondes. La cryptographie profonde et distribution des tailles de paquets toutes les 30-60 secondes. En 2026, on évite la surenchère : la haute fréquence est réservée aux métriques qui déclenchent vraiment des alertes.

Un mot sur la cardinalité : les labels par client peuvent exploser la base TSDB. Prudence donc. On agrège souvent au niveau du nœud ou pair et on active l’export détaillé par client en fenêtres courtes pour les enquêtes. Cela économise budget et ressources Prometheus.

Export métriques VPN : OpenVPN, WireGuard, IPsec

OpenVPN : un vétéran fiable

OpenVPN équipe des milliers d’entreprises. Pour le surveiller, on utilise des exportateurs dédiés qui lisent l’interface management ou les fichiers d’état. Nous collectons : clients actifs, octets entrants/sortants, durée des sessions, erreurs de renegociation, redémarrages du démon. Exemple : un scrappeur lancé près du processus, qui écoute le port de gestion en entrée et expose les métriques au format pratique en sortie.

Une ligne de commande modèle et minimaliste : openvpn_exporter --management.addr 127.0.0.1:7505 --management.auth disabled --web.listen-address :9176. Prometheus vole ensuite les métriques sur le port :9176. Simple et clair.

WireGuard : moderne, rapide et efficace

WireGuard est devenu la référence quand compte la simplicité et la performance. Les métriques types sont : wg_peers, handshake_seconds, bytes_sent, bytes_received, allowed_ips, endpoint. L’exportateur puise dans wg show et interfaces système. On mesure non seulement nombre de pairs et octets, mais aussi la latence du dernier handshake, excellente pour repérer les connexions à moitié mortes.

Commande de lancement type : wireguard_exporter --web.listen-address :9586 --include-interfaces wg0,wg1 --resolve-endpoints true. Au final, des métriques propres avec labels d’interfaces et de pairs, parfaites pour alertes et tableaux.

IPsec : strongSwan et Libreswan sans complication

IPsec reste omniprésent en entreprise. On exporte via l’API Vici de strongSwan ou en analysant logs et scripts pour Libreswan. Critique : nombre de SA établis, redémarrages, erreurs d’authentification, durée de vie des clés, événements rekey, vérifications DPD. On maintient un job dédié avec labels décrivant les tunnels site-à-site — pratique pour filtrer sous Grafana.

Si Vici est fermé, on utilise un collecteur léger qui parse ipsec statusall et génère des métriques à faible cardinalité. Pas idéal, mais fonctionnel. L’essentiel : garder un format stable et tester le parser à chaque mise à jour.

Approches universelles : Node Exporter et Blackbox

Node Exporter sauve la mise quand l’exportateur spécifique est indisponible : on voit la charge CPU crypto, les overflows de queues, pertes réseau, saturations des interfaces. Blackbox Exporter est notre éclaireur : test TCP, port UDP via proxy, vérification TLS, temps de réponse. Un pare-feu d’observabilité minimum en une heure, pour dormir un peu plus tranquille.

Quelques astuces : n’activez pas tous les collecteurs Node Exporter par défaut, filtrez les métriques bruyantes ; pour Blackbox, maintenez des modules UDP/TCP/TLS distincts et taguez-les par région et type de sondage.

Configuration Prometheus : du scrape à la sécurité

Exemples de scrape_configs

Voici des exemples compacts sans retours à la ligne. Exemple WireGuard : scrape_configs: - job_name: wireguard scrape_interval: 10s metrics_path: /metrics static_configs: - targets: ["vpn-gw-1:9586","vpn-gw-2:9586"] labels: role: "vpn" proto: "wg". Exemple OpenVPN : - job_name: openvpn scrape_interval: 15s static_configs: - targets: ["vpn-gw-1:9176"] labels: role: "vpn" proto: "ovpn". Exemple IPsec : - job_name: ipsec scrape_interval: 30s static_configs: - targets: ["vpn-gw-1:9905"] labels: role: "vpn" proto: "ipsec".

Test Blackbox TCP port : - job_name: vpn-blackbox metrics_path: /probe params: module: ["tcp_connect"] static_configs: - targets: ["vpn.example.internal:51820"] relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: "blackbox:9115". Le principe est clair : on teste la connexion, obtenant temps de réponse et code.

Relabeling, découverte de services et labels

De beaux labels, c’est déjà la moitié du travail. On transforme instance en nom lisible, ajoute les labels environment, region, proto, role, cluster. Le relabeling élimine le superflu : on supprime client_id et les labels très cardinales. En Kubernetes, on filtre sur annotations pour détecter automatiquement les exportateurs sur DaemonSet. En bare-metal, on fabrique file_sd_configs depuis CMDB ou Terraform — tout est déclaratif, sans clic manuel.

Exemple de relabel pour instance : - action: replace source_labels: [__meta_kubernetes_pod_node_name] target_label: instance. Et pour protocole : - action: replace source_labels: [__meta_kubernetes_pod_label_proto] target_label: proto. Rien de magique, mais ça fait gagner des heures au montage des dashboards.

Remote_write, fédération et montée en charge

Quand le VPN grossit, on évite de saturer Prometheus local avec l’historique. On active remote_write vers un backend long terme. Config simplifiée : remote_write: - url: https://tsdb.internal/api/v1/write queue_config: capacity: 200 max_shards: 10. On utilise la fédération pour résumer cross-régions : agrégats de latence p95 du handshake et nombre de pairs actifs montent avec labels region et proto. Ainsi, le NOC a un panneau unifié, et les équipes régionales ont les détails localement.

La stabilité prime. Ne poussez pas les files remote_write dans la zone rouge. Mettez une alerte sur le retard et volume de rejets. Si besoin, divisez les métriques en plusieurs profils remote_write selon le type de charge.

Sécurité, limites et fiabilité

Scraping TLS avec authentification mutuelle ? Oui. Secret simple user:pass ? Possible en réseau isolé. Des limites sur exportateurs et Prometheus sont indispensables : une requête malveillante ne doit pas planter le collecteur. Timeout niveau job et metric honor_timestamps: false où les sources sont étranges. Et surtout, plafonnez le nombre de séries temporelles par job pour éviter la mise à mal de la TSDB lors d’erreur de config.

La sauvegarde des configs est aussi vitale que celle des données. Stockez en Git, intégrez en CI, validez avec promtool check config et testez les alertes dans les pipelines. C’est fastidieux, mais ça évite les surprises nocturnes.

Dashboards Grafana : du pouls général au diagnostic approfondi

Structure des dashboards et standards UX

On conçoit trois zones horizontales. En haut : statut et SLO — disponibilité, nombre de pairs actifs, erreurs de connexion sur 1h et 24h. Au milieu : performance — bande passante, p95 handshake, CPU crypto, pertes sur interfaces. En bas : diagnostic — pairs précis, événements DPD, redémarrages du démon, répartition RTT. Les filtres environment, region, proto, gateway sont incontournables.

Pas de surcharge colorimétrique. Vert quand tout va bien, rouge en cas d’alerte sévère, jaune pour dégradation. Légendes courtes, titres clairs. Et toujours, unités correctement renseignées : octets, paquets, secondes. Simple, mais efficace pour éviter les erreurs d’interprétation.

Tableaux par protocoles

WireGuard : graphiques par pairs et interfaces, latence du dernier handshake, débit octets entrant/sortant, compteur tentatives de connexion. OpenVPN : clients actifs, renegotiations et échecs, sauts de routes, charge processeur. IPsec : SA établis, dynamique rekey, échecs d’authentification, DPD en temps réel. Pas de mélange confus. Chaque protocole a sa place, avec une vue générale commune.

L’idée : passer rapidement du symptôme à la cause. Clique sur p95 handshake vers un pair spécifique, du trafic global vers une interface précise, d’une alerte au panneau d’un nœud. Moins de clics, moins de stress.

Trois niveaux d’observation : direction, NOC, ingénieurs

On propose trois profils. Vue direction : 5-7 vignettes avec SLO, capacités et tendances régionales, sans détails mineurs. Vue NOC : carte incidents, régions sensibles, files d’alertes. Vue ingénieur : tous les détails, logs, métriques, filtres. Cette segmentation règle le dilemme éternel « montrez-moi que l’essentiel » vs « donnez-moi tout ». Tout le monde y trouve son compte.

Conseil pratique : versionnez vos dashboards. Quand quelqu’un « améliore » axes ou requêtes, il faut pouvoir revenir en arrière. L’historique est votre assurance anti-erreur humaine.

Alerting : moins de bruit, plus d’efficacité

Règles SLO-driven et fenêtres de déclenchement

Nos alertes sont basées sur les SLO. Exemple : si la part des handshake ratés dépasse 1 % pendant 5 minutes, on lance un warning ; à 5 % sur 10 minutes, c’est page d’astreinte. Si disponibilité des tunnels < 99,9 % sur 24 heures, incident de gravité moyenne. Math simple, comportement prévisible. Sans conjectures.

Choisir le bon intervalle est clé. Trop court = bruit. Trop long = réaction tardive. Pour VPN, 2-5 minutes pour symptômes, 15-30 pour tendances marchent bien. Et on n’oublie pas les fenêtres nocturnes pour les rotations clés régulières, pour ne pas réveiller inutilement.

Symptômes versus causes

Symptôme : p95 handshake > 500 ms ou chute brutale du nombre de pairs actifs. Cause : CPU crypto saturé ou uplink tombé. Deux catégories d’alertes : symptomatiques—fortes mais brèves, pour réagir vite ; causales—accompagnantes, pour guider l’investigation. Ensemble, elles apportent clarté et non confusion.

En 2026, annotations partagées entre Grafana et Alertmanager permettent d’associer lien vers dashboard et check-list d’actions. Sur le terrain, ça accélère la résolution de 20-30 %. Un détail minuscule avec un grand effet.

Route et réduction de bruit avec Alertmanager

Le routage se fait selon region, proto et gravité. Les ingénieurs d’astreinte reçoivent uniquement les alertes critiques de leur région. Le reste va dans un canal général avec délai et déduplication. On utilise des inhibiteurs : si une alerte « dégradation régionale » est active, elles liées « port inaccessible » sur la même région sont bridées. Résultat : une réduction de 60 % des notifications inutiles en crise.

Exemple succinct de règle sans retour ligne : groups: - name: vpn-alerts rules: - alert: WireGuardHandshakeSlow expr: histogram_quantile(0.95, sum(rate(wg_handshake_seconds_bucket[5m])) by (le,region)) > 0.5 for: 5m labels: severity: warning annotations: summary: p95 handshake supérieur à 500 ms description: La région {{ $labels.region }} souffre de délais.

Tests des alertes et vérification continue

On rédige des profils de charge et simule des pannes : désactivation d’interface, surcharge CPU crypto, coupure gestion OpenVPN. Les alertes doivent correspondre aux spécifications. On documente les résultats dans un playbook. Des exercices réguliers forment l’équipe et réduisent MTTD et MTTR. Pas de magie, juste de la rigueur.

On fait aussi valider les règles par CI : promtool check rules, linters d’expressions, séries synthétiques pour quantiles complexes. Ce n’est pas parfait, mais ça évite fautes de frappe et seuils absurdes.

Logs, traces et eBPF comme amplificateurs

Transformez les logs VPN en métriques via parsing

Les logs regorgent d’informations : événements DPD, renegotiation, erreurs CRL. On ne noie pas dedans, mais on convertit le vital en métriques : compteurs d’erreurs par type, histogrammes durée handshake, labels région et nœud. Complément utile à l’exportateur quand le protocole est chiche en données. En 2026, beaucoup d’équipes uniformisent le parsing via Pushgateway ou OTEL Collector avec prometheusremotewrite pour événements rares.

Important : ne pas confondre ; les logs servent aux enquêtes, les métriques aux alertes. On relie d’ailleurs les alertes aux dashboards logs. Un contexte bref facilite énormément.

eBPF : plus profond, mais prudemment

eBPF offre une vision détaillée du trafic : flux, latences, retransmissions, pertes avec causes. Pour le VPN, c’est précieux, surtout face aux désaccords entre réseau et dev. On déploie des agents eBPF sur les paires de gateways à fort trafic, pour collecter des métriques agrégées. Il faut bien contrôler overhead et mise à jour du kernel. Règle simple : activer uniquement ce que l’on regarde régulièrement.

Avec eBPF, on repère plus facilement pourquoi des pairs clignotent : itinéraire qui fuit, MTU cassant la fragmentation ou files saturées sur interface. Ces indices économisent heures et nerfs.

OpenTelemetry et Prometheus main dans la main

OpenTelemetry en 2026, ce n’est pas que des traces, c’est aussi des métriques. On fait passer les métriques VPN par OTEL Collector, on normalise les labels, on convertit en format Prometheus et on pousse vers le stockage. Avantages : point de config unique, filtrage souple, triple compatibilité logs/traces/métriques. Inconvénients : il faut discipline et documentation, sinon on s’embrouille vite.

Combinaison efficace : les exportateurs livrent directement à Prometheus pour la criticité, parallèlement le Collector enrichit et fait du remote_write vers stockage long terme. Ce doublon peut paraître étrange, mais renforce la résilience.

Exploitation : performances, coûts et fiabilité

Budgets ressources sous charge

Les gateways VPN butent souvent sur le CPU du fait du chiffrement. On suit cpu_utilization, crypto_time, irq_load. Sur Prometheus, on limite les séries temporelles et veille au cache mémoire. Pour une dizaine de gateways, un couple vCPU et 4-8 Go RAM suffit. Pour des centaines, on scale horizontalement : collection sharded, fédération, séparation géographique. Tenter de « tout faire tourner sur un seul nœud » est coûteux et fragile.

Quelques règles : bloqué à l’écriture ? baissez la fréquence, diminuez la cardinalité, centralisez les événements rares en compteurs. Problème de lecture en dashboard ? mettez en cache, simplifiez les requêtes, utilisez downsampling où c’est possible.

Cardinalité, rétention et optimisation budgétaire

La cardinalité est l’ennemi de l’observabilité. Des centaines de milliers de labels par client tuent les TSDB et le budget. On garde des agrégations par pair ou tunnel, et pour les enquêtes on active temporairement des logs détaillés. La rétention se fait en couches : 7-15 jours local en chaud, 30-90 jours en distant tiède, archive plus longue en stockage objet ou base économique.

En argent, c’est simple : trop de cardinalité, c’est disque, CPU et licences en plus sur le long terme. En réduisant 80 % des labels « inutiles », on divise le budget par trois. C’est douloureux au départ, mais bénéfique à terme.

Sauvegardes, mises à jour et plans de reprise

Prometheus est stateful mais pas hyper critique. Par contre, configs et alertes sont votre cerveau. On backup Git, snapshots du stockage long terme, secrets et certificats. Les mises à jour sont faites en canary : un collecteur, une Grafana, un Alertmanager avant les autres. Si problème, rollback sans panique.

Pour le DR, on a une deuxième région avec Prometheus froid et synchronisation des dashboards. Incident sur le principal ? On bascule sur le secours. Migration testée à chaque exercice trimestriel. Oui, c’est fastidieux, mais c’est la vraie fiabilité.

Conformité, audit et confidentialité

Les métriques VPN peuvent contenir des données sensibles. On évite les identifiants personnels dans les labels, on utilise du hachage ou pseudonymes. L’accès aux dashboards est restreint par rôles : NOC, ingénieurs, auditeurs. Logs d’accès et changements sont centralisés. Cela aide autant pour les audits que pour retracer rapidement qui a fait quoi en cas de pépin.

Cas pratiques : du petit bureau au réseau global

Petite entreprise : 10 à 50 utilisateurs

Une passerelle OpenVPN, une autre WireGuard en secours. Node Exporter, exportateur minimal, Prometheus sur serveur modeste, Grafana à côté. Alertes sur disponibilité, erreurs d’authentification, pairs offline plus de 5 minutes. Déploiement en 1-2 jours. Résultat : dashboard tout vert et quelques notifications hebdo, pas plus.

Optimisez : coupez les métriques coûteuses, activez seulement les panneaux essentiels, planifiez la rotation des clés. Et surtout testez la bascule régulière : l’équipe doit savoir quoi faire quand la passerelle principale part en pause.

Entreprise moyenne : succursales et mobiles

Plusieurs gateways régionales, WireGuard pour site-à-site, OpenVPN pour clients. Prometheus par région, fédération vers le sommet, stockage distant commun. Alerting via Alertmanager avec routage régional. Dashboards à trois niveaux, rôles Grafana. eBPF activé point par point pour incidents réseaux complexes.

Le gain : détection en minutes au lieu d’heures, enquêtes en heures, non en jours. Et le business gagne une vraie visibilité SLO pour planifier la capacité sans deviner.

Fournisseur ou réseau mondial

Des centaines de gateways, milliers de pairs. Discipline absolue. Collecteurs shardés, agrégations régionales, règles strictes de labels, génération automatique des configs via CMDB. Remote_write vers plusieurs stockages, tests de charge réguliers, mises à jour canaries. Dashboards NOC dédiés au filtrage du bruit. On investit dans l’automatisation pour éviter les corvées manuelles.

Résultat : incidents prévisibles, réponses rapides, bruit minimal. Coûteux, mais moins que les arrêts massifs et pénalités SLA. L’équipe respire, le business dort tranquille.

Erreurs fréquentes et comment les éviter

Premièrement : surabondance de métriques et labels par client. Corrigé par une politique de cardinalité. Deuxièmement : alertes sans priorité ni consignes. Corrigé par annotations, playbooks et SLO. Troisièmement : dashboards avec 100 panneaux inutiles. Corrigé par structure, UX et trois niveaux. Quatrièmement : sécurité « plus tard ». Corrigé par TLS, gestion des rôles et audit dès le début. Cinquièmement : absence de tests et DR. Corrigé par discipline, sinon le hasard vous rattrapera.

Et oui, n’hésitez pas à supprimer le superflu. Le monitoring n’est pas un musée de métriques, mais un outil. Mieux vaut peu et pertinent.

Checklist de déploiement : clair et concis

Préparation

Choisir protocoles et nœuds. Sélectionner exportateurs. Définir SLO. Décider rétention et budget. Structurer les labels. Définir rôles d’accès et exigences sécurité. Préparer CMDB ou fichiers pour file_sd_configs. Tout cela en une semaine, sans flair héroïque.

Indispensable : clarifier d’entrée les incidents critiques, destinataires des notifications, gardes. Sans ça, le meilleur monitoring reste une jolie image sur l’écran en salle de réunion.

Déploiement

Installer Node Exporter et exportateurs protocoles. Lancer Prometheus et Alertmanager. Configurer scrape_configs, relabeling, remote_write. Déployer Grafana, importer dashboards de base, ajouter templates. Créer premières alertes. Effectuer smoke tests : couper port, saturer démon, vérifier alertes et tableaux vivants.

Documenter résultats, mesurer MTTD. Ajuster seuils et fréquences. C’est votre chance d’adapter la surveillance à votre réalité et pas juste au manuel.

Mise en service et formation

Sessions pour NOC et ingénieurs : comment lire les dashboards, filtrer labels, explorer les causes. Documenter playbooks pour top 5 incidents. Programmer exercices mensuels simulant pannes réelles. Mettre à jour procédures après incidents. Ces détails économisent des semaines en cumul.

Un mois plus tard, rétro : alertes superflues, métriques inutiles, manque de contexte. Un dialogue honnête et deux jours d’améliorations, et votre système deviendra un allié, pas une source de stress.

FAQ : les questions fréquentes mais peu documentées

Réponses rapides

Faut-il surveiller les clients par utilisateur ?

Uniquement pour enquêtes ponctuelles. Pour la surveillance courante, agrégerez par pair ou tunnel. Les labels personnels explosent la cardinalité et coûtent cher. Et oui, c’est l’erreur classique des débutants.

Quelle fréquence pour WireGuard ?

Pour les symptômes, 5-10 secondes, pour les causes, 30-60 secondes. Si contraintes budgétaires, allongez les fenêtres, mais gardez les tests rapides de disponibilité.

Quoi déployer le plus vite : monitoring OpenVPN ou WireGuard ?

WireGuard est généralement plus simple : entités moins nombreuses, métriques plus claires. Mais si votre interface management OpenVPN est déjà en place, ça monte aussi en quelques heures.

Détails techniques

Quoi garder localement et sur le long terme

Localement, 7-15 jours chauds pour réactivité. Sur le long terme, les agrégats latence, erreurs d’authentification, bande passante, capacité. Les séries brutes haute fréquence uniquement si une vraie analyse est prévue.

Comment tester les alertes sans stress

Scénarios stockés en Git, promtool vérificateur, séries synthétiques pour quantiles complexes. Mensuellement, exercices à sec avec coupure port, montée CPU et intervention manuelle. Ça sonne ennuyeux, mais ça marche à tous les coups.

Exploitation

Que faire des fausses alertes nocturnes ?

Activer inhibiteurs, lisser les fenêtres, enrichir annotations et playbook. Surtout, après incident, prendre le temps d’éliminer la cause du bruit sous-jacent, sinon on tourne en boucle.

Faut-il adopter OpenTelemetry dès le début ?

Pour démarrer, non. Commencez par bases métriques et alertes, puis logs et OTEL. Une fois familiarisés, le Collector deviendra un allié. Vouloir tout faire d’un coup mène à la déconvenue.

Comment exposer les métriques depuis une zone DMZ en sécurité ?

mTLS, allowlist statique, agent Prometheus dédié en DMZ avec fédération montée. Ne pas ouvrir tout au public. Et surtout, gérer rotation des certificats et révocations.