Prometheus sur Kubernetes OVHcloud : déployer kube-prometheus-stack avec Helm

Table des matières :

1. kube-prometheus-stack : ce que vous déployez réellement
2. Spécificités OVHcloud Managed Kubernetes : stockage, LoadBalancer, droits
3. Déploiement Helm reproductible (et gestion des CRDs)
4. Exposer Grafana/Prometheus sans ouvrir le cluster en grand
5. Ajouter vos métriques applicatives (PrestaShop, Ingress, MySQL) avec ServiceMonitor
6. Alerting propre : PromQL, Alertmanager, tests et runbooks
7. Exploitation : upgrades, tuning, et pannes classiques sur OVHcloud

Déployer Prometheus sur Kubernetes OVHcloud avec kube-prometheus-stack via Helm n’est pas “juste installer Prometheus”. Vous installez surtout un opérateur (Prometheus Operator) qui pilote des objets Kubernetes (CRDs) pour générer automatiquement les bonnes ressources (Prometheus, Alertmanager, règles, scrape config) sans retomber dans des manifests YAML copiés-collés et ingérables.

L’objectif en production n’est pas “avoir un Grafana qui s’ouvre”, mais d’obtenir un socle reproductible (Helm + Git), sûr (auth, TLS, RBAC, NetworkPolicies) et exploitable (règles d’alerting + runbooks + capacité de diagnostic). Sur OVHcloud, ça passe aussi par de bons choix de StorageClass, de rétention et de mode d’exposition (Ingress vs LoadBalancer).

kube-prometheus-stack : ce que vous déployez réellement

Le chart kube-prometheus-stack (repo prometheus-community) empaquette une stack cohérente : Prometheus, Alertmanager, Grafana, node-exporter, kube-state-metrics, et surtout Prometheus Operator. L’opérateur étend l’API Kubernetes avec des CRDs (Custom Resource Definitions) comme ServiceMonitor, PodMonitor, PrometheusRule et Alertmanager. C’est ce point qui change la vie : au lieu de maintenir une liste d’IP/ports, vous décrivez des sélecteurs Kubernetes.

Définition utile : un ServiceMonitor est une ressource CRD qui dit “scrape tous les Services portant tel label, sur tel port, à telle fréquence”. Ça permet une observabilité “native Kubernetes”, alignée sur les labels/namespace plutôt que sur des endpoints statiques. C’est aussi la source la plus fréquente de confusion : si vos labels ne matchent pas, vous avez zéro métrique sans message clair côté application.

