Thanos : ce qu'un seul Prometheus ne peut pas garder
Un Prometheus local garde ses métriques quelques semaines, sur son propre disque. Thanos déporte la rétention vers de l'object storage et unifie plusieurs clusters.
Une alerte qu'on ignore vaut moins que pas d'alerte du tout. Ce parcours couvre ce qui rend une observabilité exploitable en astreinte plutôt que décorative.
18 articles · 4 sections
Instrumenter sans faire exploser le coût de stockage.
Un Prometheus local garde ses métriques quelques semaines, sur son propre disque. Thanos déporte la rétention vers de l'object storage et unifie plusieurs clusters.
Un label à valeurs non bornées (ID de requête, IP client) multiplie les séries stockées à l'infini. La cardinalité, pas le nombre de métriques, dimensionne Prometheus.
Le choix entre Prometheus auto-hébergé et une plateforme SaaS n'est pas idéologique. Un calcul de coût total : infrastructure et exploitation contre facturation à l'ingestion.
Golden signals, méthode RED et histogramme plutôt que summary pour la latence : comment instrumenter une application Prometheus, avec les requêtes PromQL.
Centraliser sans tout garder, et retrouver la ligne qui compte.
Un disque qui se remplit sans qu'aucun fichier visible ne l'explique cache souvent un log renommé par rotation, mais toujours ouvert par un processus qui écrit dans le vide.
Pourquoi Loki n'indexe pas le contenu des logs, ce que ça change pour le coût de stockage et LogQL, et les pièges de cardinalité qui annulent l'économie.
Suivre une requête à travers les services, et savoir ce que ça coûte.
Un Collector par nœud limite la collecte au strict local. Le tail-sampling qui a besoin de voir une trace complète réclame un second niveau, le gateway.
Pourquoi le tracing complète métriques et logs sur une requête qui traverse dix services, comment le contexte se propage, et le piège du sampling.
Alerter sur ce qui affecte l’utilisateur, pas sur ce qui bouge.
Confier le rôle d'incident commander à la personne la plus technique mélange coordination et débogage. Séparer les deux accélère la résolution.
Le toil a une définition précise : travail manuel, répétitif, automatisable, tactique et sans valeur durable, les critères qui décident quoi automatiser en premier.
Blameless sépare la reconstitution des faits de l'évaluation individuelle, ça n'efface pas le problème. Nommer une personne dans le récit d'incident casse la confiance.
Sans Alertmanager bien configuré, un seul incident déclenche des dizaines de notifications identiques pour la même cause, une tempête qui noie le vrai signal.
Un PodDisruptionBudget jamais testé est une hypothèse, pas une garantie. Le chaos engineering provoque la panne en conditions contrôlées pour le vérifier.
kubectl top pod et le HPA n'ont aucune donnée à lire sans metrics-server installé. Comment il fonctionne, et l'erreur de certificat la plus fréquente à l'installation.
Un Deployment ne garantit aucune répartition par nœud. DaemonSet en garantit une exacte, le mécanisme derrière la plupart des agents d'infrastructure.
Un SLO et un budget d'erreur ne disent pas quand alerter. La méthode burn-rate multi-fenêtres, simplifiée pour une PME, pour agir avant l'épuisement du budget.
Pourquoi les métriques internes ne suffisent jamais, comment blackbox_exporter sonde HTTP, TLS et expiration de certificats, et le piège du faux positif réseau.
Pourquoi alerter sur les symptômes et non les causes, comment régler la clause for et le label severity, et une mauvaise règle Prometheus réécrite proprement.