Configuration d'un collecteur OpenTelemetry pour Reconnaissance d'API

Configuration d'une source de données « Istio »

Enregistrez le collecteur dans votre instance d' IstioMeshConfig en exécutant la commande suivante et en ajoutant un fournisseur de découverte.

kubectl edit configmap istio -n istio-system

Où istio-system se trouve l'espace de noms dans lequel Istio est déployé sur votre cluster. L'espace de nom par défaut est istio-system.

Mettez à jour la section extensionProviders avec les informations suivantes:

    extensionProviders:
      - name: "discoveryOtelCollector"
        opentelemetry:
          service: "management-api-discovery-otel-collector.istio-system.svc.cluster.local"
          port: 5555

Pour plus d'informations sur les fournisseurs, consultez la section « Sélection des fournisseurs » de la documentation relative à l' Istio, disponible à l'adresse https://istio.io/latest/docs/tasks/observability/telemetry/#provider-selection.

Si vous avez déployé Istio à l'aide de l'outil IstioOperator, vous pouvez configurer ces informations à l'aide de l'outil MeshConfig. Pour plus d'informations, consultez la documentation d' Istio à l'adresse https://istio.io/v1.10/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig.

Configuration d'une source de données « NGINX »

Il existe plusieurs façons de configurer votre source de données NGINX pour prendre en charge le collecteur OpenTelemetry, mais les informations suivantes présentent les quatre principales options. Pour plus d'informations sur la configuration, consultez le fichier Lisez-moi de l' NGINXgithub.com.

1. NGINX otel-webserver-module
   Pour configurer le webserver module afin qu'il envoie des traces au collecteur OpenTelemetry, vous pouvez mettre à jour le déploiement NGINX pour qu'il utilise le OTEL_EXPORTER_OTLP_ENDPOINT. Par exemple :

   env:
   - name: OTEL_EXPORTER_OTLP_ENDPOINT
     value: management-api-discovery-otel-collector.namespace.svc:5555

   Vous pouvez également mettre à jour le NginxModuleOtelExporterEndpoint fichier de configuration de l' OpenTelemetry sur votre serveur NGINX.

   Le nom de la source de données des API collectées via cette intégration est dérivé de l'attribut NginxModuleServiceName de la configuration de l' OpenTelemetry.

2. NGINXinstrumentation module

   Tout comme pour le webserver module, vous pouvez mettre à jour le déploiement de NGINX pour utiliser le OTEL_EXPORTER_OTLP_ENDPOINT, ou vous pouvez configurer le point de terminaison dans le otel-nginx.toml.

   Ce module permet d'utiliser différentes variables dans nginx.conf afin de personnaliser les traces qui peuvent être envoyées au service de reconnaissance d'API .

   Le nom de la source de données des API collectées via cette intégration correspond au nom OTEL_SERVICE_NAME du déploiement de l' NGINX, ou au nom du service de l' otel-nginx.toml[...]. Vous pouvez également définir des attributs de trace personnalisés, notamment en utilisant ibm-api-discovery-datasource.name pour définir un nom de source de données personnalisé.

3. Ingress- Nginx Contrôleur
   Le contrôleur Ingress-Nginx utilise le module instrumentation , de sorte que les mêmes options de configuration s'appliquent. Au minimum, le Kubernetes Ingress-Nginx ConfigMap doit être configuré avec les détails suivants pour collecter les traces du service de back end:

   enable-opentelemetry: "true"
   otlp-collector-host: "management-api-discovery-otel-collector.namespace.svc:5555"

4. NGINX OpenTelemetry module

   Vous pouvez configurer ce module pour qu'il envoie des traces au collecteur OpenTelemetry en définissant le paramètre otel_exporter dans la configuration de NGINX.

   Ce module permet d'utiliser différentes variables dans nginx.conf afin de personnaliser les traces qui peuvent être envoyées au service de reconnaissance d'API.

   Les noms des sources de données des API collectées via cette intégration sont dérivés du nom OTEL_SERVICE_NAME du déploiement de l' NGINX. Vous pouvez également définir des attributs de trace personnalisés, notamment en utilisant ibm-api-discovery-datasource.name pour définir un nom de source de données personnalisé.

