Les yeux sur le cluster : une observabilité open source à petit budget

Le code sans visibilité, c'est de la conduite de nuit sans phares. Vous pouvez avoir le meilleur cluster K3s du monde (voir l'article 01), si vous ne savez pas ce qui s'y passe, vous êtes en danger.

Dans l'écosystème cloud, Datadog est une référence : la plateforme réunit de nombreux signaux, réduit le travail d'intégration et devient particulièrement utile quand les services et les équipes se multiplient. Mais Momentum était alors une startup de deux personnes avec un cluster de trois nœuds et un budget d'infrastructure minimal. Notre besoin immédiat était plus étroit que celui d'une organisation opérant des dizaines de services.

Nous avons donc choisi de construire une première stack open source. L'objectif : garder le contrôle sur le stockage et la rétention, éviter un abonnement disproportionné à ce stade et apprendre précisément comment circulent nos métriques, logs et alertes. Le coût de licence est nul, mais l'exploitation, les ressources du cluster et le temps d'ingénierie ne le sont évidemment pas.

Voici comment nous avons déployé la stack PLG (Prometheus, Loki, Grafana), et quels compromis accompagnent ce choix.

Pourquoi une stack open source dans notre contexte ?

La grille tarifaire officielle de Datadog affiche notamment son offre Infrastructure Pro à 15 dollars par hôte et par mois avec un engagement annuel. Les logs, l'APM, les conteneurs et certains volumes de métriques suivent leurs propres unités de facturation. La facture exacte dépend donc fortement de l'usage, de la rétention et du contrat ; elle ne se résume pas à multiplier un nombre de serveurs par un tarif unique.

Pour nos trois nœuds, le seul socle de supervision des hôtes représentait déjà environ 45 dollars par mois avant les autres produits, face à une infrastructure complète facturée autour de 50 euros. À cette échelle et avec du temps d'ingénierie disponible, nous avons préféré investir dans une solution auto-hébergée. Ce calcul serait très différent pour une équipe plus grande : quelques heures d'exploitation, une corrélation manuelle plus lente ou un incident mal diagnostiqué peuvent rapidement coûter davantage que l'abonnement à une plateforme managée.

La Stack PLG : Le Trio Gagnant

Nous avons également écarté la stack ELK (Elasticsearch, Logstash, Kibana), dont les besoins en ressources et l'exploitation nous semblaient trop importants pour ce petit cluster. L'écosystème PLG est courant dans Kubernetes et correspondait mieux à nos contraintes :

Prometheus (Metrics) : Le standard absolu. Il "scrape" (aspire) les métriques exposées par vos applications et vos nœuds. CPU, RAM, Latence HTTP, tout y passe.
Loki (Logs) : Le "Prometheus pour les logs". Contrairement à Elasticsearch qui indexe tout le texte (lourd), Loki n'indexe que les métadonnées (labels). C'est ultra-léger et rapide.
Grafana (Visualisation) : Le tableau de bord unique pour tout voir.

Partie 1 : L'Installation (Helm is King)

On ne réinvente pas la roue. On utilise le chart Helm communautaire kube-prometheus-stack. C'est un package tout-en-un qui installe Prometheus, AlertManager, Grafana, et les "Exporters" (Node Exporter pour le hardware, Kube State Metrics pour K8s).

Voici notre values.yaml épuré pour la production :

# prometheus-values.yaml
grafana:
  adminPassword: "CHANGE_ME_PLEASE"
  persistence:
    enabled: true
    size: 10Gi
  ingress:
    enabled: true
    hosts:
      - grafana.momentum-coach.com

prometheus:
  prometheusSpec:
    retention: 15d
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi

alertmanager:
  enabled: true

Une commande et tout est là :

helm install monitoring prometheus-community/kube-prometheus-stack -f prometheus-values.yaml -n monitoring

