Comment DoorDash a migré de StatsD à Prometheus

Une observabilité précise et fiable est essentielle lorsqu'il s'agit de soutenir un grand service distribué, mais cela n'est possible que si vos outils sont également évolutifs. Malheureusement, cela a été un défi pour DoorDash en raison des pics de trafic lors de l'utilisation de notre ancienne infrastructure de mesure basée sur StatsD. Au moment où nous avions le plus besoin de données d'observabilité, le système nous laissait en plan.

C'est pourquoi nous avons décidé de migrer notre pile technologique d'observabilité vers une surveillance basée sur Prometheus. Alors que nous continuons à développer l'activité de DoorDash, l'utilisation de Prometheus nous permet d'éliminer les pertes de métriques, d'augmenter notre utilisation des métriques, de normaliser nos étiquettes de métriques et de réduire de manière significative les coûts globaux. Dans cet article, nous expliquons comment nous avons réalisé la migration, en passant d'abord en revue les défis que nous avons rencontrés avec StatsD, puis en discutant de la façon dont nous avons sélectionné et mis en œuvre Prometheus comme notre solution préférée.

Défis posés par StatsD

StatsD a été un atout majeur pour nos premiers besoins d'observabilité, mais nous avons commencé à rencontrer des contraintes telles que la perte de métriques lors d'événements de surcharge, des difficultés de nommage/standardisation des tags, et un manque d'outils de reporting. Nous présenterons brièvement l'historique de StatD avant de nous pencher sur ces problèmes spécifiques.

StatsD a été développé et publié à l'origine par Etsy pour agréger et résumer les métriques des applications. StatsD est un démon réseau construit en Node.js qui écoute les messages contenant des statistiques, comme les compteurs et les minuteurs, afin d'envoyer des agrégats à des backends configurables.

Figure 1 : DoorDash utilisait auparavant les pipelines de proxy et de serveur StatsD pour les métriques des microservices.

La conception illustrée à la figure 1 reflète notre ancienne architecture pour l'observabilité. Malheureusement, cette conception posait de nombreux problèmes qui sont décrits plus en détail ci-dessous :

• La perte de paquets du protocole UDP ( User Datagram Protocol ) était possible, mais il n'existait aucun moyen pratique de détecter une telle perte, ce qui pouvait entraîner un manque d'informations métriques 
• Il n'y avait pas de normalisation des noms et les étiquettes n'étaient pas suffisamment granulaires. 
• Il n'y avait pas de fonction d'histogramme ni de moyen d'agréger les percentiles.

Perte de paquets

Le proxy StatsD lit les messages à partir du tampon recv du système d'exploitation, qui les reçoit et les conserve avant de les traiter. Si les messages arrivent trop rapidement, cette mémoire tampon ne parvient pas à les traiter tous, déborde et commence à abandonner des paquets. Si un proxy ou une instance de serveur StatsD est hors ligne pour quelque raison que ce soit, les métriques de cette instance sont perdues. Les clients StatsD envoient des données par UDP, qui n'offre aucune garantie de livraison au niveau de la couche de transport, ce qui rend les pannes de proxy transparentes pour les serveurs en aval. Bien que la perte de paquets puisse être détectée, une sophistication et une complexité accrues sont nécessaires pour l'identifier par rapport à d'autres flux simultanés.

Absence de normalisation des noms et nombre limité de balises

Le pipeline de surveillance basé sur StatsD n'est pas normalisé en matière de dénomination et ne prend que peu en charge les balises. Le serveur StatsD envoie des mesures à un proxy, qui interprète le format telegraf de StatsD pour prendre en charge les balises de point. Par exemple, les mesures originales de StatsD sont envoyées dans le format suivant :

Générique :

<metricname>:<value>|<type>

Exemple :

prod.k8s-instance1.podxk723.eta.dynamic-eta.predict:129|c

Toutefois, cette convention ne permet pas de normaliser les noms des mesures et les balises intégrées. Pour éviter une croissance exponentielle, un niveau d'agrégation supplémentaire doit être ajouté pour consolider les valeurs critiques avant le niveau de stockage.

Absence de fonction d'histogramme