Sur le fonctionnement interne, Prometheus reste un modèle pull : il collecte les métriques en “scrappant” des endpoints HTTP exposés par les cibles (documentation Prometheus : https://prometheus.io/docs/introduction/overview/). Dit autrement : si votre application (ou un exporter) n’expose pas /metrics, Prometheus ne devine rien. Et côté PrestaShop, le core n’expose pas de métriques Prometheus : il faut instrumenter (statsd/OTel) ou déployer des exporters au niveau infra (Ingress, PHP-FPM, MySQL, Redis).

Deux clarifications pratiques qui évitent beaucoup de temps perdu :

• ServiceMonitor vs PodMonitor :
• ServiceMonitor s’appuie sur un Service (stable, labelisé, souvent préféré).
• PodMonitor cible directement des pods (utile si vous n’avez pas de Service, mais plus sensible aux changements).
• Discovery ≠ scrape : vous pouvez voir vos objets Kubernetes (ServiceMonitor présents), sans pour autant scrapper les targets (labels non matchés, port manquant, auth kubelet, NetworkPolicy…).

Enfin, gardez en tête que kube-prometheus-stack installe aussi des dashboards et des règles par défaut. C’est un accélérateur… et parfois une source de “bruit” (alertes trop génériques) si vous ne les ajustez pas.

Pour référence, la source du chart est ici (utile pour lire les options, valeurs par défaut, et notes de release) : https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

Spécificités OVHcloud Managed Kubernetes : stockage, LoadBalancer, droits

Sur OVHcloud Managed Kubernetes (Public Cloud), vous devez anticiper deux contraintes : le stockage persistant et les droits cluster-wide. Prometheus Operator installe des CRDs au niveau cluster : il faut typiquement des permissions proches de cluster-admin (au minimum pour créer/mettre à jour des CRDs et des webhooks d’admission). En environnement mutualisé multi-équipes, c’est un point politique/SSI à trancher avant de lancer Helm.

Le stockage est le vrai sujet “prod” : Prometheus conserve des séries temporelles en local (TSDB). Sans PVC, vous perdez l’historique à chaque reschedule. Sur OVHcloud, vous aurez généralement des StorageClasses CSI basées sur Cinder (souvent des variantes “classic/high-speed” selon votre projet/région). Ne choisissez pas à l’aveugle : commencez par kubectl get storageclass et alignez le compromis IOPS/prix/rétention. Un Prometheus très bavard (kube-state-metrics + exporters + application) peut générer des volumes non triviaux.

Checklist simple pour décider “sans magie” :

• Rétention (ex : 15 jours) : plus long = plus de disque (et plus de compactions).
• Fréquence de scrape (15s vs 30s vs 60s) : plus rapide = plus de samples = plus de CPU/RAM/disque.
• Cardinalité : plus vous avez de labels “uniques” (URI complète, userid, orderid…), plus vous explosez le nombre de séries.
• HA/replicas : si vous voulez 2 Prometheus (sharding/HA), il faut 2 volumes, et des contraintes d’affinité.

Un moyen concret d’éviter les “surprises” après déploiement : surveiller très tôt la volumétrie interne de Prometheus (dans Grafana, dashboards Prometheus / TSDB), en particulier :

• prometheus_tsdb_head_series (nombre de séries en mémoire),
• prometheus_tsdb_compactions_total et durées de compaction,
• la taille du WAL (Write-Ahead Log) et sa pression,
• consommation disque du PVC.

Côté exposition réseau : OVHcloud fournit classiquement des Services LoadBalancer via le CCM OpenStack. C’est pratique, mais pas neutre : chaque LoadBalancer a un coût/une gestion, et vous ne voulez pas exposer Prometheus ou Alertmanager “en clair” sur Internet. En pratique, privilégiez un Ingress derrière TLS + authentification (ou du kubectl port-forward en accès admin), et réservez le LoadBalancer à l’Ingress Controller.

Pour cadrer l’infra qui héberge tout ça (latence, anti-DDoS, ports, durcissement), vous pouvez recouper avec VPS OVHcloud : sécurité, anti-DDoS, SMTP 25 et bonnes pratiques admin.

Déploiement Helm reproductible (et gestion des CRDs)

Contexte versions (ciblage) : commandes ci-dessous écrites pour Kubernetes v1.29+, Helm v3.14+ et le chart kube-prometheus-stack dans une version récente. Avant d’ancrer une version, listez ce que vous avez réellement :

kubectl version --short
helm version
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm search repo prometheus-community/kube-prometheus-stack --versions | head

Évitez l’installation “one-liner” sans values.yaml. Vous voulez un fichier versionné (Git) pour : tailles de PV, rétention, ressources, exposition, RBAC, et désactivation de composants inutiles. Exemple minimaliste (à adapter) :

# values-kps.yaml
prometheus:
  prometheusSpec:
    retention: 15d
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi

alertmanager:
  alertmanagerSpec:
    storage:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 10Gi

grafana:
  enabled: true
  adminPassword: "CHANGE_ME_USE_SECRET_IN_REAL_LIFE"
  persistence:
    enabled: true
    size: 10Gi

Quelques améliorations “prod-ready” typiques, sans alourdir inutilement :

• Ne stockez pas de mot de passe en clair dans Git : préférez un Secret existant (ou une solution External Secrets).
• Fixez une StorageClass explicitement si votre cluster en propose plusieurs (évite de changer de comportement lors d’une évolution côté infra) :

prometheus:
  prometheusSpec:
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: "csi-cinder-high-speed" # exemple : adaptez à votre cluster
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi

• Définissez une policy de ressources aussi pour l’opérateur (sinon, sur petit cluster, ce sont les composants “invisibles” qui deviennent votre goulot) :

prometheusOperator:
  resources:
    requests:
      cpu: 200m
      memory: 256Mi

Installation/upgrade idempotent (namespace dédié, release stable) :

kubectl create namespace monitoring
helm upgrade --install kps prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  -f values-kps.yaml

kubectl -n monitoring get pods
kubectl -n monitoring get servicemonitors,podmonitors,prometheusrules | head

Point sensible : les CRDs. Selon votre politique, vous pouvez préférer gérer les CRDs séparément (GitOps/ArgoCD) plutôt que de laisser Helm les “posséder”. Le chart a des options dédiées suivant versions ; lisez la doc du chart (GitHub) et arbitrez. Si vous ne clarifiez pas ça, vous vous exposez à des upgrades qui cassent l’état (CRD drift) ou à des conflits de ownership Helm.

Deux commandes utiles pour diagnostiquer “ça a installé, mais ça scrape rien” :

# Vérifier que Prometheus est bien créé par l'opérateur
kubectl -n monitoring get prometheus

# Vérifier les targets côté Prometheus (via port-forward ensuite)
kubectl -n monitoring get svc | grep -E 'prometheus|grafana|alertmanager'

Et si vous suspectez un problème de sélection des ServiceMonitors : inspectez la spec du Prometheus généré (le champ serviceMonitorSelector et serviceMonitorNamespaceSelector sont souvent la clé).

Exposer Grafana/Prometheus sans ouvrir le cluster en grand

La méthode la plus sûre pour démarrer sur OVHcloud : port-forward (accès admin) + bastion/VPN. Ça réduit la surface d’attaque, surtout si vous n’avez pas encore de gestion SSO/OIDC. Exemple :

kubectl -n monitoring port-forward svc/kps-grafana 3000:80
kubectl -n monitoring port-forward svc/kps-kube-prometheus-stack-prometheus 9090
kubectl -n monitoring port-forward svc/kps-kube-prometheus-stack-alertmanager 9093

En production, vous finirez généralement par un Ingress (NGINX/Traefik/HAProxy ingress) avec TLS, et auth obligatoire. Grafana expose des permissions fines mais ce n’est pas un WAF : mettez, au minimum, un proxy d’authentification (OAuth2, OIDC) ou une BasicAuth correctement gérée (secret Kubernetes + rotation). L’erreur classique : exposer Grafana et laisser l’admin par défaut ou un mot de passe en clair dans values.yaml.

Deux bonnes pratiques “réalistes” quand vous passez à l’Ingress :

• Séparer l’exposition de Grafana (UI) et celle de Prometheus/Alertmanager (API) : ces derniers finissent souvent consommés par des outils internes seulement.
• Bloquer l’indexation et l’accès public : authentification + éventuellement une liste d’IP autorisées (VPN/bastion) si votre modèle le permet.

Sur la partie certificats et routage, c’est cohérent de rapprocher votre configuration d’une approche “landing zone” (segmentation réseau, ingress central, politiques) : https://www.expertise-prestashop.fr/2026/06/30/landing-zone-ovhcloud-architecture-hub-and-spoke-avec-opnsense-ha/.

Enfin, appliquez des NetworkPolicies si votre CNI les supporte : vous voulez limiter les flux entrants vers Prometheus (scrape) aux namespaces qui publient des métriques, et empêcher tout trafic latéral inutile. Sur un cluster e-commerce, l’observabilité finit vite par toucher des secrets (URLs internes, noms de services, métadonnées) : traitez ça comme un composant sensible, pas comme un “outil de dev”.

Exemple minimal (à adapter à votre CNI/labels) : autoriser uniquement Prometheus à joindre les exporters d’un namespace applicatif.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-prometheus-scrape
  namespace: shop
spec:
  podSelector: {} # tous les pods du namespace "shop"
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - namespaceSelector:
            matchNames: ["monitoring"]
      ports:
        - protocol: TCP
          port: 9100  # exemple (node-exporter/exporter)

En parallèle, gardez un socle de durcissement applicatif (TLS, mises à jour, etc.) : https://www.expertise-prestashop.fr/2026/07/06/securite-prestashop-mises-a-jour-ssl-et-durcissement-htaccess/.

Ajouter vos métriques applicatives (PrestaShop, Ingress, MySQL) avec ServiceMonitor

Le plus gros différenciateur de kube-prometheus-stack, c’est votre capacité à brancher vos workloads proprement. Pour une stack e-commerce PrestaShop, vous aurez typiquement : un Ingress Controller (Nginx), des pods PHP-FPM (ou Apache), une base MySQL/MariaDB, du cache (Redis), parfois Varnish. À défaut de métriques natives, vous passez par des exporters standards.

Exemple concret : vous déployez un exporter (ou un service) qui expose /metrics sur le port metrics, et vous créez un ServiceMonitor dans le namespace applicatif. L’opérateur se charge du reste.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prestashop-phpfpm
  namespace: shop
  labels:
    release: kps   # doit matcher le selector du chart (souvent "release")
spec:
  selector:
    matchLabels:
      app: phpfpm-exporter
  namespaceSelector:
    matchNames: ["shop"]
  endpoints:
    - port: metrics
      interval: 30s
      path: /metrics

Trois pièges récurrents : (1) le label release ne correspond pas (le chart filtre ses ServiceMonitors), (2) vous exposez un port différent de celui déclaré dans le Service, (3) vous scrapez trop souvent et vous explosez le coût CPU + la cardinalité. Sur ce dernier point : kube-state-metrics et des exporters trop “verbeux” peuvent générer des dizaines/centaines de milliers de séries. La TSDB de Prometheus n’aime pas les labels à haute cardinalité (id commande, id client, URL complète, etc.). Pour un checkout, vous voulez des agrégats (latence p95, taux d’erreur) — pas un label par utilisateur.

Mini-scenario typique (et très concret en e-commerce) :
vous ajoutez des métriques HTTP avec un label path="/product/12345-super-produit" (ou pire : path inclut des paramètres). Résultat : à chaque nouveau produit/variation d’URL, vous créez une nouvelle série temporelle. En quelques heures/jours de trafic, vous avez :

• RAM Prometheus qui grimpe (head block),
• requêtes Grafana qui deviennent lentes,
• compactions TSDB plus fréquentes,
• et des dashboards “inutilisables” en période de soldes.

Contre-mesures pragmatiques :

• normaliser les chemins (templating) ou agréger par route (ex : /product/:id),
• supprimer les labels inutiles côté exporter/instrumentation,
• augmenter l’intervalle de scrape pour les métriques peu critiques (ex : 60s sur certains exporters),
• n’exporter que les métriques réellement actionnables.

Pour relier ça aux problématiques de perf boutique (TTFB, cache, goulots PHP/MySQL), votre base de lecture interne est ici : https://www.expertise-prestashop.fr/2026/06/18/prestashop-performance-monitoring-tests-de-charge-et-runbooks-soldes/ et https://www.expertise-prestashop.fr/2026/06/29/performance-prestashop-benchmarks-et-optimisation-php-fpm-opcache-mysql/.

Si vous avez déjà une sonde complémentaire type agent, comparez avec Netdata monitoring : surveiller AWS, Kubernetes, bases de données et serveurs web : Netdata est très bon pour le “temps réel” et le diagnostic interactif, Prometheus excelle pour l’historique, l’alerting et le PromQL.

Alerting propre : PromQL, Alertmanager, tests et runbooks

Installer Alertmanager ne suffit pas : sans règles pertinentes, vous recevez soit rien, soit du bruit. Un garde-fou simple : une alerte doit déclencher une action claire (et idéalement pointer vers un runbook), sinon vous entraînez l’équipe à l’ignorer. Le livre Site Reliability Engineering (Google) rappelle justement l’idée d’un monitoring “actionnable” plutôt que bavard : https://sre.google/sre-book/monitoring-distributed-systems/

Sur kube-prometheus-stack, vous déclarez vos alertes via PrometheusRule. Exemple simple et utile en e-commerce : saturation PHP-FPM (trop de workers occupés), qui corrèle très bien avec des pics de latence côté checkout. Les métriques exactes dépendent de l’exporter PHP-FPM, mais le pattern est stable : alerter sur un ratio “busy / max” et non sur une valeur brute. Autre règle classique : baisse brutale du taux de réponses 2xx sur l’Ingress, combinée à une hausse 5xx.

Un bon template d’alerte (structure) contient presque toujours :

• symptôme (quoi) : latence, erreurs, saturation,
• impact (qui) : namespace/app/route critique,
• seuil + durée (combien/combien de temps) : éviter le flapping,
• lien vers runbook : étapes de triage + commandes + “rollback plan”.

Côté routage Alertmanager (Slack, email, webhook vers votre API Gateway), utilisez la config route/receivers/inhibit_rules pour éviter l’avalanche lors d’un incident global (ex : base down → tout tombe). L’inhibition est particulièrement utile dans un cluster microservices : quand un composant amont tombe, vous voulez une alerte “racine” + des alertes “symptômes” silencées automatiquement.

Si votre SI intègre un gateway interne, vous pouvez aussi appliquer des politiques (auth, rate limiting) au webhook d’Alertmanager : voir API Gateway : authentification, rate limiting et routage des microservices.

Testez vos alertes. Vraiment. En pratique :

• vérifiez les règles dans l’UI Prometheus (/rules) ;
• forcez des conditions (réduire temporairement les replicas, injecter une latence contrôlée) en environnement de staging ;
• utilisez amtool (si disponible) pour inspecter les alertes et silences.

Sans tests, vous découvrez le jour J que votre règle matche une métrique inexistante (typo de label), ou que votre Alertmanager ne peut pas sortir vers Internet (egress bloqué) — scénario fréquent sur des clusters durcis.

Exploitation : upgrades, tuning, et pannes classiques sur OVHcloud

La maintenance “normale” : upgrader le chart et maîtriser l’impact. Ne faites pas helm upgrade en prod sans lire le changelog du chart : les stacks observabilité changent vite (CRDs, dashboards, rules). Épingler une version (--version x.y.z) + planifier une fenêtre + valider en staging reste la base. Sur des clusters longs à vivre, vous finirez par gérer des migrations de CRDs : prévoyez-le dans votre runbook.

Le tuning le plus rentable : (1) réduire la cardinalité (labels inutiles, metrics trop détaillées), (2) ajuster retention et la taille de PV, (3) limiter les scrape intervals (tout n’a pas besoin de 15s), (4) fixer des requests/limits réalistes. Prometheus peut consommer beaucoup de RAM si vous scrapez beaucoup de targets avec de grosses règles d’agrégation. Faites du capacity planning : nombre de nœuds, mémoire disponible, et impact pendant les compactions.

Une routine d’exploitation simple (hebdo ou mensuelle) qui marche bien :

• vérifier l’occupation des PVC (Prometheus / Alertmanager / Grafana),
• vérifier le nombre de séries (prometheus_tsdb_head_series) et son évolution,
• lister les targets DOWN et comprendre si c’est du réseau, du RBAC, ou du label-matching,
• faire une revue des alertes “noisy” et les corriger (seuils, durée, inhibition, suppression),
• tester un restore logique (au minimum : exporter dashboards Grafana, sauvegarder config Alertmanager, et s’assurer que vos values Helm sont en Git).

Les incidents typiques sur Kubernetes OVHcloud :

• PV qui ne se bind pas (mauvaise StorageClass, quota, zone/affinité),
• pods “Pending” par manque de ressources (Grafana + Prometheus + exporters sur un petit cluster),
• targets DOWN car ServiceMonitor ne matche pas les labels (ou RBAC qui empêche la découverte cross-namespace),
• exposition externe accidentelle (Service LoadBalancer créé par défaut),
• upgrades cassés par une gestion floue des CRDs.

Deux commandes utiles quand vous suspectez un problème de PVC sur un cluster managé :

kubectl -n monitoring get pvc
kubectl -n monitoring describe pvc <nom-du-pvc>

Vous verrez rapidement si c’est un problème de classe de stockage, d’événements CSI, ou d’attente de provisionnement.

Si vous cherchez une grille de lecture “infra d’hébergement” (mutualisé vs VPS vs cloud, impacts sur observabilité et SLA), recoupez avec : https://www.expertise-prestashop.fr/2026/07/08/hebergement-e-commerce-mutualise-vps-cloud-ou-saas-compares/.

Enfin, si votre objectif final est d’avoir des dashboards exploitables par l’équipe (et pas juste “Grafana posé”), vous pouvez vous inspirer de votre existant Grafana côté VM, mais gardez en tête que l’installation Kubernetes a ses propres patterns (Secrets, Ingress, RBAC) : https://www.expertise-prestashop.fr/2026/07/03/grafana-sur-ubuntu-installation-apt-et-configuration-initiale/.