Quand les TSDS rencontrent l'ILM : Concevoir des flux de données temporelles qui ne rejettent pas les données en retard

Récemment, j'ai migré le cluster de métriques d'un client d'une architecture "tout en accès direct" vers une architecture en mode "chaud/froid/gelé". J'avais pourtant effectué cette migration des dizaines de fois auparavant. Quelques minutes plus tard, Logstash a complètement cessé de transmettre les données.

Elasticsearch rejetait les métriques arrivant en retard. Ces rejets ont provoqué un retard dans le pipeline, entraînant davantage de données en retard, ce qui a déclenché encore plus de rejets. Finalement, le pipeline s'est complètement arrêté.

Nous avons dû restaurer les données à partir d'un snapshot, les réindexer et repenser le pipeline d'ingestion pour pouvoir les récupérer.

La cause principale n'était pas la gestion du cycle de vie des index (ILM) elle-même. C'étaient les flux de données temporelles (TSDS) et la manière dont ils imposent des index sous-jacents limités dans le temps.

Les TSDS peuvent réduire les besoins de stockage des métriques de 40 à 70 %, mais les modifications architecturales qui optimisent leur fonctionnement influent également sur l'évolution des index. Ces changements sont importants lors de la conception de politiques ILM ou lorsque vos pipelines d'ingestion sont susceptibles de générer des données arrivant en retard.

RÉSUMÉ

Lors de l'utilisation de TSDS :

• Les index sous-jacents acceptent uniquement les documents compris dans une fenêtre temporelle spécifique.
• Si des données en retard arrivent après qu'un index passe en mode froid ou gelé, Elasticsearch rejette ces documents ou les achemine vers le stockage des échecs, si configuré.

Règle de conception :

Qu'est-ce qu'un flux de données temporelles ?

Un flux de données temporelles (TSDS) est un flux de données spécialisé optimisé pour les données de métriques. Les données sont acheminées de manière à ce que les documents associés soient situés dans les mêmes partitions, optimisant ainsi la requête et la récupération. Voici comment Elasticsearch procède :

Chaque document contient :

• Un horodatage.
• Des champs dimensionnels qui identifient les séries temporelles.
• Des champs de métriques qui représentent les valeurs mesurées.

En voici quelques exemples :

• Utilisation du processeur par hôte.
• Latence des requêtes par service.
• Relevés de température par capteur.

Les dimensions identifient ce que nous voulons mesurer, tandis que les métriques représentent des valeurs qui évoluent au fil du temps.

Dimensions

Les dimensions décrivent l'entité mesurée.

Exemples :

Nous les définissons dans les mappings avec :

Des métriques

Les métriques représentent des valeurs numériques et sont définies comme suit :

Types de métriques courants :

• Jauge : valeurs qui montent et descendent.
• Compteur : valeurs qui augmentent jusqu'à la réinitialisation.

Elastic Agent collecte principalement des métriques et des données de logs, donc même si vous n'avez pas activé d'index TSDS manuellement, il est possible que vous en ayez toujours dans votre cluster.

Le champ _tsid

Elasticsearch génère en interne une valeur _tsid à partir des champs de dimensions. Cela permet d'acheminer les documents de dimensions identiques vers la même partition, ce qui améliore :

• Compression.
• Localité de la requête.
• Performance d'agrégation.

La principale différence : les index sous-jacents à durée déterminée

Les flux de données traditionnels écrivent toujours dans l'index sous-jacent le plus récent, appelé index d'écriture, mais TSDS se comporte différemment.

Chaque index TSDS sous-jacent comporte une fenêtre temporelle définie et n'accepte que les documents dont les valeurs @timestamp se situent dans cette fenêtre :

Lorsqu’un document est indexé, Elasticsearch l’achemine vers l’index sous-jacent responsable de cet horodatage, ce qui signifie que, contrairement aux index traditionnels, un TSDS peut écrire simultanément dans plusieurs index sous-jacents.

Par exemple :

• Données en temps réel → dernier index.
• Données tardives → index plus ancien couvrant cette plage horaire.

Conception pour les données arrivant en retard

Dans la réalité, les pipelines d'ingestion fournissent rarement les métriques dans les délais impartis. Les métriques peuvent être retardées par des pannes de réseau, des accumulations de données en cours de route, l'ingestion par lots et la perte d'appareils en périphérie, qui se reconnectent ensuite et commencent à rattraper leur retard.

Les index traditionnels absorbent discrètement ces retards, ce qui n'est pas le cas des TSDS.

Si l'horodatage d'un document se situe en dehors de la plage des index de support inscriptibles, Elasticsearch le rejette, ce qui signifie que votre politique ILM doit tenir compte des données en retard.

La contrainte critique

Les index sous-jacents doivent rester accessibles en écriture suffisamment longtemps pour accepter les données en retard.

Concrètement :

