Cas pratiques Prometheus

Contexte : Un service critique nécessite une supervision plus fréquente que les autres. Le Problème : Le scrape_interval global est trop élevé pour ce service. Contraintes : Définir un scrape_interval spécifique pour un job particulier sans modifier la configuration globale. Livrable attendu : Adapter le fichier prometheus.yml afin de définir un intervalle personnalisé pour le job concerné.

Contexte : Prometheus est déjà configuré pour superviser un service unique. Le Problème : Un nouveau serveur applicatif expose des métriques sur le port 8080 mais n'est pas encore supervisé. Contraintes : Ajouter une nouvelle cible dans static_configs sans modifier les jobs existants. Livrable attendu : Adapter le fichier prometheus.yml afin d'ajouter correctement la nouvelle cible de scraping.

Contexte : Une équipe met en place Prometheus pour superviser un serveur Node Exporter. Le Problème : Au démarrage, Prometheus échoue avec une erreur YAML indiquant une mauvaise indentation dans le fichier de configuration. Contraintes : Corriger uniquement la syntaxe YAML sans modifier la logique de scraping. Extrait actuel : scrape_configs: - job_name: node static_configs: - targets: - localhost:9100 Livrable attendu : Fournir une version correctement indentée du fichier prometheus.yml permettant à Prometheus de démarrer sans erreur.

Contexte : Une équipe souhaite identifier clairement les métriques provenant de différents services. Le Problème : Plusieurs jobs utilisent le même job_name, rendant les métriques ambiguës. Contraintes : Modifier uniquement les noms des jobs pour garantir leur unicité. Livrable attendu : Adapter la configuration Prometheus pour attribuer des job_name distincts et cohérents.

Contexte : Prometheus indique une cible en état DOWN dans l'interface web. Le Problème : L'adresse configurée contient une erreur de port. Extrait actuel : static_configs: - targets: - localhost:910 Contraintes : Corriger uniquement la cible erronée. Livrable attendu : Adapter la configuration pour que la cible soit correctement définie et passe en état UP.

Contexte : Une application expose une métrique http_requests_total. Le Problème : Aucun mécanisme d'alerte n'est configuré pour détecter une augmentation anormale du trafic. Contraintes : Créer une règle d'alerte déclenchée si le nombre de requêtes dépasse un seuil défini. Livrable attendu : Fournir un fichier rules.yml contenant une règle d'alerte Prometheus simple basée sur une condition métrique.

Contexte : Une équipe souhaite surveiller l'utilisation CPU d'un serveur. Le Problème : Aucun dashboard ou requête n'a encore été défini. Contraintes : Utiliser une métrique standard issue de Node Exporter. Livrable attendu : Proposer une requête PromQL simple permettant d'afficher l'utilisation CPU moyenne sur 5 minutes.

Contexte : Un serveur Linux doit être supervisé via Node Exporter. Le Problème : Prometheus ne récupère aucune métrique car la cible est mal configurée. Contraintes : Vérifier que la cible correspond bien à l'adresse et au port exposé par Node Exporter. Livrable attendu : Adapter la configuration Prometheus afin de pointer correctement vers l'instance Node Exporter fonctionnelle.

Contexte : Plusieurs règles d'alerte sont définies directement dans prometheus.yml. Le Problème : La configuration devient difficile à maintenir. Contraintes : Externaliser les règles dans un fichier rules.yml et les référencer correctement. Livrable attendu : Proposer une configuration Prometheus structurée séparant le fichier principal et les fichiers de règles.

Contexte : Une modification récente a été apportée au fichier prometheus.yml. Le Problème : L'équipe souhaite vérifier la validité de la configuration avant redémarrage. Contraintes : Utiliser les outils natifs Prometheus pour valider le fichier de configuration. Livrable attendu : Décrire la commande permettant de vérifier la validité syntaxique du fichier prometheus.yml avant son déploiement.

Contexte : Plusieurs alertes sont déclenchées mais toutes arrivent dans le même canal de notification. Le Problème : Les alertes critiques et mineures ne sont pas différenciées. Contraintes : Configurer Alertmanager pour router les alertes selon le label severity (warning, critical) vers des récepteurs différents. Livrable attendu : Proposer une configuration Alertmanager avec routes hiérarchiques permettant un routage conditionnel des alertes.

