Découvrez pourquoi les bases de données temporelles alimentent les métriques, la surveillance et l'observabilité — requêtes plus rapides, meilleure compression, prise en charge de la haute cardinalité et des alertes fiables.
Les métriques sont des nombres qui décrivent ce que fait votre système — des mesures que vous pouvez tracer, comme la latence des requêtes, le taux d'erreur, l'utilisation CPU, la profondeur de file ou les utilisateurs actifs.
La surveillance (monitoring) consiste à collecter ces mesures, les afficher sur des tableaux de bord et définir des alertes quand quelque chose va mal. Si le taux d'erreur d'un service de checkout monte en flèche, la surveillance doit vous le signaler rapidement et clairement.
L'observabilité va plus loin : c'est la capacité à comprendre pourquoi quelque chose arrive en regardant plusieurs signaux ensemble — typiquement métriques, logs et traces. Les métriques indiquent ce qui a changé, les logs disent ce qui s'est passé, et les traces montrent où le temps a été passé à travers les services.
Les données séries temporelles sont « valeur + timestamp », répétées en continu.
Cette dimension temporelle change la façon dont on utilise les données :
Une base de données séries temporelles (TSDB) est optimisée pour ingérer beaucoup de points horodatés, les stocker efficacement et les interroger rapidement sur des plages temporelles.
Une TSDB ne réparera pas magiquement une instrumentation manquante, des SLO mal définis ou des alertes bruyantes. Elle ne remplace pas non plus les logs et les traces ; elle les complète en rendant les workflows de métriques fiables et économiques.
Imaginez que vous tracez le p95 de votre API chaque minute. À 10:05 il passe de 180 ms à 900 ms et y reste. La surveillance déclenche une alerte ; l'observabilité vous aide à relier ce pic à une région, un endpoint ou un déploiement spécifique — en partant de la tendance métrique et en creusant les signaux sous-jacents.
Les métriques séries temporelles ont une forme simple, mais leur volume et leurs modes d'accès les rendent particulières. Chaque point est typiquement timestamp + labels/tags + valeur — par exemple : « 2025-12-25 10:04:00Z, service=checkout, instance=i-123, p95_latency_ms=240 ». Le timestamp ancre l'événement dans le temps, les labels décrivent qui l'a émis, et la valeur est ce que vous voulez mesurer.
Les systèmes de métriques n'écrivent pas par lots occasionnels. Ils écrivent en continu, souvent toutes les quelques secondes, depuis de nombreuses sources. Cela crée un flux de nombreuses petites écritures : compteurs, jauges, histogrammes et résumés qui arrivent sans cesse.
Même des environnements modestes peuvent produire des millions de points par minute quand on multiplie intervalles de collecte, hôtes, conteneurs, endpoints, régions et flags fonctionnels.
Contrairement aux bases transactionnelles où l'on récupère « la dernière ligne », les utilisateurs de séries temporelles demandent généralement :
Cela signifie que les requêtes communes sont des scans de plage, des rollups (p. ex. 1s → moyennes 1m) et des agrégations comme percentiles, taux et sommes regroupées.
Les données séries temporelles révèlent des motifs difficiles à remarquer dans des événements isolés : pics (incidents), saisonnalité (cycles journaliers/hebdomadaires) et tendances longues (augmentation de capacité, régressions progressives). Une base de données qui comprend le temps rend le stockage de ces flux plus efficace et les requêtes plus rapides pour les dashboards et les alertes.
Une TSDB est une base conçue spécifiquement pour les données ordonnées par le temps — des mesures qui arrivent en continu et sont principalement interrogées par plage temporelle. En surveillance, cela signifie des métriques comme l'utilisation CPU, la latence des requêtes, le taux d'erreur ou la profondeur de file, chacune enregistrée avec un timestamp et un ensemble d'étiquettes (service, région, instance, etc.).
À la différence des bases généralistes optimisées pour de nombreux patterns d'accès, les TSDB optimisent la charge de travail la plus courante en monitoring : écrire de nouveaux points au fil du temps et lire rapidement l'historique récent. Les données sont souvent organisées en blocs/chunks temporels pour que le moteur puisse scanner « les 5 dernières minutes » ou « les 24 dernières heures » efficacement sans toucher aux données non pertinentes.
Les métriques sont souvent numériques et évoluent progressivement. Les TSDB exploitent cela avec des techniques d'encodage et de compression spécialisées (par ex. encodage des deltas entre timestamps adjacents, run-length, stockage compact pour ensembles d'étiquettes répétées). Résultat : vous conservez plus d'historique pour le même budget de stockage, et les requêtes lisent moins d'octets sur disque.
Les données de monitoring sont majoritairement append-only : on met rarement à jour de vieux points ; on ajoute des nouveaux. Les TSDB s'appuient sur ce pattern avec des écritures séquentielles et une ingestion par lots. Cela réduit les I/O aléatoires, diminue l'amplification d'écriture et stabilise l'ingestion même quand de nombreuses métriques arrivent en même temps.
La plupart des TSDB proposent des primitives adaptées au monitoring et aux dashboards :
Même si la syntaxe diffère entre produits, ces patterns forment la base pour construire des tableaux de bord et alimenter les évaluations d'alerte de façon fiable.
La surveillance est un flux de petits faits qui ne s'arrête jamais : ticks CPU toutes les quelques secondes, comptes de requêtes chaque minute, profondeur de file toute la journée. Une TSDB est construite pour ce pattern — ingestion continue plus questions « que s'est-il passé récemment ? » — elle paraît donc souvent plus rapide et plus prévisible qu'une base généraliste pour les métriques.
La plupart des questions opérationnelles sont des requêtes de plage : « montre-moi les 5 dernières minutes », « compare aux 24 dernières heures », « qu'est-ce qui a changé depuis le déploiement ? » Le stockage et l'indexation d'une TSDB sont optimisés pour scanner efficacement des plages temporelles, ce qui garde les graphiques réactifs même si le dataset grossit.
Les tableaux de bord et le monitoring SRE reposent davantage sur des agrégations que sur des points bruts. Les TSDB facilitent généralement les calculs métriques courants :
Ces opérations sont essentielles pour transformer des échantillons bruités en signaux exploitables pour l'alerte.
Les tableaux de bord ont rarement besoin de chaque datapoint brut indéfiniment. Les TSDB supportent souvent le bucketing temporel et les rollups, pour conserver des données haute-résolution pour les périodes récentes et pré-agréger les données anciennes pour les tendances long terme. Cela maintient les requêtes rapides et aide à contrôler le stockage sans perdre la vue d'ensemble.
Les métriques n'arrivent pas par lots ; elles arrivent continuellement. Les TSDB sont conçues pour que les charges d'écriture intensives n'altèrent pas trop rapidement les performances de lecture, garantissant que les requêtes « est-ce que quelque chose est cassé maintenant ? » restent fiables durant les pics de trafic et les incidents.
Les métriques sont puissantes quand vous pouvez les découper par labels (aussi appelés tags ou dimensions). Une métrique http_requests_total peut être enregistrée avec des dimensions comme service, region, instance et endpoint — pour répondre à des questions comme « l'UE est-elle plus lente que les US ? » ou « une instance se comporte mal ? »
La cardinalité est le nombre de séries temporelles uniques créées par vos métriques. Chaque combinaison unique de valeurs d'étiquettes est une série distincte.
Par exemple, si vous suivez une métrique avec :
…vous avez déjà 20 × 5 × 200 × 50 = 1 000 000 séries temporelles pour cette unique métrique. Ajoutez quelques labels supplémentaires (code de statut, méthode, type d'utilisateur) et cela peut dépasser ce que votre stockage et moteur de requête peuvent gérer.
La haute cardinalité échoue rarement en douceur. Les premiers points douloureux sont souvent :
C'est pourquoi la tolérance à la haute cardinalité est un différenciateur clé : certains systèmes la gèrent, d'autres deviennent instables ou coûteux rapidement.
Une bonne règle : utilisez des labels bornés et à variabilité faible à moyenne, et évitez les labels effectivement non bornés.
Préférez :
service, region, cluster, environmentinstance (si la taille du parc est contrôlée)endpoint seulement si c'est un template de route normalisé (ex. /users/:id, pas /users/12345)Évitez :
Si vous avez besoin de ces détails, conservez-les dans les logs ou les traces et liez depuis une métrique via un label stable. Ainsi votre TSDB reste rapide, vos tableaux de bord utilisables et vos alertes ponctuelles.
Conserver les métriques « pour toujours » paraît séduisant — jusqu'à ce que la facture de stockage augmente et que les requêtes ralentissent. Une TSDB vous aide à garder les données nécessaires, au niveau de détail nécessaire, pour la durée nécessaire.
Les métriques sont naturellement répétitives (mêmes séries, intervalle d'échantillonnage régulier, petites variations entre points). Les TSDB exploitent cela avec des compressions dédiées, souvent en conservant de longues périodes à une fraction de la taille brute. Cela vous permet de conserver plus d'historique pour l'analyse de tendance (planification de capacité, motifs saisonniers, « qu'est-ce qui a changé depuis le trimestre dernier ? ») sans payer des disques proportionnels.
La rétention est simplement la règle de durée de conservation des données.
La plupart des équipes scindent la rétention en deux couches :
Cette approche évite que les données ultra-granulaires d'hier deviennent l'archive coûteuse de l'année prochaine.
Le downsampling (ou rollups) remplace de nombreux points bruts par moins de points résumés — typiquement avg/min/max/count sur un bucket temporel. Appliquez-le quand :
Certaines équipes downsample automatiquement après la fenêtre brute ; d'autres gardent le brut plus longtemps pour les services « chauds » et downsample plus vite pour les métriques bruyantes ou de faible valeur.
Le downsampling économise du stockage et accélère les requêtes longue portée, mais vous perdez du détail. Par exemple, un court pic CPU peut disparaître dans une moyenne horaire, tandis que des rollups min/max peuvent préserver qu'« il s'est passé quelque chose » sans garder l'instant précis ni la fréquence.
Une règle pratique : conservez le brut assez longtemps pour déboguer les incidents récents, et conservez des rollups assez longs pour répondre aux questions produit et capacité.
Les alertes ne valent que par la qualité des requêtes qui les sous-tendent. Si votre système de monitoring ne peut répondre rapidement et de façon constante à « ce service est-il sain maintenant ? », vous manquerez des incidents ou serez réveillé pour du bruit.
La plupart des règles d'alerte se résument à quelques motifs :
rate() sur des compteurs.\n- Vérifications de type anomalie : « la latence est inhabituellement élevée par rapport à l'heure/jour précédent(e) », ou « le trafic a chuté en dessous de l'attendu ». Elles comparent généralement une fenêtre courante à une baseline.Une TSDB compte ici parce que ces requêtes doivent scanner rapidement les données récentes, appliquer correctement les agrégations et rendre les résultats dans les temps.
Les alertes ne sont pas évaluées sur un seul point ; elles le sont sur des fenêtres (par ex. « les 5 dernières minutes »). De petits problèmes de timing peuvent changer les résultats :
Les alertes bruyantes viennent souvent de données manquantes, d'un échantillonnage irrégulier ou de seuils trop sensibles. Le flapping — basculement rapide entre firing et resolved — signifie généralement que la règle est trop proche de la variance normale ou que la fenêtre est trop courte.
Traitez le « pas de données » explicitement (est-ce un problème, ou un service inactif ?), et préférez des alertes basées sur des taux/ratios plutôt que des comptes bruts quand le trafic varie.
Chaque alerte doit pointer vers un tableau de bord et un runbook court : quoi vérifier en premier, à quoi ressemble le « bon » fonctionnement et comment atténuer. Même un simple lien /runbooks/service-5xx et un lien vers un dashboard peuvent réduire drastiquement le temps de réponse.
L'observabilité combine généralement trois types de signaux : métriques, logs et traces. Une TSDB est le stockage spécialisé pour les métriques — points de données indexés par le temps — parce qu'elle est optimisée pour les agrégations rapides, les rollups et les questions « qu'est-ce qui a changé dans les 5 dernières minutes ? ».
Les métriques sont la première ligne de défense. Elles sont compactes, peu coûteuses à interroger à grande échelle et idéales pour tableaux de bord et alerting. C'est ainsi que les équipes suivent des SLO comme « 99,9 % des requêtes sous 300 ms » ou « taux d'erreur sous 1 % ».
Une TSDB alimente typiquement :
Les métriques disent **qu'**il y a un problème, mais pas toujours pourquoi.
En pratique, une TSDB est au centre du monitoring « signal rapide », tandis que les systèmes de logs et traces servent de preuves détaillées consultées une fois que les métriques ont indiqué où regarder.
Les données de monitoring sont les plus précieuses pendant un incident — précisément quand les systèmes sont sous stress et que les tableaux de bord sont fortement sollicités. Une TSDB doit continuer à ingérer et répondre aux requêtes même lorsque des parties de l'infrastructure sont dégradées, sinon vous perdez la chronologie nécessaire pour diagnostiquer et récupérer.
La plupart des TSDB montent horizontalement en shardant les données entre nœuds (souvent par plages temporelles, nom de métrique, ou hash d'étiquettes). Cela répartit la charge d'écriture et permet d'ajouter de la capacité sans réarchitecturer la surveillance.
Pour rester disponible quand un nœud échoue, les TSDB s'appuient sur la réplication : écrire des copies des mêmes données sur plusieurs nœuds ou zones. Si une réplique devient indisponible, les lectures et écritures peuvent continuer sur des répliques saines. Les bons systèmes supportent aussi le failover pour que les pipelines d'ingestion et les routeurs de requêtes redirigent automatiquement le trafic avec des interruptions minimes.
Le trafic métrique est en rafales — déploiements, autoscaling ou pannes peuvent multiplier les échantillons. Les TSDB et leurs collecteurs utilisent généralement du buffering d'ingestion (queues, WALs, spool disque local) pour absorber les pics courts.
Quand la TSDB ne suit pas, le backpressure est important. Plutôt que de perdre silencieusement des données, le système devrait signaler aux clients de ralentir, prioriser les métriques critiques ou réduire l'ingestion non essentielle de façon contrôlée.
Dans les grandes organisations, une TSDB sert souvent plusieurs équipes et environnements (prod, staging). Les fonctionnalités multi-tenant — namespaces, quotas par locataire, limites de requêtes — aident à empêcher qu'un dashboard bruyant ou un job mal configuré n'affecte tout le monde. L'isolation claire simplifie aussi le chargeback et le contrôle d'accès à mesure que le programme de monitoring grandit.
Les métriques paraissent souvent « non sensibles » car ce sont des nombres, mais les labels et métadonnées peuvent révéler beaucoup : identifiants clients, noms d'hôtes internes, ou indices d'incidents. Une bonne configuration de TSDB traite les métriques comme n'importe quel jeu de données production.
Commencez par l'essentiel : chiffrez le trafic entre agents/collecteurs et votre TSDB avec TLS, et authentifiez chaque écrivain. La plupart des équipes utilisent des tokens, clefs API ou des identifiants éphémères fournis par service ou environnement.
Règle pratique : si un token fuit, le périmètre d'impact doit être réduit. Préférez des identifiants d'écriture séparés par équipe, cluster ou namespace — pour pouvoir révoquer sans tout casser.
Lire des métriques peut être aussi sensible que les écrire. Votre TSDB devrait supporter un contrôle d'accès correspondant à l'organisation :
Cherchez un contrôle d'accès basé sur les rôles et un scoping par projet, tenant ou namespace. Cela réduit les expositions accidentelles et aligne dashboards et alertes avec la propriété.
Beaucoup de « fuites métriques » arrivent via les labels : user_email, customer_id, URLs complètes ou fragments de payloads. Évitez d'injecter des données personnelles ou des identifiants uniques dans les labels. Pour le debugging au niveau utilisateur, utilisez des logs ou traces avec des contrôles plus stricts et une rétention plus courte.
Pour la conformité, vous devrez peut-être répondre : qui a accédé à quelles métriques et quand ? Privilégiez les TSDB (et les gateways associées) qui génèrent des logs d'audit pour l'authentification, les changements de configuration et l'accès en lecture — pour que les enquêtes soient fondées sur des preuves.
Choisir une TSDB dépend moins d'un nom de produit que de l'adéquation au profil métrique : combien de données vous générez, comment vous les interrogez, et ce dont votre équipe d'astreinte a besoin à 2 h du matin.
Avant de comparer offres commerciales ou open-source, répondez à :
TSDB gérées réduisent la maintenance (upgrades, scalabilité, sauvegardes), souvent avec des SLA prévisibles. Le compromis est le coût, moins de contrôle et parfois des contraintes sur les fonctionnalités ou l'export des données.
TSDB auto-hébergées peuvent coûter moins cher à grande échelle et offrir plus de flexibilité, mais vous assumez la planification de capacité, le tuning et la réponse aux incidents de la base elle-même.
Une TSDB ne vit rarement seule. Confirmez la compatibilité avec :
Timeboxez un PoC (1–2 semaines) et définissez des critères :
La « meilleure » TSDB est celle qui répond à vos exigences de cardinalité et de requête tout en maintenant coût et charge opérationnelle acceptables.
Une TSDB compte pour l'observabilité parce qu'elle rend les métriques utilisables : requêtes rapides pour tableaux de bord, évaluations d'alerte prévisibles et capacité à gérer beaucoup de données étiquetées (y compris des charges haute-cardinalité) sans transformer chaque nouveau label en surprise de coût et de performance.
Commencez petit et rendez les progrès visibles :
Si vous développez et déployez rapidement (par exemple en générant une app React + backend Go avec PostgreSQL), traitez l'observabilité comme faisant partie du chemin de livraison — pas comme une réflexion après coup. Des plateformes comme Koder.ai aident les équipes à itérer vite, mais vous voulez des noms de métriques cohérents, des labels stables et un bundle dashboard/alerte standard pour que les nouvelles fonctionnalités n'arrivent pas « obscures » en production.
Rédigez une page de guide simple et facile à suivre :
service_component_metric (ex. checkout_api_request_duration_seconds).\n- Unités : inclure toujours secondes, octets ou pourcentage.\n- Labels : définir les valeurs autorisées et éviter les labels non bornés (ex. IDs utilisateur bruts).\n- Ownership : chaque dashboard/alerte a un propriétaire et un cycle de revue.Instrumentez d'abord les chemins de requête et les jobs background clés, puis étendez la couverture. Après avoir établi vos tableaux de bord de référence, faites une courte « review d'observabilité » dans chaque équipe : les graphiques répondent-ils à « qu'est-ce qui a changé ? » et « qui est affecté ? » Si non, affinez les labels et ajoutez un petit nombre de métriques à forte valeur plutôt que d'augmenter le volume aveuglément.
Les métriques sont des mesures numériques (latence, taux d'erreur, CPU, profondeur de file). La surveillance consiste à les collecter, les afficher et déclencher des alertes quand elles montrent un problème. L'observabilité est la capacité d'expliquer pourquoi elles montrent un problème en combinant les métriques avec les logs (ce qui s'est passé) et les traces (où le temps a été passé entre services).
Les données temporelles sont des paires continues valeur + timestamp, donc on pose surtout des questions sur des plages (les 15 dernières minutes, avant/après un déploiement) et on s'appuie beaucoup sur des agrégations (moyenne, p95, taux) plutôt que sur la lecture de lignes individuelles. Cela rend la disposition du stockage, la compression et la performance des scans temporels bien plus importantes que dans un usage transactionnel classique.
Une TSDB est optimisée pour les charges de surveillance : débits d'écriture élevés, ingestion majoritairement append-only, et requêtes rapides sur des plages temporelles avec des fonctions usuelles (bucketing, rollups, taux, percentiles, group-by labels). Elle vise à garder tableaux de bord et évaluations d'alertes réactifs à mesure que le volume de données augmente.
Non. Une TSDB améliore les mécaniques de stockage et de requêtage des métriques, mais il vous faut aussi :
Sans cela, vous pouvez avoir des tableaux de bord rapides qui n'aident pas à agir.
Les métriques offrent une détection rapide et bon marché et permettent de suivre les tendances, mais elles manquent de détails. Gardez :
Utilisez les métriques pour détecter et restreindre le périmètre, puis basculez sur logs/traces pour les éléments de preuve détaillés.
La cardinalité est le nombre de séries temporelles uniques créées par les combinaisons d'étiquettes. Elle explose quand vous ajoutez des dimensions comme instance, endpoint, code de statut ou (pire) des IDs non bornés. La haute cardinalité provoque souvent :
C'est souvent le premier point qui rend un système de métriques instable ou coûteux.
Privilégiez des étiquettes aux valeurs bornées et stables :
La rétention contrôle le coût et la vitesse des requêtes. Une configuration courante :
Le downsampling échange précision contre stockage moins coûteux et requêtes plus rapides ; conserver min/max en plus des moyennes peut préserver le signal « quelque chose s'est passé ».
La plupart des règles d'alerte s'appuient sur des plages et des agrégations (seuils, taux/ratios, comparaisons d'anomalies). Si les requêtes sont lentes ou l'ingestion retardée, vous aurez des alertes instables, manquées ou retardées. Mesures pratiques :
/runbooks/service-5xx)Validez l'adéquation par un déploiement mesurable :
Un PoC court avec des tableaux de bord et règles réelles vaut souvent mieux qu'une simple liste de fonctionnalités.
serviceregionclusterenvironmentendpointinstance si le parc change très viteMettez ces identifiants haute-détail dans les logs/traces et gardez les labels de métriques pour le regroupement et le triage.