Étant donné que l'ILM mesure l'âge à partir de la substitution, la règle opérationnelle est la suivante :

Par exemple, si les métriques peuvent arriver jusqu'à six heures en retard, les index doivent rester inscriptibles au moins six heures après la substitution.

L'absence de prise en compte de cette contrainte est exactement ce qui a causé l'échec d'ingestion décrit précédemment. Les données arrivées en retard ont été dirigées vers un index antérieur, qui se trouvait déjà dans le niveau froid et était donc bloqué en écriture.

Gestion des documents rejetés

Lorsqu'un TSDS rejette un document, Elasticsearch renvoie une erreur, indiquant que l'horodatage ne se situe pas dans la plage des index inscriptibles. La façon dont votre pipeline d'ingestion gère cette erreur détermine si vous perdez des données ou si l'ingestion est bloquée.

Le principal mécanisme pour la gestion des documents rejetés est le magasin des échecs.

Stockage des échecs (recommandé dans Elasticsearch 9.1+)

Elasticsearch 9.1 a introduit le magasin des échecs, qui capture automatiquement les documents rejetés. Au lieu de renvoyer des erreurs aux clients, Elasticsearch écrit les échecs de documents dans un index d'échec dédié au sein du flux de données.

Vous pouvez examiner les échecs à l'aide de :

L'utilisation du stockage des échecs empêche les pipelines d'ingestion d'être bloqués par des erreurs de rejet, tout en préservant les données rejetées à des fins d'analyse ou de réindexation.

Surveillance des problèmes de rejet

Les problèmes de retard d'arrivée apparaissent généralement d'abord sous forme d'anomalies d'ingestion. Vous les remarquerez peut-être d'abord comme :

• Des chutes soudaines du taux d'indexation.
• Une forte augmentation du nombre de documents rejetés.
• Un nombre croissant d'entrées de stockage des échecs.
• Incohérences entre les nombres d'entrées et de sorties du pipeline.

Les alertes en fonction de ces signaux permet aux opérateurs de détecter les problèmes avant que les pipelines ne s'arrêtent. Les workflows, les tâches de machine learning et d'autres mécanismes peuvent être utilisés pour automatiser la détection et les notifications.

Checklist de migration pour les TSDS et l'ILM

Si vous migrez un cluster de métriques vers TSDS, introduisez une hiérarchisation ILM ou effectuez une mise à niveau vers une version d'Elasticsearch où les métriques sont TSDS par défaut, consultez d'abord ces éléments.

1. Mesurer la latence d'ingestion

Avant de modifier les politiques ILM, déterminez :

• Le délai d'ingestion normal.
• Le délai maximal en cas d'incident.
• Les retards dus aux pipelines de traitement par lots.

Votre conception ILM doit prendre en compte le délai réaliste maximal.

2. Vérifier les fenêtres temporelles d'index

Vérifiez vos index sous-jacents TSDS :

Recherchez :

• time_series.start_time
• time_series.end_time

Ces limites déterminent quels index peuvent accepter des documents. Comprendre ces délais permet de déterminer la date limite de rejet des données.

3. Dimensionner le niveau hot pour les arrivées tardives

Assurez-vous que les index sous-jacents restent modifiables suffisamment longtemps pour les données en retard.

Règle opérationnelle :

• warm_min_age > rollover_max_age + maximum_expected_lateness

N'oubliez pas que les index doivent rester accessibles en écriture pendant au moins six heures si les métriques peuvent arriver avec six heures de retard.

4. Décider comment traiter les documents rejetés

Choisissez une stratégie avant d'activer TSDS :

• Magasin des échecs (recommandé dans Elasticsearch 9.1+).
• File d'attente des messages Logstash non distribuables.
• Index de repli pour les arrivées tardives.
• Accepter une perte de données limitée.

5. Monitorer l'intégrité de l'ingestion

Ajoutez des alertes pour :

• Le taux d'indexation chute.
• Documents refusés.
• Croissance du magasin des échecs.
• Incohérences entre les entrées et les sorties du pipeline.

Les problèmes de données tardives apparaissent souvent d'abord sous forme d'anomalies d'ingestion.

Résumé

Les flux de données temporelles apportent des améliorations majeures en termes de stockage et de performances pour les charges de travail des métriques, mais ils introduisent un changement architectural important : les index sous-jacents sont limités dans le temps, ce qui affecte le comportement de l'ILM.

Lors de l'utilisation de TSDS :

• Les index doivent rester inscriptibles suffisamment longtemps pour accepter les données différées.
• Les pipelines d'ingestion doivent gérer les documents rejetés de manière sécurisée.

La règle essentielle à retenir est la suivante :

Si vous concevez les politiques ILM en tenant compte de cette contrainte, TSDS fonctionne de manière optimale pour les charges de travail de métriques.

En revanche, si vous ignorez cette règle, votre pipeline d'ingestion risque de découvrir ces limites temporelles à ses dépens.