Contexte : Une organisation possède plusieurs instances Prometheus (dev, staging, prod). Le Problème : Il n'existe aucune vue consolidée des métriques globales. Contraintes : Mettre en place la fédération Prometheus pour agréger certaines métriques clés. Livrable attendu : Décrire une configuration de federation permettant à une instance centrale de collecter des métriques sélectionnées depuis d'autres instances.

Contexte : Le serveur Prometheus consomme un volume disque important en raison de la croissance des données historiques. Le Problème : Aucune politique de rétention n'est configurée. Contraintes : Ajuster les paramètres de rétention sans compromettre les besoins métiers. Livrable attendu : Décrire la configuration nécessaire pour définir une durée de rétention adaptée et optimiser le stockage des données.

Contexte : Une application est déployée sur Kubernetes et expose des métriques via un service interne. Le Problème : Prometheus ne découvre pas automatiquement les pods concernés. Contraintes : Utiliser ServiceMonitor ou configuration Kubernetes adaptée pour la découverte automatique. Livrable attendu : Proposer une configuration permettant à Prometheus de découvrir dynamiquement les services Kubernetes exposant des métriques.

Contexte : Une plateforme collecte les métriques CPU de dizaines de serveurs via Node Exporter. Le Problème : Les requêtes PromQL complexes sont répétées dans plusieurs dashboards, rendant l'analyse lente et difficile à maintenir. Contraintes : Créer une recording rule permettant de pré-calculer l'utilisation CPU moyenne par instance sur 5 minutes. Ne pas modifier les exporters existants. Livrable attendu : Proposer un fichier de règles définissant une recording rule pertinente et l'intégrer correctement dans la configuration Prometheus.

Contexte : Une API expose une métrique http_requests_total avec un label status. Le Problème : Aucune alerte n'est configurée pour détecter un taux d'erreurs 5xx élevé. Contraintes : Utiliser une requête PromQL calculant le ratio d'erreurs sur le total des requêtes. Livrable attendu : Proposer une règle d'alerte déclenchée si le taux d'erreurs 5xx dépasse un seuil défini sur une période donnée.

Contexte : Une application expose ses métriques via HTTPS avec authentification basique. Le Problème : Prometheus ne parvient pas à scraper correctement la cible. Contraintes : Configurer scheme: https, basic_auth et éventuellement relabel_configs. Livrable attendu : Adapter le fichier prometheus.yml pour permettre le scraping sécurisé d'une cible HTTPS protégée.

Contexte : Un dashboard affiche des métriques agrégées sur une longue période pour plusieurs centaines de séries temporelles. Le Problème : Les requêtes sont lentes et impactent les performances du serveur Prometheus. Contraintes : Optimiser la requête PromQL sans supprimer les informations essentielles. Livrable attendu : Proposer une version optimisée d'une requête PromQL complexe en réduisant la cardinalité ou en utilisant des fonctions adaptées.

Contexte : Une application génère des métriques avec des labels dynamiques incluant des identifiants uniques. Le Problème : La cardinalité élevée dégrade les performances de Prometheus. Contraintes : Identifier une stratégie de réduction via relabeling ou modification des labels. Livrable attendu : Proposer une solution permettant de réduire la cardinalité excessive tout en conservant la pertinence des métriques.

Contexte : Une application est déployée sur plusieurs instances derrière un load balancer. Le Problème : Les métriques ne sont pas correctement distinguées car les labels sont mal configurés. Contraintes : Utiliser des labels cohérents dans scrape_configs pour différencier les environnements et instances. Livrable attendu : Adapter la configuration Prometheus afin d'ajouter des labels pertinents permettant une identification claire des métriques par instance.

Contexte : Une entreprise opère dans plusieurs régions géographiques avec des déploiements indépendants. Le Problème : La supervision est fragmentée et aucune vue consolidée mondiale n'existe. Contraintes : Concevoir une architecture multi-régions tolérante aux pannes réseau. Livrable attendu : Décrire une architecture complète combinant Prometheus locaux, agrégation centrale et mécanismes de tolérance aux partitions réseau.

