Pendant la plupart de la dernière décennie, l'observabilité avait un secret inconfortable : la contrainte principale sur ce que vous pouviez observer n'était pas technique mais financière. Les équipes exécutaient des clusters Elasticsearch dont les factures de stockage croissaient plus rapidement que leur trafic, et la réponse standard était de jeter les données — réduire la rétention de quatre-vingt-dix jours à sept, sampler les logs à dix pour cent, jeter complètement les sorties de debug. Puis, inévitablement, un incident arriverait dans le gap. Les données qui l'auraient expliqué avaient été rejetées pour économiser de l'argent, et l'action d'élémentaire du postmortem lisait « augmentez la rétention des logs », que personne n'a financé.
Les économies ont changé parce qu'une nouvelle génération d'outils a déplacé le stockage de logs des disques locaux coûteux au stockage d'objets bon marché — S3, GCS, Azure Blob. Quand les coûts de stockage sont un ordre de magnitude moins chers, la rétention cesse d'être une négociation de budget. Ce guide couvre ce changement : pourquoi l'ancienne architecture était coûteuse, comment le modèle de stockage d'objets fonctionne, et les outils qui l'implémentent — Quickwit pour la rétention searchable de logs et traces, OpenObserve comme plateforme observabilité complète, et Vector comme le pipeline qui les alimente.
Pourquoi l'ancienne architecture était coûteuse
Elasticsearch et les stacks construits dessus ont été conçus pour un cas d'usage exigeant : recherche full-text interactive sur des données qui changent, avec des résultats en millisecondes. Pour livrer cela, ils gardent les indices sur les disques locaux rapides attachés aux nœuds toujours actifs, répliquent chaque shard pour la durabilité et la disponibilité, et gardent les structures d'index substantielles en mémoire. Chacun de ces choix est raisonnable pour la recherche, et chacun est coûteux.
Les coûts s'aggrègent de manières qui surprennent les équipes. Le stockage est provisionné plutôt que consommé — vous payez pour les disques que vous les remplissiez ou non, et vous sur-provisionniez parce que manquer d'espace est une panne. La réplication multiplie cela par deux ou trois. Les nœuds doivent s'exécuter en continu même si la plupart des logs ne sont jamais lus après le jour où ils ont été écrits. Et l'échelle est couplée : avoir besoin de plus de stockage signifie ajouter des nœuds, ce qui signifie payer pour le CPU et la RAM que vous n'aviez pas besoin. Le résultat est une courbe de coût qui monte abruptement avec la rétention, ce qui est exactement pourquoi « réduire la rétention » est devenue le levier de contrôle des coûts standard.
Le désalignement plus profond est que les logs ne sont pas le workload pour lequel Elasticsearch a été optimisé. Les données log sont append-only — écrites une fois, jamais mises à jour. C'est overwhelmingly froid : la grande majorité n'est jamais interrogée, et la petite fraction qui l'est obtient interrogée pendant un incident, où quelques secondes de latence est parfaitement acceptable. Payer pour la recherche interactive milliseconde et la machinerie de document mutable sur les pétaoctets de données write-once que personne ne lit est l'erreur architecturale sous-jacente à la facture.
Le modèle de stockage d'objets
L'architecture plus nouvelle démarre de ces propriétés. Si les données sont append-only et la plupart froides, stockez-les dans le stockage d'objets — qui est environ un ordre de magnitude moins cher par téraoctet que le stockage block provisionné, est effectivement infini, et est durable par défaut sans que vous gériez la réplication. Puis découpler le calcul du stockage : exécutez les nœuds de query qui lisent depuis le stockage d'objets à la demande, et mettez-les à l'échelle indépendamment de combien de données vous retenez. Stocker une année de logs supplémentaires coûte uniquement le stockage, pas plus de nœuds.
Le catch, bien sûr, est que le stockage d'objets est lent par rapport au disque local — chaque lecture est une requête réseau avec latence significative. L'insight d'ingénierie qui rend cela fonctionne est que vous pouvez compenser avec le format et l'indexation. Les données sont écrites dans des formats columnar compressés (Parquet est courant) à côté des structures d'index qui permettent à une query de chercher uniquement les ranges de bytes qu'elle a réellement besoin, plutôt que de scanner tout. Le cache agressif garde les données chaudes proches. Le résultat est des queries qui retournent en secondes plutôt qu'en millisecondes — un trade-off qui est complètement acceptable pour la recherche de logs et complètement inacceptable pour une boîte de recherche faisant face à l'utilisateur, ce qui est précisément pourquoi cette architecture convient à l'observabilité et pas à la recherche générale.
Ce que cela achète, au-delà de l'argent, c'est un changement de comportement. Quand la rétention est bon marché, vous arrêtez de jeter proactivement les données, ce qui signifie que la réponse à l'incident suivant est plus probable d'exister toujours. C'est le vrai retour : pas une facture plus petite, mais moins d'enquêtes qui deviennent des impasses parce que l'évidence a été supprimée.
Quickwit : search construit pour les logs et traces
Quickwit est l'expression la plus pure de l'idée. C'est un moteur de recherche Rust conçu depuis le départ pour les données append-only sur le stockage d'objets — il n'a besoin ni de disque local pour les indices ni de machinerie d'état de cluster pour eux, parce que l'index vit dans S3 comme des splits immuables. Il fournit une recherche genuinely full-text (pas juste un filtrage basé sur les labels), expose une API de recherche compatible Elasticsearch qui facilite la migration, et sert comme un backend Jaeger natif pour les traces, ce qui le rend un fit naturel pour les équipes exécutant déjà OpenTelemetry.
Le sweet spot de Quickwit est le stockage bon marché, searchable, long-rétention pour les logs et traces où vous voulez la vraie capacité de search. La gestion de rétention devient triviale — expirer les vieilles données est juste supprimer les vieux splits. Son trade-off est la portée : c'est un moteur de recherche, pas une plateforme observabilité complète, donc vous amenez vos propres dashboards (Grafana), votre propre alerting, et votre propre stack de métriques. Pour les équipes qui ont déjà ces pièces et veulent fixer le coût de stockage spécifiquement, cette focus est une feature.
OpenObserve : la plateforme batteries-incluses
OpenObserve prend le même insight de stockage et enveloppe une plateforme complète autour. Elle gère les logs, les métriques, et les traces dans un système, stocke les données comme Parquet compressé dans le stockage d'objets, et s'expédie avec une UI built-in, l'interrogation SQL, les dashboards, et un moteur d'alerting — tout comme un binaire Rust unique qui est véritablement facile à mettre en place. Elle ingère OpenTelemetry nativement et supporte l'écriture distante Prometheus, donc elle s'insère dans l'instrumentation existante.
L'appel est la consolidation. Plutôt que d'exécuter un moteur de recherche plus Grafana plus une stack d'alerting plus un stockage de métriques séparé, vous exécutez une chose. Pour les petites et moyennes équipes spécialement, les économies opérationnelles peuvent importer plus que toute comparaison par-téraoctet — chaque composant supplémentaire dans une stack observabilité est quelque chose à upgrader, sécuriser, et déboguer à 3 du matin. Son trade-off est le standard pour les plateformes intégrées : moins de flexibilité que d'assembler les composants best-of-breed, et un écosystème plus jeune que les mondes Grafana ou Elastic. Choisissez-le quand la simplicité opérationnelle vaut plus que la modularité.
Vector : le pipeline qui rend la migration sûre
Aucun backend n'importe si vous ne pouvez pas avoir les données dedans, et c'est où Vector devient l'artisan silencieux. Vector est un pipeline haute performance, agnostique aux fournisseurs : il collecte les logs, métriques, et traces depuis n'importe quelle source, les remet en forme via les transformations écrites en VRL, et les livre à n'importe quel sink. Écrit en Rust, il utilise une fraction des ressources de Logstash ou Fluentd — ce qui importe parce qu'un agent s'exécute sur chaque nœud que vous possédez.
Sa valeur stratégique est qu'elle découple votre instrumentation de votre backend. Les applications et les agents livrent les données à Vector ; Vector décide où elles vont. Cela transforme une migration de backend d'un projet de ré-instrumentation flotte-entière en un changement de config — et, crucialement, cela vous permet de dual-write pendant une transition, envoyant les mêmes données à la fois à votre stack existant et à un nouveau afin que vous puissiez valider le replacement sur le vrai trafic avant de vous transformer. Les transformations de Vector coupent aussi le coût à la source : larguer les logs de debug, sampler les événements de haut volume, et redacter les PII avant le stockage tous réduisent ce que vous payez pour garder.
Adopter cela sans une migration risquée
Le chemin sensé est graduel, et Vector est ce qui le rend sûr. Commencez par mettre un pipeline devant votre stack existante. Déployez Vector, pointez vos sources vers lui, et faites-le envoyer à tout ce que vous exécutez aujourd'hui. Rien ne change fonctionnellement, mais vous avez gagné un point de contrôle — et vous pouvez immédiatement utiliser les transformations pour jeter le bruit et réduire les coûts actuels.
Puis dual-write vers un backend candidat. Ajoutez un deuxième sink pointant à Quickwit ou OpenObserve et laissez les données de production réelles circuler aux deux. Maintenant vous pouvez évaluer honnêtement : les queries que vous exécutez réellement sont-elles assez rapides ? La syntaxe de recherche couvre-t-elle vos besoins ? Quel est le coût de stockage vraiment à votre volume ? C'est une bien meilleure base pour une décision qu'un benchmark, et il coûte uniquement le stockage du nouveau backend pendant l'essai.
Changez la rétention avant de changer l'interrogation primaire. Un état intermédiaire low-risk est de garder les données de courte rétention chaudes où elles sont tandis que d'envoyer les données de longue rétention au stockage d'objets. Vous obtenez la victoire de coût sur la partie coûteuse (long rétention) sans parier votre réponse d'incident sur un système non-familier. Puis déplacez l'interrogation graduellement, en commençant par l'analyse non-urgente et en passant à la réponse d'incident une fois que l'équipe lui fait confiance. Et gardez la vieille stack en exécution jusqu'à ce que vous ayez vécu un incident réel sur le nouveau — le moment que vous découvrez si cela fonctionne est le moment que vous désirez le moins une surprise.
Ce que vous abandonnez, honnêtement
Chaque architecture échange quelque chose, et il vaut la peine d'être explicite sur ce que se déplacer vers le stockage d'objets coûte afin que la décision soit informée plutôt qu'enthousiaste.
Latency de query. Les lectures du stockage d'objets sont des requêtes réseau, donc les queries retournent en secondes plutôt que les réponses sub-secondes un index de disque local chaud peut livrer. Pour la recherche de logs pendant un incident c'est véritablement bon — vous lisez les résultats, pas en tapant à côté. Mais si vous avez construit les workflows qui dépendent de la filtration interactive instantanée, ou les dashboards qui tirent des dizaines de queries sur chaque refresh, ils se sentiront plus lentement. Testez vos patterns de query réels, pas un benchmark synthétique.
Maturité d'écosystème. Elasticsearch a une décennie d'intégrations accumulées, de tutoriels, de réponses Stack Overflow, et les ingénieurs qui le connaissent déjà. Les outils plus nouveaux ont des communautés plus petites, une documentation plus mince pour les cas extremes, et moins de gens que vous pouvez embaucher qui l'ont exécuté à l'échelle. Quand quelque chose casse à une heure inconfortable, cette différence est réelle. Les APIs compatibles Elasticsearch assouplissent la migration mais ne éliminent pas l'écart de connaissance.
Surface de feature. Elasticsearch fait beaucoup au-delà de la recherche de logs — agrégations complexes, jobs machine-learning, tuning de relevance, un riche query DSL. Les moteurs de logs de purpose-built font délibérément moins. Si vous vous appuyez sur ces capacités, vérifiez les équivalents existent avant de vous engager plutôt que de découvrir le gap mid-migration.
Infamiliarité opérationnelle. Vos runbooks, alertes, et instincts sont calibrés à votre stack actuel. Un nouveau backend signifie les nouveaux modes de défaillance et une période où l'équipe est plus lente à diagnostiquer ses problèmes. C'est l'argument le plus fort pour l'approche dual-write et pour garder la vieille stack tournant au-travers d'au moins un incident réel — vous voulez que la courbe d'apprentissage se produise tandis que vous avez toujours une fallback.
Aucun de ceux-ci ne pèsent une réduction de coût d'un ordre de magnitude pour la plupart des équipes, particulièrement celles supprimant actuellement les données qu'elles souhaiteraient avoir. Mais ce sont la raison de migrer délibérément plutôt que toute d'un coup.
Le résultat
L'observabilité est devenue dramatiquement moins chère parce que les outils ont enfin correspondu au workload. Les logs sont append-only et la plupart froides, donc les stocker sur les disques locaux répliqués, toujours-on optimisés pour la recherche milliseconde mutable était payer une large prime pour les propriétés que les données n'ont pas besoin. Se déplacer vers le stockage d'objets avec les formats columnar et l'indexation intelligente échange les millisecondes pour les secondes — irrélévant pour la recherche de logs — et coupe le coût de stockage par un ordre de magnitude. Quickwit le livre comme un magasin log et trace focused, searchable, avec un backend Jaeger ; OpenObserve le livre comme une plateforme consolidée avec l'UI, les dashboards, et l'alerting built-in ; et Vector est le pipeline qui découple votre instrumentation de chacun, rendant l'adoption un changement de config et un dual-write plutôt qu'une migration. Mettre le pipeline d'abord, dual-write pour évaluer sur le trafic réel, déplacez la long rétention avant l'interrogation chaude, et arrêtez de supprimer les données qui expliquent vos incidents.
Références et ressources
Outils
- Quickwit et GitHub
- OpenObserve et GitHub
- Vector et VRL reference
Contexte et analyse
Cheatsheets 1337skills liées