Ocado utilise New Relic avec Micrometer pour le monitoring d'un environnement complexe de traitement du streaming d'événements. Découvrez comment !

Ocado Group est une entreprise britannique de technologies de supermarchés en ligne. Chez Ocado Technology, la branche d'Ocado spécialisée dans les technologies, nous concevons et développons en interne une énorme quantité de technologies d'automatisation de pointe. Nous utilisons l'apprentissage machine pour la prévision des demandes, réalisons environ 20 millions de prévisions de demandes par jour et utilisons des robots personnalisés pour aller chercher les articles dans nos entrepôts. Si vous n'avez pas vu nos robots en pleine action, allez les voir sur notre chaîne YouTube. Si la technologie est au cœur de tout ce que nous faisons aujourd'hui, Ocado Group détient également 50 % d'un distributeur-retailer au Royaume-Uni dans une joint-venture avec M&S sur Ocado.com, qui livre plus de 330 000 commandes par semaine. 

Le modèle commercial d'Ocado n'a pas de magasin physique, nous utilisons plutôt d'énormes entrepôts dédiés qui, selon nous, sont les plus grands et les plus sophistiqués de ce type dans le monde. Depuis 2018, nous avons mis Ocado Smart Platform à la disposition d'autres retailers — huit dans le monde dont Morrisons au Royaume-Uni, le Groupe Casino en France, Sobeys au Canada, Kroger aux États-Unis, Coles en Australie et Aeon au Japon. 

La plupart de nos logiciels sont basés sur JVM, y compris les logiciels que nous utilisons pour contrôler nos essaims de robots et la matrice. Pour monitorer ces logiciels, nous utilisons Prometheus (surtout pour les installations sur site) et New Relic. En outre, étant donné qu'une grande partie de notre infrastructure tourne dans le cloud public sur AWS, nous avons utilisé Amazon CloudWatch pour le stockage des métriques et le monitoring de tout ce qui est spécifique à AWS, telles que nos fonctions Lambda et nos groupes automatiquement évolutifs.

Dans ce billet de blog, qui est basé sur ma présentation, je décris l'architecture du système de métriques et de monitoring d'Ocado, le rôle que jouent New Relic et Prometheus, la raison pour laquelle nous utilisons Micrometer et la façon dont nous l'utilisons.

Présentation de l'architecture de monitoring

Nous utilisons Micrometer dans le cadre de notre système de monitoring et de métriques interne, que nous appelons Flux. Flux fournit des métriques agrégées complexes à caractère commercial tel que le « taux d'abandon des commandes » et le « nombre de calculs de commandes commencées, mais pas complétées au cours d'un laps de temps donné ».

En termes d'architecture, à un très haut niveau, Flux fonctionne avec l'envoi par nos applications de leurs événements commerciaux via Amazon Kinesis. Nous ingérons ces événements, nous les filtrons et nous envoyons les événements filtrés vers un flux (stream) Kinesis unique où un processeur des streams d'événements personnalisé réalise l'agrégation nécessaire et calcule les métriques. Ces métriques calculées sont alors envoyées à CloudWatch pour stockage. Si des alertes sont générées, elles sont envoyées à PagerDuty et également par e‑mail.

Bien entendu, le monitoring du système de traitement des streams d'événements est également nécessaire. Pour cela, nous faisons le suivi des trois métriques principales :

• Taux : le taux d'événements
• Perte : le taux d'erreur défini en tant qu'événements n'ayant pas atteint le point de terminaison
• Délai : le parcours de bout en bout d'un événement donné

Ces métriques sont créées en utilisant Micrometer, envoyées à un stream Kinesis comme auparavant, puis distribuées à Prometheus et New Relic.

Voici une capture d'écran de l'un de nos dashboards New Relic :

Pour vous donner une meilleure idée de comment cela marche, j'ai préparé une petite application de démo qui est disponible sur mon repo GitHub. L'application montre une version simplifiée de la façon dont nous utilisons Micrometer avec les registres Prometheus et New Relic. Pour que l'exemple reste simple, j'ai utilisé Kafka Streams plutôt que Kinesis parce qu'il est plus facile d'exécuter Kafka Streams sur un ordinateur local.

Vous vous demandez peut-être pourquoi nous avons choisi cette approche dispersée pour l'envoi des événements à partir de Micrometer vers Prometheus et New Relic, plutôt que d'utiliser l'intégration Prometheus de New Relic. Nous l'avons choisi parce que l'utilisation de l'intégration aurait exigé que nous évoluions et assurions la forte disponibilité de notre cluster Prometheus.

Avantages de Micrometer

L'utilisation de Micrometer nous apporte plusieurs avantages. Tout d'abord, sa proche association avec le framework Spring signifie qu'il fonctionne bien avec Spring et prend nativement en charge l'injection de dépendances. Ensuite, les métriques font partie du code des applications ce qui signifie que nous pouvons facilement avoir la couverture de test automatisée pour ces métriques, en incorporant le test de l'unité et de l'intégration.  Micrometer fonctionne aussi sans fournisseur associé, il nous fournit donc une certaine protection contre l'enfermement propriétaire ; la solution est semblable à SLF4J, mais pour les métriques. En d'autres termes, nous utilisons New Relic parce que le produit nous apporte une valeur certaine et non parce que nous sommes obligés de l'utiliser.

Micrometer prend en charge les quatre principaux types de métriques suivants :

• Compteurs : ils signalent une seule métrique, un compte. L'interface du compteur vous permet d'augmenter d'une seule quantité positive. Le calcul du taux de changement est une des applications des compteurs. Vous pouvez, par exemple, utiliser un compteur pour calculer le temps de disponibilité et vous servir du résultat pour voir quand il y a eu un redémarrage d'une application.
• Indicateurs : ils permettent d'obtenir la valeur actuelle, ils sont utiles pour le monitoring d'un élément avec des bornes supérieures naturelles comme la taille d'une carte ou d'une collecte, ou le nombre de threads en cours d'exécution.
• Minuteurs : ils sont prévus pour mesurer les latences de courte durée telles que l'exécution de certaines parties du code.
• Résumés de distribution : ils sont utilisés pour faire le suivi de la distribution des événements, ils comprennent l'écart type, la moyenne et un échantillon de la métrique particulière.

Enfin, nous trouvons que le modèle de données dimensionnel de Micrometer est utile. Les métriques dimensionnelles ont une valeur qui peut être un scalaire ou un vecteur de valeurs doubles, ainsi que des tags, qui sont des ensembles arbitraires de paires de valeurs clés. Les exemples de tags peuvent être le nom de votre application, la version d'une bibliothèque particulière, etc. Ce modèle vous permet d'effectuer l'agrégation et d'explorer en profondeur différentes métriques selon différents tags, ce qui crée une certaine flexibilité en termes de détection et de création d'alertes.