Contexte : Une organisation supervise des centaines de services critiques avec une seule instance Prometheus. Le Problème : Cette instance constitue un point unique de défaillance et ne permet pas une conservation longue durée des métriques. Contraintes : Mettre en place une architecture hautement disponible avec réplication Prometheus et intégration Thanos pour stockage long terme. Aucun impact sur les exporters existants. Livrable attendu : Proposer une architecture complète intégrant plusieurs instances Prometheus, Thanos Sidecar, stockage objet et requêtage unifié via Thanos Query.

Contexte : Une entreprise souhaite recevoir des alertes critiques via plusieurs canaux (email, Slack, PagerDuty) avec escalade progressive. Le Problème : Les alertes sont actuellement envoyées sans hiérarchie ni stratégie d'escalade. Contraintes : Configurer Alertmanager avec routage hiérarchique, grouping et repeat_interval adaptés. Livrable attendu : Proposer une configuration avancée d'Alertmanager permettant escalade conditionnelle, déduplication et gestion intelligente des notifications.

Contexte : Une plateforme souhaite détecter des comportements anormaux sans seuil fixe statique. Le Problème : Les alertes actuelles reposent uniquement sur des seuils rigides. Contraintes : Utiliser des fonctions PromQL comme avg_over_time, stddev_over_time pour calculer des déviations dynamiques. Livrable attendu : Proposer une approche de détection d'anomalies basée sur comparaison statistique des métriques sur une fenêtre temporelle glissante.

Contexte : Plusieurs clusters Kubernetes doivent être supervisés depuis une instance centrale. Le Problème : La collecte brute de toutes les métriques surcharge l'instance centrale et mélange les environnements. Contraintes : Mettre en place une fédération sélective avec filtrage par labels et isolation des namespaces. Livrable attendu : Décrire une architecture de fédération multi-clusters permettant agrégation centralisée tout en conservant une isolation logique des environnements.

Contexte : Une API critique doit respecter un SLO de latence à 95% sous 200ms. Le Problème : Les métriques actuelles ne permettent pas de mesurer précisément la conformité au SLO. Contraintes : Utiliser des histogrammes Prometheus et requêtes PromQL adaptées pour calculer les percentiles. Livrable attendu : Décrire une stratégie complète de mesure SLO avec histogram_quantile et règles d'alerte basées sur le non-respect du SLO.

Contexte : Une organisation utilise actuellement uniquement Prometheus pour la supervision. Le Problème : L'absence de corrélation logs-métriques complique l'analyse des incidents. Contraintes : Intégrer Grafana pour visualisation avancée et Loki pour logs tout en conservant Prometheus comme source métrique. Livrable attendu : Proposer une architecture d'observabilité complète intégrant métriques, dashboards et logs corrélés dans une stack cohérente.

Contexte : Une instance Prometheus collecte des millions de samples par minute. Le Problème : Les temps de réponse des requêtes PromQL deviennent trop longs et la consommation disque augmente rapidement. Contraintes : Ajuster les paramètres TSDB (retention, block duration, WAL) sans perte critique de données. Livrable attendu : Proposer une stratégie complète d'optimisation incluant tuning TSDB, rétention adaptée et ajustement des intervalles de scraping.

Contexte : L'interface Prometheus est exposée publiquement pour consultation. Le Problème : Aucun mécanisme d'authentification ou de contrôle d'accès n'est en place. Contraintes : Mettre en place reverse proxy sécurisé, authentification et éventuellement TLS. Livrable attendu : Proposer une architecture sécurisée protégeant l'accès à Prometheus tout en garantissant la continuité du scraping interne.

Contexte : Une plateforme microservices génère des millions de séries temporelles à cause de labels dynamiques non maîtrisés. Le Problème : Les performances de Prometheus se dégradent fortement et la mémoire explose. Contraintes : Identifier les métriques problématiques et mettre en place des stratégies de relabeling, filtrage ou réécriture. Livrable attendu : Décrire une approche technique complète permettant de réduire drastiquement la cardinalité tout en conservant la valeur métier des métriques.