Enfin, l'absence de prise en charge complète du type de données histogramme par le pipeline StatsD complique l'analyse des percentiles de latence. Cela nécessite le calcul des percentiles requis pour les latences, par exemple quel pourcentage des valeurs métriques est inférieur à un seuil arbitraire. Le pré-calcul ajoute de la complexité au pipeline et empêche les utilisateurs d'explorer les données en utilisant différents seuils ou percentiles, ce qui diminue en fin de compte la valeur globale de l'information sur les métriques.

Exigences pour notre outil d'observabilité amélioré

1.) Sur la base de ces problèmes avec StatsD, nous avons défini certains principes et exigences pour notre prochaine solution : une préférence marquée pour l'utilisation de logiciels libres et de normes émergentes

Un système de surveillance à code source ouvert permet de tirer parti des avantages suivants :

• Rentabilité: Les avantages en termes de coûts de l'utilisation de logiciels libres sont généralement plus importants que l'investissement nécessaire à la création et à la maintenance de ces systèmes. 
• Intégration : Nous utilisons des systèmes à code source ouvert pour rendre nos mesures, tableaux de bord et alertes portables. Nous pouvons tirer parti des formats de données et des langages d'interrogation libres. De plus, de nombreux fournisseurs actuels et futurs prennent en charge ces normes, ce qui offre une souplesse d'évolution.
• Auto-hébergement : Le partenariat avec un fournisseur accélère le déploiement, tandis que l'alignement sur les normes open-source garantit que le pipeline reste indépendant du fournisseur jusqu'à l'étape finale, ce qui permet de conserver une certaine flexibilité pour l'avenir.

2.) Une meilleure gouvernance et un meilleur contrôle

L'alignement de tous les services sur les conventions standard de dénomination et de marquage permet d'assurer la cohérence au sein de l'écosystème d'observabilité au sens large.

• Conventions standard : Tout en donnant la priorité à une surveillance stable et fiable, nous voulions aussi mieux contrôler les conventions que nous utilisions et assurer la similitude entre nos autres systèmes d'observabilité. L'établissement de conventions de dénomination et de balises communes permet d'optimiser toute réinitialisation future des tableaux de bord et des alertes.
• Contrôles des taux : Dès le départ, nous avons voulu développer la capacité de rendre compte de l'agrégation de l'utilisation conformément à nos normes d'étiquetage - par exemple, par espace de noms - et d'appliquer des contrôles sélectifs aux services sources qui violaient nos enveloppes convenues, telles que le taux et la cardinalité.
• Facilitation de l'intégration : Nous avons cherché à permettre la corrélation des données de mesure avec les événements d'autres domaines. Cela permet une intégration plus profonde entre les systèmes, y compris les journaux et les traces, et permet d'utiliser les données de mesure pour des besoins adjacents tels que l'attribution des coûts.

3.) Capacités de libre-service 

Pour accélérer la migration, nous devions renforcer la productivité et automatiser le processus général d'intégration.

• Renforcement de la productivité : Ce processus signifie que chaque paramètre est découvert sur la base de la méthodologie de déploiement existante. 
• Automatisation de l'accueil : Une fois que le service du développeur est enregistré, ces mêmes configurations sont utilisées pour découvrir le service et commencer à collecter les mesures correspondantes. Aucune étape supplémentaire n'est nécessaire pour construire des tableaux de bord ou créer des alertes de service.

Migrer vers une surveillance basée sur Prometheus

Avec ces nouveaux principes et lignes directrices en matière d'observabilité, nous avons choisi de migrer vers une surveillance basée sur Prometheus, un logiciel libre. 

Pourquoi Prométhée ?

Prometheus s'est imposé comme la norme dominante en matière de métrologie libre et correspond bien à notre stratégie et à nos besoins. Il bénéficie d'un large soutien tant pour la production de données métriques côté client que pour la consommation et la présentation de ces informations côté serveur. Le soutien solide de la communauté parmi de nombreux fournisseurs a créé un vaste écosystème d'exportateurs et de connaissances partagées qui accélèrent l'intégration avec presque tous les systèmes sources. 

L'adoption de Prometheus dans la Cloud Native Computing Foundation a permis d'assurer un soutien solide aux outils plus fondamentaux utilisés chez DoorDash, notamment Kubernetes et Envoy. Prometheus comprend une base de données de séries temporelles remplaçable couplée à un service pour gérer la collecte et l'extraction des données à l'aide d'une syntaxe PromQL puissante. Un projet homologue étroitement couplé fournit un gestionnaire d'alertes intégré qui extrait des informations critiques en temps réel du flux de données.

