Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Premiers pas avec l’opérateur OpenTelemetry sur Kubernetes

Voici la configuration que nous allons créer, pour une application qui doit être surveillée :

  • L’application / charge de travail surveillée s’exécutant dans le cluster A, auto-instrumentée par l’opérateur

  • L’opérateur OpenTelemetry dans le cluster A

  • Un collecteur créé par l’opérateur

  • SUSE Observability s’exécutant dans le cluster B, ou SUSE Cloud Observability

Instrumentation des conteneurs avec l’auto-instrumentation de l’opérateur OpenTelemetry

Installez l’opérateur

L’opérateur OpenTelemetry offre des fonctionnalités supplémentaires par rapport à la configuration Kubernetes normale :

  • Il peut auto-instrumenter vos pods d’application pour les langages pris en charge (Java, .NET, Python, Golang, Node.js), sans avoir à modifier les applications ou les images Docker.

  • Il peut être utilisé comme remplacement de l’opérateur Prometheus et commencer à récupérer les points de terminaison des exportateurs Prometheus basés sur les moniteurs de services et de pods.

Créer un jeton de service

Il existe deux façons de créer un jeton de service :

  • SUSE Observability UI - ouvrez le menu principal en cliquant en haut à gauche de l’écran et allez à StackPacks > Open Telemetry. Si vous ne l’avez pas encore fait, cliquez sur le bouton INSTALL. Cliquez sur le bouton CREATE NEW SERVICE TOKEN et copiez la valeur dans votre presse-papiers.

  • SUSE Observability CLI - voir Gérer les jetons de service

La valeur du jeton de service doit être utilisée là où les instructions ci-dessous mentionnent <SERVICE_TOKEN>.

Créer l’espace de noms et un secret pour le jeton de service

Nous allons installer dans l’espace de noms open-telemetry et utiliser le token de service :

kubectl create namespace open-telemetry
kubectl create secret generic open-telemetry-collector \
    --namespace open-telemetry \
    --from-literal=API_KEY='<SERVICE_TOKEN>'

Configurer et installer l’opérateur

L’opérateur est installé avec un chart Helm, donc commencez par configurer le dépôt de charts.

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts

Créons un fichier otel-operator.yaml pour configurer l’opérateur :

otel-operator.yaml
# Add image pull secret for private registries
imagePullSecrets: []
manager:
  image:
    # Uses chart.appVersion for the tag
    repository: ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator
  collectorImage:
    # find the latest collector releases at https://github.com/open-telemetry/opentelemetry-collector-releases/releases
    repository: otel/opentelemetry-collector-k8s
    tag: 0.123.0
  targetAllocatorImage:
    repository: ""
    tag: ""
  # Only needed when overriding the image repository, make sure to always specify both the image and tag:
  autoInstrumentationImage:
    java:
      repository: ""
      tag: ""
    nodejs:
      repository: ""
      tag: ""
    python:
      repository: ""
      tag: ""
    dotnet:
      repository: ""
      tag: ""
    # The Go instrumentation support in the operator is disabled by default.
    # To enable it, use the operator.autoinstrumentation.go feature gate.
    go:
      repository: ""
      tag: ""

admissionWebhooks:
  # A production setup should use certManager to generate the certificate, without certmanager the certificate will be generated during the Helm install
  certManager:
    enabled: false
  # The operator has validation and mutation hooks that need a certificate, with this we generate that automatically
  autoGenerateCert:
    enabled: true

Installez maintenant le collecteur, en utilisant le fichier de configuration :

helm upgrade --install opentelemetry-operator open-telemetry/opentelemetry-operator \
  --namespace open-telemetry \
  --values otel-operator.yaml

Cela installe uniquement l’opérateur. Continuez à installer le collecteur et à activer l’auto-instrumentation.

Le collecteur OpenTelemetry

L’opérateur gère un ou plusieurs déploiements de collecteurs via une ressource personnalisée Kubernetes de type OpenTelemetryCollector. Nous allons en créer un en utilisant la même configuration que celle utilisée dans le guide de démarrage Kubernetes.

Il utilise le secret créé plus tôt dans le guide. Assurez-vous de remplacer <otlp-suse-observability-endpoint:port> par votre point de terminaison OTLP (voir API OTLP pour votre point de terminaison) et insérez le nom de votre cluster Kubernetes à la place de <your-cluster-name> :

