Présentation

Datadog surveille chaque aspect de votre environnement Istio, afin que vous puissiez :

• Évaluer la santé d’Envoy et du plan de contrôle Istio grâce aux logs (voir ci-dessous)
• Consulter en détail les performances de votre maillage de services avec des métriques sur les requêtes, la bande passante et la consommation de ressources (voir ci-dessous).
• Mapper les communications réseau entre les conteneurs, pods et services sur le maillage avec la solution Network Performance Monitoring
• Plonger au cœur des traces distribuées pour les applications qui effectuent des transactions sur le maillage avec l’APM

Pour en savoir plus sur la surveillance de votre environnement Istio avec Datadog, consultez l’article du blog à ce sujet (en anglais).

Configuration

Suivez les instructions ci-dessous pour installer et configurer ce check lorsque l’Agent est exécuté sur un host. Consultez la documentation relative aux modèles d’intégration Autodiscovery pour découvrir comment appliquer ces instructions à un environnement conteneurisé.

Installation

Istio est fourni avec l’Agent Datadog. Installez l’Agent Datadog sur vos serveurs Istio ou dans votre cluster et pointez-le vers Istio.

Envoy

Si vous voulez surveiller les proxies Envoy dans Istio, configurez l’intégration Envoy.

Configuration

Modifiez le fichier istio.d/conf.yaml (dans le dossier conf.d/ à la racine du répertoire de configuration de votre Agent) pour vous connecter à Istio. Consultez le fichier d’exemple istio.d/conf.yaml pour découvrir toutes les options de configuration disponibles.

Collecte de métriques

Pour surveiller le déploiement istiod et istio-proxy dans Istio v1.5+, deux composants clés contribuent à la collecte des métriques au format Prometheus. Conformément à l’architecture Istio, il s’agit du plan de données (les conteneurs sidecar istio-proxy) et du plan de contrôle (le service istiod qui gère les proxies). Ils sont tous les deux exécutés en tant que checks d’Agent istio. Toutefois, chacun possède ses responsabilités et est configuré de façon distincte, comme décrit ci-dessous.

Configuration du plan de données

Pour surveiller le plan de données Istio, l’Agent comprend un fichier istio.d/auto_conf.yaml permettant de configurer automatiquement la surveillance pour chacun des conteneurs sidecar istio-proxy. L’Agent initialise ce check pour chaque conteneur sidecar qu’il détecte automatiquement. Cette configuration active la transmission de métriques istio.mesh.* pour les données exposées par chacun de ces conteneurs sidecar.

Pour personnaliser le plan de données de l’intégration, créez un fichier de configuration équivalent pour Istio. Définissez les valeurs de ad_identifiers et de istio_mesh_endpoint correctement afin de configurer l’intégration lorsqu’un conteneur sidecar istio-proxy est détecté. Référez-vous au fichier istio.d/auto_conf.yaml et à l’exemple de fichier de configuration fournis pour découvrir toutes les options de configuration disponibles. Lors de la personnalisation, définissez les valeurs de use_openmetrics: true et exclude_labels comme suit :

    exclude_labels:
      - source_version
      - destination_version
      - source_canonical_revision
      - destination_canonical_revision
      - source_principal
      - destination_principal
      - source_cluster
      - destination_cluster
      - source_canonical_service
      - destination_canonical_service
      - source_workload_namespace
      - destination_workload_namespace
      - request_protocol
      - connection_security_policy

Configuration du plan de contrôle

Pour surveiller le plan de contrôle Istio et transmettre les métriques mixer, galley, pilot et citadel, vous devez configurer l’Agent de façon à ce qu’il surveille le déploiement istiod. Dans Istio v1.5+, appliquez les annotations Autodiscovery suivantes en tant qu’annotations de pod pour le déploiement istiod dans l‛espace de nommage istio-system :

ad.datadoghq.com/discovery.check_names: '["istio"]'
ad.datadoghq.com/discovery.init_configs: '[{}]'
ad.datadoghq.com/discovery.instances: |
     [
       {
         "istiod_endpoint": "http://%%host%%:15014/metrics",
         "use_openmetrics": "true"
       }
     ]     

La méthode à suivre pour appliquer ces annotations varie en fonction de la stratégie de déploiement Istio (Istioctl, Helm ou Operator) utilisée. Pour déterminer l’approche à suivre pour appliquer ces annotations de pod, consultez la documentation Istio.

Dans ces annotations, la valeur <IDENTIFICATEUR_CONTENEUR> est utilisée pour discovery, afin d’appliquer le nom du conteneur par défaut pour les pods du déploiement istiod. Si le nom de votre conteneur est différent, ajustez la valeur en conséquence.

OpenMetrics V2 et V1

Lorsque vous activez l’option de configuration use_openmetrics, l’intégration Istio utilise l’implémentation OpenMetrics V2 du check.

Dans OpenMetrics V2, les métriques sont envoyées par défaut avec une précision renforcée. De plus, leur comportement est plus proche des types de métriques Prometheus. Par exemple, les métriques Prometheus qui se terminent par _count et _sum sont envoyées en tant que monotonic_count par défaut.

