Technique

Monitoring d'Istio avec Elastic Observability

Istio est un maillage de service open source qui permet aux développeurs et aux opérateurs de contrôler, de sécuriser et de connecter facilement des services appartenant à l'univers des microservices distribués. Istio est un outil performant pour les équipes. Par ailleurs, il est important que les administrateurs bénéficient d'une visibilité complète de son état. Dans cet article, nous vous expliquons comment monitorer Istio et ses microservices à l'aide d'Elastic Observability.

Voici quelques explications tirées de la documentation sur Istio :

Istio permet de créer facilement un réseau de services déployés doté de diverses fonctionnalités, comme l'équilibrage des charges, l'authentification de service en service et le monitoring, qui nécessite peu de changements de code, voire aucun. Pour ajouter Istio aux services, il suffit de déployer au sein de votre environnement un proxy sidecar spécial qui intercepte toutes les communications réseau entre les microservices. Ensuite, configurez Istio et gérez-le à l'aide de sa fonctionnalité de plan de commande, qui comprend les éléments suivants :

  • équilibrage des charges automatique pour HTTP, gRPC, WebSocket et le trafic TCP ;
  • contrôle minutieux du comportement du trafic à l'aide de règles optimales de routage, de nouvelles tentatives, de basculements et d'injection de fautes ;
  • une couche modulable de politique et une API de configuration prenant en charge les contrôles des accès, les limites et les quotas ;
  • des indicateurs, logs et traces automatiques pour l'ensemble du trafic d'un cluster, y compris ses points d'entrée et de sortie ;
  • une communication sécurisée entre les services au sein d'un cluster à l'aide de solides autorisation et authentification fondées sur les identités.

Avant la version 1.5, Istio était doté d'une architecture de microservices. Ses composantes de gestion et son plan de commande comprenaient plusieurs microservices, à savoir Pilot, Mixer, Galley et Citadel.

Metricbeat intégrait la prise en charge du monitoring de ces microservices. Cependant, la version 1.5 d'Istio a remplacé son architecture par une approche monolithique. Désormais, le plan de commande comprend une seule application, appelée istiod. Pilot, Galley et Citadel font désormais partie intégrante d'istiod, tandis que la fonctionnalité de Mixer, qui recueillait les indicateurs sur le trafic depuis les proxys Envoy, est désormais assurée directement par les proxys Istio. Voici à quoi ressemble l'architecture actuelle d'Istio :

Architecture d'Istio

Création d'une solution de monitoring avec Elastic

Tandis que les versions antérieures à la version 1.5 étaient déjà prises en charge par les différents ensembles d'indicateurs du module Metricbeat Istio, cet article est consacré au support technique des nouvelles versions lorsqu'Istio est exécuté sur Kubernetes.

Indicateurs du plan de commande

Comme le montre l'architecture Istio illustrée ci-dessus, nous pouvons collecter les indicateurs du plan de commande à partir d'une seule ressource. Istiod fournit un exportateur Prometheus à partir duquel nous pouvons recueillir des indicateurs Prometheus.

Afin d'utiliser les indicateurs provenant du point de terminaison Prometheus, nous avons besoin d'un ensemble d'indicateurs capable de recueillir ces données correctement, de les filtrer et de les stocker en conséquence. Pour ce faire, il n'y a rien de plus simple : il suffit de créer un ensemble d'indicateurs léger à partir du module Prometheus qui exploite des options performantes, comme le filtrage des indicateurs, mais aussi l'utilisation des histogrammes et des types.

Voici la définition de ce nouvel ensemble d'indicateurs léger :

input: 
  module: prometheus 
  metricset: collector 
  defaults: 
    metrics_path: /metrics 
    metrics_filters: 
      include: ["citadel_*", "galley_*", "pilot_*"] 
      exclude: ["^up$"] 
    use_types: true 
    rate_counters: true

Ainsi est défini le chemin à partir duquel l'ensemble récupère les indicateurs et les filtre pour conserver uniquement ceux qui sont nécessaires. En outre, il active les taux et les types. Ainsi, les données seront correctement stockées dans Elasticsearch, ce qui nous permet d'en tirer pleinement parti.

Voici comment configurer cet ensemble d'indicateurs lorsque vous déployez Metricbeat sur un cluster Kubernetes :

- module: istio 
  metricsets: ['istiod'] 
  period: 10s 
  hosts: ['istiod.istio-system:15014']

