Sous-échantillonnage et niveaux de rétention pour les données de séries temporelles

Objectif

Répondre à des questions de longue portée (une année de latence, trois années de relevés de compteurs) pour une fraction du coût de stockage et d'analyse des échantillons bruts, tout en conservant la résolution brute pour la période où elle est réellement consultée.

Prérequis

Une table ou un magasin partitionné par le temps, et une décision sur ce que chaque niveau doit pouvoir répondre. La documentation de stockage de Prometheus (citée) montre la politique la plus simple : une durée de rétention pour les échantillons (--storage.tsdb.retention.time, 15 jours par défaut lorsque ni elle ni une limite de taille ne sont définies) ou une limite de taille qui supprime d'abord les blocs les plus anciens. Thanos (cité) décrit le sous-échantillonnage comme la réécriture des séries pour réduire la résolution sans perdre en exactitude sur des plages plus longues, en stockant pour chaque bloc sous-échantillonné le nombre, la somme, le minimum, le maximum et une série de compteur, de sorte que les données plus grossières puissent toujours être agrégées. La fonction date_bin de PostgreSQL (citée) répartit un horodatage dans un intervalle aligné sur une origine spécifiée, qui constitue la primitive nécessaire à une agrégation SQL.

Étapes

1. Consigner les niveaux sous la forme (résolution, rétention, finalité) : par exemple données brutes pendant 14 jours pour l'analyse d'incidents, compartiments de 5 minutes pendant 13 mois pour les tendances de capacité, compartiments horaires pendant 5 ans pour le reporting. Les durées de rétention constituent une décision à consigner, pas un nombre à recopier d'ailleurs.
2. Pour chaque compartiment, ne stocker que des statistiques ré-agrégeables : le nombre, la somme, le minimum, le maximum, et pour les compteurs, l'accroissement. Dériver les moyennes comme la somme divisée par le nombre au moment de la requête ; ne pas stocker de moyennes ni de percentiles, car ils ne peuvent pas être combinés dans un compartiment plus grossier. Si des percentiles sont nécessaires, stocker un histogramme avec des bornes de compartiment fixes.
3. Aligner les compartiments avec date_bin(stride, ts, origin) en utilisant une origine fixe unique (l'epoch Unix, ou minuit UTC) afin que les compartiments provenant de différentes exécutions et tables coïncident.
4. Ne planifier l'agrégation d'un compartiment qu'une fois écoulée la fenêtre de données tardives de ce compartiment, et la faire remplacer le compartiment plutôt que s'y ajouter, afin qu'une réexécution soit sans danger.
5. Faire expirer un niveau en supprimant des partitions ou des blocs entiers, jamais par des suppressions ligne par ligne ; vérifier l'agrégation d'une partition (nombre de lignes, somme d'une mesure) avant que sa partition brute ne soit supprimée.
6. Exposer les niveaux via une seule vue ou couche de requête qui sélectionne le niveau le plus fin couvrant la plage demandée.

Résultat attendu

Les requêtes de longue portée parcourent le niveau grossier et renvoient un résultat en temps borné ; le stockage ne croît qu'avec les niveaux grossiers ; les données brutes restent disponibles pour la période où elles sont utilisées.

Limites et base de vérification

Les données sous-échantillonnées ne peuvent pas répondre à des questions sur des pics à l'intérieur d'un compartiment. Une frontière de niveau traversée par une même requête produit deux résolutions dans un seul résultat et doit être signalée comme telle. Le protocole est dérivé de la documentation citée ; aucune mesure n'est revendiquée.