La version 2 d’OpenMetrics corrige des problèmes de performance et de qualité de la version 1. Cette nouvelle version bénéficie notamment de la prise en charge de types de métriques natives, d’une configuration améliorée et de types de métriques custom.

Définissez l’option de configuration use_openmetrics sur false pour utiliser l’implémentation OpenMetrics V1. Pour découvrir les paramètres de configuration d’OpenMetrics V1, consultez le fichier conf.yaml.example.

Désactivez l’injection de sidecar pour les pods de l’Agent Datadog

Si vous installez l’Agent Datadog dans un conteneur, Datadog vous recommande de désactiver au préalable l’injection de sidecar Istio.

Versions d’Istio >= 1.10 :

Ajoutez l’étiquette sidecar.istio.io/inject: "false" au DaemonSet datadog-agent :

# (...)
spec:
  template:
    metadata:
      labels:
        sidecar.istio.io/inject: "false"
    # (...)

Vous pouvez également utiliser la commande kubectl patch.

kubectl patch daemonset datadog-agent -p '{"spec":{"template":{"metadata":{"labels":{"sidecar.istio.io/inject":"false"}}}}}'

Versions d’Istio <= 1.9 :

Ajoutez l’annotation sidecar.istio.io/inject: "false" au DaemonSet datadog-agent :

# (...)
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "false"
    # (...)

Avec la commande kubectl patch :

kubectl patch daemonset datadog-agent -p '{"spec":{"template":{"metadata":{"annotations":{"sidecar.istio.io/inject":"false"}}}}}'

Collecte de logs

Istio propose deux types de logs : les logs d’accès Envoy recueillis via l’intégration Envoy, ainsi que les logs Istio.

Disponible à partir des versions > 6.0 de l’Agent

Consultez les modèles d’intégration Autodiscovery pour découvrir comment appliquer les paramètres ci-dessous. Par défaut, la collecte des logs est désactivée dans l’Agent Datadog. Pour l’activer, consultez la section Collecte de logs Kubernetes.

Validation

Lancez la sous-commande info de l’Agent et cherchez istio dans la section Checks.

Données collectées

Métriques

Événements

Le check Istio n’inclut aucun événement.

Checks de service

Dépannage

Erreur « Invalid chunk length »

Si vous rencontrez l’erreur suivante lors de l’implémentation OpenMetricsBaseCheck (V1) d’Istio (intégration d’Istio version 3.13.0 ou antérieure) :

  Error: ("Connection broken: InvalidChunkLength(got length b'', 0 bytes read)",
  InvalidChunkLength(got length b'', 0 bytes read))

Utilisez l’implémentation Openmetrics V2 de l’intégration Istio afin de résoudre cette erreur.

Remarque : vous devez effectuer au minimum une mise à niveau vers l’Agent 7.31.0 et Python 3. Consultez la rubrique Configuration relative à l’activation d’Openmetrics V2.

Utilisation de l’intégration OpenMetrics générique dans un déploiement Istio

Si l’injection de sidecar proxy Istio est activée, la surveillance d’autres métriques Prometheus à l’aide de l’intégration Openmetrics par le biais du même endpoint de métriques que istio_mesh_endpoint peut engendrer une forte utilisation de métriques custom et la collecte de métriques en double.

Pour veiller à ce que votre configuration OpenMetrics ne recueille pas des métriques redondantes, deux options s’offrent à vous :

1. Utilisez une expression spécifique pour l’option de configuration metrics, afin de renvoyer uniquement les métriques pertinentes.
2. Sinon, si vous utilisez le wildcard * pour metrics, vous pouvez envisager d’utiliser les options d’intégration OpenMetrics suivantes afin d’exclure les métriques déjà prises en charge par les intégrations Istio et Envoy.

Configuration d’Openmetrics V2 avec la collecte générique de métriques

Veillez à exclure les métriques Istio et Envoy de votre configuration pour éviter qu’un nombre élevé de métriques custom ne vous soit facturé. Utilisez exclude_metrics si vous utilisez la configuration Openmetrics V2 (openmetrics_endpoint activé).

## Chaque instance est programmée indépendamment des autres.
#
instances:
  - openmetrics_endpoint: <ENDPOINT_OPENMETRICS>
    metrics: [*]
    exclude_metrics:
      - istio_*
      - envoy_*

Configuration d’Openmetrics V1 (ancienne version) avec la collecte générique de métriques

Veillez à exclure les métriques Istio et Envoy de votre configuration pour éviter qu’un nombre élevé de métriques custom ne vous soit facturé. Utilisez ignore_metrics si vous utilisez la configuration Openmetrics V1 (prometheus_url activé).

instances:
  - prometheus_url: <URL_PROMETHEUS>
    metrics:
      - *
    ignore_metrics:
      - istio_*
      - envoy_*

Besoin d’aide ? Contactez l’assistance Datadog.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles :

• Surveiller votre maillage de services Istio avec Datadog
• Découvrir comment Datadog recueille des métriques clés pour surveiller Istio
• Comment surveiller Istio avec Datadog