collector.yaml
apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: otel-collector
spec:
  mode: deployment
  envFrom:
  - secretRef:
      name: open-telemetry-collector
  # optional service-account for pulling the collector image from a private registries
  # serviceAccount: otel-collector
  config:
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
      # Scrape the collectors own metrics
      prometheus:
        config:
          scrape_configs:
          - job_name: opentelemetry-collector
            scrape_interval: 10s
            static_configs:
            - targets:
              - ${env:MY_POD_IP}:8888
    extensions:
      health_check:
        endpoint: ${env:MY_POD_IP}:13133
      # Use the API key from the env for authentication
      bearertokenauth:
        scheme: SUSEObservability
        token: "${env:API_KEY}"
    exporters:
      debug: {}
      nop: {}
      otlp/suse-observability:
        auth:
          authenticator: bearertokenauth
        # Put in your own otlp endpoint, for example otlp-suse-observability.my.company.com:443
        endpoint: <otlp-suse-observability-endpoint:port>
        compression: snappy
    processors:
      memory_limiter:
        check_interval: 5s
        limit_percentage: 80
        spike_limit_percentage: 25
      batch: {}
      resource:
        attributes:
        - key: k8s.cluster.name
          action: upsert
          # Insert your own cluster name
          value: <your-cluster-name>
        - key: service.instance.id
          from_attribute: k8s.pod.uid
          action: insert
          # Use the k8s namespace also as the open telemetry namespace
        - key: service.namespace
          from_attribute: k8s.namespace.name
          action: insert
    connectors:
      # Generate metrics for spans
      spanmetrics:
        metrics_expiration: 5m
        namespace: otel_span
    service:
      extensions: [ health_check,  bearertokenauth ]
      pipelines:
        traces:
          receivers: [otlp]
          processors: [memory_limiter, resource, batch]
          exporters: [debug, spanmetrics, otlp/suse-observability]
        metrics:
          receivers: [otlp, spanmetrics, prometheus]
          processors: [memory_limiter, resource, batch]
          exporters: [debug, otlp/suse-observability]
        logs:
          receivers: [otlp]
          processors: []
          exporters: [nop]
      telemetry:
        metrics:
          address: ${env:MY_POD_IP}:8888

Utilisez le même nom de cluster que celui utilisé pour installer l’agent SUSE Observability si vous utilisez également l’agent SUSE Observability avec le stackpack Kubernetes. Utiliser un nom de cluster différent entraînera une perspective de traces vide pour les composants Kubernetes et rendra globalement la corrélation des informations beaucoup plus difficile pour SUSE Observability et vos utilisateurs.

Appliquez maintenant ce collector.yaml dans l’espace de noms open-telemetry pour déployer un collecteur :

kubectl apply --namespace open-telemetry -f collector.yaml

Le collecteur propose de nombreux récepteurs, processeurs et exportateurs ; pour plus de détails, consultez notre page du collecteur. Pour une utilisation en production, de grandes quantités de spans sont souvent générées et vous voudrez commencer à configurer l’échantillonnage.

Auto-instrumentation

Configurer l’auto-instrumentation

Nous devons maintenant indiquer à l’opérateur comment configurer l’auto-instrumentation pour les différents langages en utilisant une autre ressource personnalisée, de type Instrumentation. Il est principalement utilisé pour configurer le collecteur qui vient d’être déployé comme point de terminaison de télémétrie pour les applications instrumentées.

Il peut être défini à un seul endroit et utilisé par tous les pods du cluster, mais il est également possible d’avoir un Instrumentation différent dans chaque espace de noms. Nous allons faire cela ici. Notez que si vous avez utilisé un espace de noms différent ou un nom différent pour le collecteur otel, le point de terminaison dans ce fichier doit être mis à jour en conséquence.

Créer un instrumentation.yaml :

instrumentation.yaml
apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: otel-instrumentation
spec:
  exporter:
    # default endpoint for the instrumentation
    endpoint: http://otel-collector-collector.open-telemetry.svc.cluster.local:4317
  propagators:
    - tracecontext
    - baggage
  defaults:
    # To use the standard app.kubernetes.io/ labels for the service name, version and namespace:
    useLabelsForResourceAttributes: true
  python:
    env:
      # Python autoinstrumentation uses http/proto by default, so data must be sent to 4318 instead of 4317.
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: http://otel-collector-collector.open-telemetry.svc.cluster.local:4318
  dotnet:
    env:
      # Dotnet autoinstrumentation uses http/proto by default, so data must be sent to 4318 instead of 4317.
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: http://otel-collector-collector.open-telemetry.svc.cluster.local:4318
  go:
    env:
      # Go autoinstrumentation uses http/proto by default, so data must be sent to 4318 instead of 4317.
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: http://otel-collector-collector.open-telemetry.svc.cluster.local:4318

