Prometheus et son modèle de données

Un Prometheus qui fonctionne bien pendant six mois peut devenir inutilisable en une seule journée, à cause d'une ligne de code apparemment anodine. Quelqu'un ajoute une étiquette user_id sur un compteur de requêtes, pour « pouvoir filtrer par client ». Le lendemain, l'occupation mémoire du serveur est passée de 4 à 38 Gio, les requêtes du tableau de bord principal expirent, et le processus finit tué par le noyau. Aucune alerte ne se déclenche, puisque le système d'alerte tourne précisément sur le serveur qui vient de mourir.

Cette panne est la plus courante de tout l'écosystème, et elle est entièrement prévisible dès qu'on a compris ce qu'est une série temporelle pour Prometheus. Ce n'est pas une métrique nommée que l'on filtre à la lecture, comme une colonne dans une table SQL : chaque combinaison distincte de valeurs d'étiquettes crée une série indépendante, avec sa propre structure en mémoire et son propre fichier sur disque. Dix mille clients multipliés par cinq points d'entrée multipliés par quatre codes de statut, ce ne sont pas dix mille lignes de données, ce sont deux cent mille séries. Comprendre ce modèle avant d'écrire la première métrique vous évitera de reconstruire l'installation dans six mois.