Comprendre et collecter les métriques dans Istio

Comprendre et collecter les métriques dans Istio

C’est quoi les métriques ?

Les métriques fournissent un moyen de surveiller et de comprendre le comportement des entités d’un système. Elles permettent entre autres d’avoir des informations telles que:

• Le volume global de trafic
• Le taux d’erreurs sur le trafic
• Le temps de réponse aux requêtes ( latence)
• …

Comprendre les métriques dans Istio

Les métriques dans Istio offrent une observabilité du comportement des services, ainsi que celle de l’état du mesh et de ses composants. Les métriques permettent aux Ops de surveiller les services afin qu’on puisse les dépanner et les optimiser . Ils acquièrent ainsi une compréhension approfondie de la façon dont les services interagissent, à la fois avec d’autres services et avec les composants Istio eux-mêmes.

Istio implémente les métriques différemment suivant le composant Istio concerné.

Pour rappel, ci-dessous l’architecture d’Istio:

                                                                                                                                                                               source: https://istio.io/docs/ops/deployment/architecture/

Pour ne pas trop entrer dans les détails de son architecture, Istio est divisé logiquement en deux entités:

• le Data plane constitué par un ensemble de proxies qui assurent et contrôlent l’ensemble des communications dans le service mesh,
• le Control plane qui gère et configure les proxies.

De ce fait:

Au niveau du Data plane, la collecte des métriques se fait avec les sidecars proxies ( Envoy). Le proxy donne généralement trois types de métriques dépendamment de comment il est configuré:

• Downstream : elles concernent les connexions / requêtes entrantes. Ces métriques sont émises par les listenners, le gestionnaire de connexions HTTP, le filtre proxy TCP, etc.
• Upstream : elles concernent les connexions / requêtes sortantes. Ces métriques sont émises par les pools de connexions, le router filter, le proxy TCP filter , etc.
• Server : elles décrivent le fonctionnement de l’instance même. Les métriques telles que la disponibilité du serveur ou la quantité de mémoire allouée sont classées ici.

Au niveau Service, Istio fournit également un ensemble de métriques permettant de comprendre les communications inter-services. Ces métriques couvrent l’ensemble des besoins de base du monitoring à savoir : la latence, la saturation, les erreurs et le trafic. Cependant il est laissé à l’appréciation de l’Ops de choisir quelles métriques visualiser.( PS: Istio est livré avec un ensemble de métriques par défaut que pourrez voir ici Default Metrics )

Au niveau du Control plane, chaque entité (Pillot, Mixer, Galley) dispose d’une collection de métrique permettant de comprendre le comportement d’Istio lui-même.

 NOTE: Prometheus est un logiciel opensource  de monitoring et de génération d’alerte . Il enregistre les métriques en temps réel dans une base de données en se basant sur le contenu du endpoint exposé. Istio permet d’installer Prometheus et Grafana . 

Collecter les métriques

Dans cette partie nous verrons comment collecter les métriques dans un cluster Istio.

Nous allons ajouter une nouvelle métrique à Istio qui nous permettra de compter deux fois les requêtes arrivant sur une application . Ainsi chaque requête arrivant sur un service bien déterminé sera compté doublement. Par exemple, si une requête est faite sur notre application bookinfo, notre instance que nous avons nommée doublerequestcount considérera que 2 requêtes sont faites.

Supposons que nous avons une définition  de métrique nommée mymetric.yaml telle que définie ci-dessous:

Cette configuration indique au Mixer comment générer les valeurs des métriques pour une requête donnée, en fonction des attributs renvoyés par Envoy (et générés par Mixer lui-même). Pour chaque instance de doublerequestcount, on demande au  Mixer de fournir une valeur de 2 pour l’instance. Étant donné qu’Istio génère une instance pour chaque demande, cela signifie que cette métrique enregistre une valeur égale au double du nombre total de demandes reçues.

Nous allons par la suite exécuter cette commande pour créer cette nouvelle métrique :

En considérant, l’exemple bookinfo de Istio Bookinfo Application , on peut tester l’instance de métrique créée en visitant l’onglet productPage http://$GATEWAY_URL/productpage

Ces métriques peuvent maintenant être visualisées à l’aide de Prometheus. Sur la console relative à notre instance créée, on a une sortie semblable à celle-ci:

Nous voyons bien que nos requêtes sont comptées 2 fois! Nous avons donc reçu 4 requêtes sur productpage-v1.

Pour supprimer cette métrique une commande

Le petit plus…

• Visualisation avec Grafana

Istio est installé avec des dashboards Grafana préconfigurés.

On a principalement trois types de dashboard:

• une pour l’affichage des workloads: cette section fournit des métriques sur les requêtes et les réponses pour chaque workload dans le mesh (HTTP / gRPC et TCP). 
• une pour les services : cette section fournit des métriques sur les requêtes et les réponses pour chaque service dans le mesh (HTTP / gRPC et TCP). 
• Une dernière section  qui donne une vision globale du mesh

Pour rendre la lecture et la compréhension des métriques plus faciles, Grafana (outil de visualisation) est utilisé . Grafana est un add-on d’Istio par défaut. 

Pour ouvrir l’UI d’Istio avec Grafana,  on a besoin de faire un port-forwarding comme suit:

Une fois celui-ci configuré, on peut accéder au dashboard avec cette url http://localhost:3000/dashboard/db/istio-mesh-dashboard 

Ainsi on peut visualiser les dashboards suivants:

                                                                                                       Mesh Dashboard

                                                                                                        Service dashboard

                                                                                                        Workload dashboard                                                                                                        Mixer dashboard

• Le mesh dashboard montre le nombre total de requête , le nombre de requête ayant réussi et la latence pour tous les services et les workloads concernés.
• Le service dashboard et le workload dashboard concernent respectivement un service et un workload bien déterminé. On a entre autres données , le nombre de requête client, le pourcentage des requêtes ayant réussies ainsi que la durée de ces requêtes.
• Le Mixer dashboard quant à lui donne des graphes de l’utilisation des différentes ressources (Memory, CPU, Disk).

Toutes les métriques relatives à notre mesh, ainsi qu’aux différents services sont ainsi visualisées sur ces interfaces graphiques!

Halima GAYEIngénieur Cloud & DevOps