Appliquez maintenant le instrumentation.yaml également dans l’espace de noms open-telemetry :

kubectl apply --namespace open-telemetry -f instrumentation.yaml

Activer l’auto-instrumentation pour un pod

Pour indiquer à l’opérateur d’auto-instrumenter vos pods d’application, nous devons ajouter une annotation au pod :

  • Java : instrumentation.opentelemetry.io/inject-java: open-telemetry/otel-instrumentation

  • NodeJS : instrumentation.opentelemetry.io/inject-nodejs: open-telemetry/otel-instrumentation

  • Python : instrumentation.opentelemetry.io/inject-python: open-telemetry/otel-instrumentation

  • Go : instrumentation.opentelemetry.io/inject-go: open-telemetry/otel-instrumentation

Notez que la valeur de l’annotation fait référence à l’espace de noms et au nom de la ressource Instrumentation que nous avons créée. Les autres options sont :

  • "true" - injecter la ressource personnalisée Instrumentation depuis l’espace de noms.

  • "my-instrumentation" - nom de la ressource personnalisée Instrumentation dans l’espace de noms actuel.

  • "my-other-namespace/my-instrumentation" - espace de noms et nom de la ressource personnalisée Instrumentation dans un autre espace de noms.

  • "false" - ne pas injecter

Lorsqu’un pod avec l’une des annotations est créé, l’opérateur modifie le pod via un hook de mutation :

  • Il ajoute un conteneur d’initialisation qui fournit la bibliothèque d’auto-instrumentation

  • Il modifie le premier conteneur du pod pour charger l’instrumentation au démarrage et ajoute des variables d’environnement pour configurer l’instrumentation

Si vous devez personnaliser quels conteneurs doivent être instrumentés, utilisez la documentation de l’opérateur.

L’auto-instrumentation Go nécessite des autorisations élevées. Ces autorisations sont définies automatiquement par l’opérateur :

securityContext:
  privileged: true
  runAsUser: 0

Consultez les résultats

Allez sur SUSE Observability et assurez-vous que le Stackpack Open Telemetry est installé (via le menu principal -> Stackpacks).

Après un court instant, si vos pods reçoivent du trafic, vous devriez pouvoir les trouver sous leur nom de service dans les aperçus Open Telemetry -> services et instances de service. Les traces apparaîtront dans le explorateur de traces et dans la perspective de traces pour les composants de service et d’instance de service. Les métriques de span et les métriques spécifiques au langage (si disponibles) seront accessibles dans la perspective des métriques pour les composants.

Si vous avez également le stackpack Kubernetes installé, les pods instrumentés auront également les traces disponibles dans la perspective de traces.

Rancher RBAC

Pour que Rancher RBAC fonctionne, les données de télémétrie doivent avoir les attributs de ressource suivants présents :

  • k8s.cluster.name - le nom du Cluster tel qu’utilisé par le stackpack Kubernetes

  • k8s.namespace.name - un espace de noms géré par un Rancher Project

L’opérateur Kubernetes injectera par défaut ces attributs dans toutes les données de télémétrie envoyées.

Étapes suivantes

Vous pouvez ajouter de nouveaux graphiques aux composants, par exemple, le service ou l’instance de service, pour votre application, en suivant notre guide. Il est également possible de créer nouveaux moniteurs en utilisant les métriques et de procéder à la configuration de notifications pour être averti lorsque votre application n’est pas disponible ou rencontre des problèmes de performance.

L’opérateur, le OpenTelemetryCollector et la ressource personnalisée Instrumentation ont plus d’options qui sont documentées dans le readme du dépôt de l’opérateur. Par exemple, il est possible d’installer un allocateur cible optionnel via la ressource OpenTelemetryCollector, qui peut être utilisé pour configurer le récepteur Prometheus du collecteur. Ceci est particulièrement utile lorsque vous souhaitez remplacer l’opérateur Prometheus et que vous utilisez ses ressources personnalisées ServiceMonitor et PodMonitor.

Pour en savoir plus.