Notre processus de migration vers Prometheus

La migration s'est déroulée en deux phases. Tout d'abord, l'équipe chargée de l'observabilité a migré les composants de l'infrastructure et mis en place le nouveau pipeline de collecte de mesures avec découverte automatique des services, parallèlement aux pipelines existants ; les propriétaires de services ont simultanément activé les nouveaux points de terminaison sur les composants qui leur appartiennent. Ensuite, nous avons collaboré en tant que consultants avec les propriétaires de services pour migrer les tableaux de bord, les alertes, les SLO et d'autres outils similaires, comme expliqué ci-dessous. 

Instrumentation des services avec les clients et les bibliothèques Prometheus

Les clients et les bibliothèques de métrologie génèrent et exposent des métriques via un point d'extrémité HTTP. Prometheus prend en charge la plupart des langages de programmation et des frameworks courants. Ainsi, au lieu d'utiliser une façade comme un micromètre, les propriétaires de services sont encouragés à utiliser les bibliothèques Prometheus en mode natif. Nous fournissons ce support natif par le biais d'une bibliothèque de plateforme commune par défaut, mais les propriétaires de services peuvent utiliser des bibliothèques/clients personnalisés s'ils ont des exigences particulières. En cas de difficultés liées à la prise en charge native des clients, comme les composants tiers, les propriétaires de services peuvent également déployer un exportateur en tant que sidecar pour répondre à leurs exigences en matière de métrologie.  

Bibliothèques internes

Nous fournissons des bibliothèques internes communes basées sur des standards open source pour faciliter l'adoption par la plupart des propriétaires de services. Ces bibliothèques prennent en charge les mesures générées par toutes les autres fonctions de la plate-forme, telles que les interactions avec la base de données ou MQ, de sorte que les développeurs n'ont pas à se préoccuper de l'instrumentation de ces interactions et peuvent se concentrer sur les mesures liées à leur logique d'entreprise.

Bibliothèques communautaires

Nous avons encouragé les propriétaires de services et les équipes à utiliser les bibliothèques natives de Prometheus pour générer des métriques d'application plutôt que d'utiliser d'autres façades de métriques. Cela permet d'éviter les comportements potentiellement incohérents découlant de la manière dont les systèmes de façade mettent en œuvre les paradigmes Prometheus tels que les histogrammes ou les résumés.

Exportateurs

Lorsque le service ou le composant n'est pas entièrement contrôlé par le propriétaire, il peut être nécessaire d'exporter les métriques Prometheus via un exportateur spécifique à la fonction. La communauté propose de nombreux exportateurs qui peuvent être utilisés pour fournir des mesures de haute qualité à partir de sources non natives. Parmi de nombreux exemples, nous incluons l'exportateur Prometheus JVM dans nos images de base ; les propriétaires de services peuvent activer les métriques JVM à l'aide de l'exportateur. Des exportations similaires sont déployées pour de nombreuses bases de données et composants d'infrastructure dans DoorDash.

Collecte de données métriques

Il existe un certain nombre de cas d'utilisation distincts pour la collecte de métriques : 

• Collecte Kubernetes : Le collecteur de métriques est déployé en tant que DaemonSet sur chaque nœud Kubernetes pour racler les cibles qui sont déterminées comme étant locales sur la base des annotations maintenues dans la configuration Kubernetes pour la découverte de services. Comme la plupart des microservices de DoorDash sont déployés dans des clusters Kubernetes, cela représente la grande majorité de la collecte de métriques en volume.
• collection d'exportateurs : Prenons l'exemple de l'extraction de métriques à partir d'une infrastructure AWS sous-jacente. Le service AWS CloudWatch expose les données, ce qui nous permet de déployer l'exportateur de métriques CloudWatch open-source pour copier les données pertinentes dans notre environnement Prometheus commun. Il existe deux exportateurs CloudWatch populaires : l'exportateur officiel Prometheus CloudWatch et l'exportateur open-source YACE, abréviation de Yet Another CloudWatch Exporter. Nous avons choisi YACE parce qu'il offre des optimisations qui réduisent la charge sur l'API CloudWatch et qu'il se targue d'un mécanisme de découverte facile. La principale différence entre les deux est que les fonctions principales de YACE utilisent l'API GetMetricData pour obtenir des métriques, tandis que l'exportateur officiel utilise l'API GetMetricStatistics. Une méthodologie similaire est utilisée pour exporter les métriques de divers autres composants tiers utilisés dans notre infrastructure.
• Collecte pour les emplois de courte durée : Dans certains cas, les travaux de courte durée ne peuvent pas être récupérés via ce mécanisme. Dans ce cas, nous déployons la passerelle d'agrégation Prometheus pour fournir la cible de métriques basée sur la poussée nécessaire pour les charges de travail personnalisées. Il ne s'agit pas d'un modèle de collecte privilégié, mais il permet de couvrir l'ensemble des cas d'utilisation pour la collecte de métriques.