Dans cet exemple, istiod est le nom du service de Kubernetes présentant l'Istiod Pod et istio-system est l'espace de nom où il est déployé.

Et le tour est joué ! L'ensemble d'indicateurs istiod recueille déjà les indicateurs dans istiod. Il comprend également un tableau de bord préintégré afin de fournir un aperçu du plan de commande du maillage de service, mais aussi plusieurs visualisations qui vous permettent d'utiliser vos propres tableaux de bord personnalisés.

Tableau de bord de l'aperçu

Indicateurs du plan de données

Maintenant que nous recueillons les indicateurs depuis le plan de commande grâce à l'ensemble istiod, nous pouvons étendre notre monitoring en collectant les indicateurs depuis le plan de données. Ainsi, nous obtenons un très bon aperçu du trafic entre les services gérés par Istio.

Comme expliqué précédemment, le microservice Mixer recueillait ces indicateurs depuis le plan de données et les mettait à disposition. Cependant, après la version 1.5, ces indicateurs sont collectés et exposés directement depuis les proxys Istio grâce à un exportateur Prometheus.

Pour recueillir ces indicateurs supplémentaires, il suffit de préciser un autre ensemble d'indicateurs léger, similaire à celui configuré pour istiod :

input: 
  module: prometheus 
  metricset: collector 
  defaults: 
    metrics_path: /stats/prometheus 
    metrics_filters: 
      include: ["istio_*"] 
      exclude: ["^up$"] 
    use_types: true 
    rate_counters: true

De nouveau, nous configurons le chemin metrics_path, conservons uniquement les indicateurs adéquats et les stockons à l'aide des types. 

Toutefois, il nous manque une information : nous ne savons pas comment atteindre ces conteneurs proxys, car nous ne connaissons pas leurs adresses IP. Même si nous les connaissions avant de déployer Metricbeat, nous ne pourrions pas recueillir de données depuis les services qui seraient déployés après le lancement de Metricbeat. Nous avons besoin d'une méthode nous permettant d'identifier automatiquement ces conteneurs et de commencer à collecter les indicateurs dès leur lancement. Bonne nouvelle ! La solution idéale existe : il s'agit de la fonctionnalité autodiscover de Metricbeat. Ainsi, nous définissons une condition de détection automatique, qui identifie ces conteneurs. Dès qu'un nouveau conteneur sidecar proxy Istio est repéré, Metricbeat active automatiquement l'ensemble d'indicateurs proxy et commence à en recueillir les données.

Voici un exemple de la configuration de détection automatique :

metricbeat.autodiscover: 
  providers: 
    - type: kubernetes 
      node: ${NODE_NAME} 
      templates: 
        - condition: 
            contains: 
              kubernetes.annotations.prometheus.io/path: "/stats/prometheus" 
          config: 
            - module: istio 
              metricsets: ["proxy"] 
              hosts: "${data.host}:15090"

Et voilà ! Nous recueillons les indicateurs de tous les conteneurs sidecar Istio exécutés sur le cluster et pouvons identifier les nouveaux en temps réel. Voici l'ensemble d'indicateurs proxy du module Istio, comprenant un tableau de bord préintégré.

Tableau de bord du trafic

En outre, nous pouvons exploiter l'analyse de graphes dans Kibana afin d'explorer les corrélations entre nos données et les services. Par exemple, dans le graphe ci-dessous, nous obtenons un aperçu de la manière dont nos services sont interconnectés et de la solidité de leurs relations avec les codes d'état http. Si un service a une relation solide avec un code d'état de 500, cela peut indiquer un problème qui doit être étudié.

Graphe du maillage de service

Monitoring d'Istio dès aujourd'hui

Si vous souhaitez commencer à monitorer votre maillage de service Istio dès aujourd'hui, téléchargez Metricbeat 7.11 et commencez à explorer vos indicateurs avec efficacité grâce à Elasticsearch et à Kibana. Pour déployer votre cluster, la méthode la plus rapide est de vous inscrire à un essai gratuit d'Elasticsearch Service. Si vous avez la moindre question, n'hésitez pas à la poser sur les forums de discussion. Nous serons ravis de vous aider.

We're hiring

Work for a global, distributed team where finding someone like you is just a Zoom meeting away. Flexible work with impact? Development opportunities from the start?