• discovery.datasource_type - le type de source de données (facultatif). Les valeurs valables sont istio, nginx, ou laissées en blanc. Si c'est le cas istio, le rapport de télémétrie (CR) requis pour l' Istio est installé. Sinon, la fonction ` Helm ` ignore la création de données de télémétrie.
• discovery.datasource_name - le nom de la source de données pour toutes les API découvertes par le collecteur (facultatif). Si le nom de la source de données est vide, l'espace de nom de l'API collectée est utilisé.
• discovery.apic_host_domain -nom de domaine de l'instance API ConnectAI Gateway où les API découvertes sont envoyées. Par exemple, us-east-a.apiconnect.automation.ibm.comdw-rosa-01.owe.p1.openshiftapps.com.
• discovery.provider_org -nom de l'organisation de type fournisseur dans API Manager.
• discovery.api_key -Données d'identification requises pour l'envoi des fichiers d'API au gestionnaire d'API. Vous pouvez obtenir la clé d'API auprès de l'utilisateur qui a accès à API Manager pour l'envoi d'API. Pour savoir comment obtenir une clé API, consultez la section « Gestion des clés API REST de la plateforme ». Le api_key est ajouté à un secret Kubernetes dans le cadre du déploiement, puis monté sur le pod de déploiement du collecteur.
• discovery.processors -indicateur permettant d'activer ou de désactiver les processeurs. Peut être réglé surenabled oudisabled . Si réglé surenabled , leConfigMap active le processeur de limitation de lots et de mémoire existant et ne fournira aucun processeur dans les autres cas. Si vous tentez d'envoyer une trace avec plus de 11000 intervalles à la fois, le collecteur rejette le contenu et vous devez activer le processeur de traitement par lots. Les processeurs de limitation de mémoire et de traitement par lots disponibles sont configurables en fonction de la configuration système de base requise. Lelimit_mib dans le processeur limiteur de mémoire peut être augmenté si vous mettez à jour les limites de ressources du déploiement du collecteur. Les processeurs attributes/ibm-apiconnect, redaction/ibm-apiconnect, filter/ibm-apiconnect, transform/ibm-apiconnect et resource/ibm-apiconnect du service.pipelines.traces.processors doivent être maintenus dans le même ordre lors de l'activation des processeurs, car certains processeurs intégrés améliorent les performances du collecteur. Si vous n'incluez pas ces processeurs, la qualité du trafic collecté est dégradée, ainsi que les performances du collecteur. Pour plus d'informations, consultez un exemple de modèle de processeur ConfigMap, les informations relatives au processeur par lots OpenTelemetry, ainsi que celles concernant le processeur de limitation de mémoire OpenTelemetry.
• namespace - l'espace de noms dans lequel Istio ou NGINX est déployé sur votre cluster. Conformément aux exigences de l'intégration de la télémétrie de l' Istio, le pod collecteur sera également déployé ici.
• images.api_discovery_collector -active la mise à niveau du déploiement du collecteur à mesure que de nouvelles versions sont publiées. Notez que les collecteurs nécessiteront des mises à jour à l'avenir afin de s'assurer qu'ils restent compatibles avec le service de reconnaissance. Les détails concernant les mises à jour sont disponibles dans le dépôt https://github.com/ibm-apiconnect/api-discovery-otel-collector.
• logging.log_level -niveau de journalisation ; le niveau par défaut est info. A des fins de débogage, le niveau peut être augmenté à debug si nécessaire.
• logging.debugexporter_verbosity -niveau de prolixité du journal de débogage ; la valeur par défaut est basic. Pour des informations détaillées sur l'exportateur, le niveau de prolixité peut être augmenté à detailed. Toutefois, il est recommandé de conserver la verbosité basic pour un collecteur qui est traversé par une grande quantité de trafic.

• telemetry_namespace - l'espace de noms dans lequel le CR de télémétrie « Istio » sera déployé (facultatif). Par défaut, le fichier de valeurs définit cet espace de nom sur istio-system, en tant qu'espace de nom de configuration racine pour fournir une configuration de collecte de niveau de maillage. Toutefois, ce paramètre peut être personnalisé en fonction des exigences de votre collection pour les applications déployées que vous souhaitez reconnaître. Pour plus d'informations, consultez les informations sur la télémétrie à l'adresse https://istio.io/latest/docs/reference/config/telemetry/.

---
discovery:
  # platform_api_prefix is not required to change for API Connect on Cloud
  datasource_type: istio
  # supported values are istio, nginx
  datasource_name: my-data-source
  platform_api_prefix: platform-api
  apic_host_domain: us-east-a.apiconnect.automation.ibm.com
  provider_org: myOrgName
  api_key: xxxxxx
  namespace: istio-system
  telemetry_namespace: istio-system
  # Enable the processor and edit the processor-configmap to choose values for batch and memory_limiter
  # supported values are enabled and disabled
  processors: disabled
logging:
  log_level: info
  # supported values are json and console
  log_encoder: json
  # supported values are basic and detailed
  debugexporter_verbosity: basic

images:
  api_discovery_collector: ghcr.io/ibm-apiconnect/api-discovery-otel-collector:20240612-173911

Pour en savoir plus sur la configuration du OpenTelemetry collecteur, consultez le fichier OpenTelemetry collecteur pour la découverte d'API Lisez-moi sur github.com. Ces ressources API ConnectAI Gateway incluent des exemples de travail avec un référentiel de test.

helm template . | kubectl apply -f -