Balises standard pour tous les indicateurs

Pour améliorer la cohérence des mesures et maximiser la réutilisation des tableaux de bord et des alertes, nous avons défini des balises communes qui sont ajoutées à toutes les mesures Prometheus. Ces balises communes sont utiles pour créer des tableaux de bord et des alertes communs afin de surveiller l'état des services. 

Voici quelques-unes des balises communes à toutes les mesures :

• service: Le nom du service enregistré dans notre registre de services interne.
• app: L'application au sein d'un service (par exemple, web vs. mobile)
• environnement: pour indiquer que le service est dans un environnement de production ou de mise à l'essai
• région: La région du nuage dans laquelle cette charge de travail est exécutée
• zone: La zone de disponibilité du nuage dans laquelle cette charge de travail est exécutée.

La figure 2 ci-dessous montre un exemple de la manière dont ces balises communes sont utilisées comme filtres dans la plupart des tableaux de bord.

            Figure 2 : Un des tableaux de bord qui utilise des balises communes pour les filtres et les requêtes

Optimisation de l'ingestion

Le processus de collecte permet une agrégation efficace basée sur des règles avant que les données ne soient transférées au niveau de stockage. Cela permet d'optimiser les mesures de cardinalité des étiquettes et d'améliorer les performances en réduisant ou en éliminant les dimensions des étiquettes non désirées, produisant ainsi une mesure représentative basée uniquement sur les étiquettes restantes. Ce processus permet également d'abandonner complètement les métriques si aucun tableau de bord ni aucune alerte n'y fait référence. Enfin, la résolution des mesures est réduite au bout de dix jours afin de conserver les données de tendance pour les comparaisons historiques tout en réduisant considérablement les besoins de stockage.

Règles d'étiquetage

Les règles de relabel sont utilisées pour réécrire dynamiquement le jeu d'étiquettes d'une cible pendant l'événement de scrape afin d'optimiser le processus d'admission à sa genèse. Dans le collecteur de métriques, nous avons configuré les règles de relabel pour consolider les valeurs et abandonner les étiquettes ou les métriques de faible valeur.

Utilisation de la codification pour les alertes

Un système d'alerte robuste basé sur des mesures notifie les ingénieurs des événements critiques lorsque des critères de seuil spécifiques sont atteints. Chez DoorDash, nous avons codifié nos alertes pour obtenir des avantages clés :

• Contrôle de la source: Toutes les alertes de surveillance doivent être contrôlées à la source et configurées/versionnées par le biais du code plutôt que d'être modifiées directement dans une interface utilisateur. Cela permet de garantir une capacité de retour en arrière sûre et d'établir un historique des modifications.
• Modèles d'alerte : Nous avons intégré les définitions d'alerte dans des modèles communs avec des valeurs par défaut logiques pour permettre aux ingénieurs de définir rapidement leurs alertes.
• Étiquetage commun : En normalisant nos valeurs d'étiquetage comme décrit ci-dessus, nous sommes en mesure de faire correspondre une alerte à l'équipe qui possède ce service et d'automatiser l'acheminement de la notification correspondante directement à l'infrastructure de rendu direct de garde pour ce service. Cela permet d'éliminer en grande partie toute étape de triage et de réduire le temps moyen de réparation.

Résultats et réalisations

Grâce à toutes les stratégies décrites ci-dessus, nous avons mené à bien la migration de tous les indicateurs, tableaux de bord et alertes. Nous n'avons plus à déplorer de pertes périodiques de métriques et notre gouvernance améliorée permet une plus grande cohérence, prévisibilité et transparence dans l'écosystème des métriques. Le système de surveillance basé sur Prometheus est stable, évolutif et flexible, et offre une vision nettement améliorée de la santé du service DoorDash.