Partie 2 : Les Logs avec Loki et S3 (L'astuce stockage)

Conserver durablement les logs sur les disques locaux des nœuds aurait compliqué la gestion de la capacité et la reprise après incident. L'architecture moderne de Loki permet de stocker les "chunks" de logs directement dans un Object Storage S3 (AWS S3, Scaleway Object Storage, MinIO).

À notre faible volume, ce stockage ne représente que quelques centimes par mois. Il faudra néanmoins surveiller son évolution, définir une politique de rétention et tenir compte des coûts de requêtes et de transfert.

Voici la configuration Loki pour utiliser S3 :

# loki-values.yaml
loki:
  auth_enabled: false
  storage:
    bucketNames:
      chunks: momentum-loki-chunks
      ruler: momentum-loki-ruler
      admin: momentum-loki-admin
    type: s3
    s3:
      endpoint: s3.fr-par.scw.cloud # Exemple Scaleway
      region: fr-par
      secretAccessKey: "${S3_SECRET_KEY}"
      accessKeyId: "${S3_ACCESS_KEY}"

Côté application, on déploie Promtail (un agent léger) sur chaque nœud via un DaemonSet. Il lit /var/log/containers/*.log, attache les labels Kubernetes (pod name, namespace) et envoie tout à Loki.

Partie 3 : Alerting (Dormir tranquille)

Avoir des graphiques, c'est joli. Être réveillé quand ça brûle, c'est mieux. Prometheus utilise AlertManager.

Nous avons défini des règles critiques. Si un nœud est sous pression ou qu'un Pod redémarre en boucle, on veut le savoir immédiatement.

Exemple de PrometheusRule :

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: momentum-critical-alerts
  namespace: monitoring
  labels:
    release: monitoring
spec:
  groups:
  - name: kubernetes-apps
    rules:
    - alert: PodCrashLooping
      expr: rate(kube_pod_container_status_restarts_total[15m]) * 60 * 5 > 0
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping."
    
    - alert: HighNodeCPU
      expr: instance:node_cpu:rate:sum > 0.9
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Node {{ $labels.node }} CPU usage is above 90%"

La destination : Discord

À deux, nous avons choisi Discord comme destination initiale plutôt qu'une plateforme dédiée à l'astreinte. C'est suffisant tant que le nombre d'alertes et de personnes reste faible ; avec plusieurs rotations, des escalades ou des contraintes fortes de traçabilité, un outil de gestion d'incidents deviendrait plus approprié. AlertManager peut envoyer les alertes directement via un Webhook Discord.

# alertmanager-config.yaml
global:
  resolve_timeout: 5m

route:
  receiver: 'discord-notifications'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
- name: 'discord-notifications'
  discord_configs:
  - webhook_url: 'https://discord.com/api/webhooks/...'
    send_resolved: true

Résultat : une notification dans notre canal #devops-alerts dès qu'un problème survient, puis une autre quand il est résolu.

Conclusion : un choix adapté à une phase, pas une vérité universelle

Avec cette stack, nous avons :

Une visibilité ciblée : métriques système et applicatives utiles à notre exploitation actuelle.
Une rétention maîtrisée : logs stockés sur S3 avec une politique que nous contrôlons.
Une première boucle de réaction : alertes envoyées en temps réel sur Discord.
Un coût direct limité : aucune licence, mais du CPU, de la mémoire, du stockage et du temps de maintenance.

En contrepartie, nous sommes responsables des mises à jour, de la disponibilité de la stack, de sa sécurité, de la capacité de stockage et de la qualité des alertes. Une plateforme managée reprend de la valeur dès que le nombre de services augmente, que plusieurs équipes doivent collaborer ou qu'il devient essentiel de corréler rapidement métriques, logs, traces et incidents.

Pour Momentum, l'open source était le bon compromis à ce moment-là : davantage de contrôle et d'apprentissage en échange d'une charge opérationnelle assumée. Le bon choix d'observabilité dépend moins d'une opposition entre SaaS et open source que du contexte, de l'échelle et du coût total d'exploitation.

Dans le prochain article, on parlera de CI/CD : Comment passer du code sur mon laptop à la production en un git push, sans interruption de service.