Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Erste Schritte mit dem Open Telemetry Operator auf Kubernetes

Hier ist das Setup, das wir für eine zu überwachende Anwendung erstellen werden:

  • Die überwachte Anwendung / Arbeitslast, die im Cluster A läuft und automatisch vom Operator instrumentiert wird

  • Der Open Telemetry Operator im Cluster A

  • Ein vom Operator erstellter Collector

  • SUSE Observability, das in Cluster B läuft, oder SUSE Cloud Observability

Containerinstrumentierung mit der automatischen Instrumentierung des Open Telemetry Operators

Installieren Sie den Operator

Der Open Telemetry Operator bietet einige zusätzliche Funktionen im Vergleich zur normalen Kubernetes-Installation:

  • Er kann Ihre Anwendungs-Pods für unterstützte Sprachen (Java, .NET, Python, Golang, Node.js) automatisch instrumentieren, ohne dass die Anwendungen oder Docker-Images geändert werden müssen.

  • Er kann als Ersatz für den Prometheus-Operator eingesetzt werden und beginnt, Prometheus-Exporter-Endpunkte basierend auf Service- und Pod-Überwachungen zu scrapen.

Erstellen Sie ein Service-Token

Es gibt zwei Möglichkeiten, ein Service-Token zu erstellen:

  • SUSE Observability UI - Öffnen Sie das Hauptmenü, indem Sie oben links auf dem Bildschirm klicken, und gehen Sie zu StackPacks > Open Telemetry. Wenn Sie dies noch nicht getan haben, klicken Sie auf die INSTALL-Schaltfläche. Klicken Sie auf die CREATE NEW SERVICE TOKEN-Schaltfläche und kopieren Sie den Wert in Ihre Zwischenablage.

  • SUSE Observability CLI - siehe Service-Token verwalten

Der Wert des Service-Tokens muss dort verwendet werden, wo die folgenden Anweisungen <SERVICE_TOKEN> erwähnen.

Erstellen Sie den Namespace und ein Secret für das Service-Token.

Wir werden im open-telemetry Namespace installieren und das Service-Token verwenden:

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

Konfigurieren und installieren Sie den Operator

Der Operator wird mit einem Helm-Chart installiert, also konfigurieren Sie zuerst das Chart-Repository.

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

Lassen Sie uns eine otel-operator.yaml Datei erstellen, um den Operator zu konfigurieren:

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

Installieren Sie jetzt den Collector unter Verwendung der Konfigurationsdatei:

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

Dies installiert nur den Operator. Fahren Sie fort, um den Collector zu installieren und die automatische Instrumentierung zu aktivieren.

Der Open Telemetrie-Collector

Der Operator verwaltet eine oder mehrere Collector-Implementierungen über eine benutzerdefinierte Kubernetes-Ressource vom Typ OpenTelemetryCollector. Wir werden einen erstellen, der die gleiche Konfiguration wie im Kubernetes-Einstiegshandbuch verwendet.

Er verwendet das zuvor im Handbuch erstellte Geheimnis. Stellen Sie sicher, dass Sie <otlp-suse-observability-endpoint:port> durch Ihren OTLP-Endpunkt ersetzen (siehe OTLP API für Ihren Endpunkt) und fügen Sie den Namen Ihres Kubernetes-Clusters anstelle von <your-cluster-name> ein:

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

Verwenden Sie denselben Clusternamen wie für die Installation des SUSE Observability-Agenten, wenn Sie auch den SUSE Observability-Agenten mit dem Kubernetes-Stackpack verwenden. Die Verwendung eines anderen Clusternamens führt zu einer leeren Trace-Perspektive für Kubernetes-Komponenten und macht es insgesamt viel schwieriger, Informationen für SUSE Observability und Ihre Benutzer zu korrelieren.

Wenden Sie dieses collector.yaml im open-telemetry-Namespace an, um einen Collector bereitzustellen:

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

Der Collector bietet viele weitere Konfigurationsmöglichkeiten für Receiver, Prozessoren und Exporter. Für weitere Details siehe unsere Collector-Seite. Für den Produktionseinsatz werden oft große Mengen an Spans generiert, und Sie sollten beginnen, sampling einzurichten.

Automatische Instrumentierung

Automatische Instrumentierung konfigurieren

Jetzt müssen wir dem Operator mitteilen, wie die automatische Instrumentierung für die verschiedenen Sprachen mit einer anderen benutzerdefinierten Ressource des Typs Instrumentation konfiguriert werden kann. Es wird hauptsächlich verwendet, um den gerade bereitgestellten Collector als Telemetrie-Endpunkt für die instrumentierten Anwendungen zu konfigurieren.

Es kann an einem einzigen Ort definiert und von allen Pods im Cluster verwendet werden, aber es ist auch möglich, in jedem Namespace einen anderen Instrumentation zu haben. Wir werden hier die erstgenannte Option wählen. Beachten Sie, dass, wenn Sie einen anderen Namespace oder einen anderen Namen für den otel-Collector verwendet haben, der Endpunkt in dieser Datei entsprechend aktualisiert werden muss.

Erstellen Sie ein 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

Wenden Sie das instrumentation.yaml auch im open-telemetry-Namespace an:

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

Aktivieren Sie die automatische Instrumentierung für einen Pod

Um den Operator anzuweisen, Ihre Anwendungs-Pods automatisch zu instrumentieren, müssen wir eine Annotation zum Pod hinzufügen:

  • 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

Beachten Sie, dass der Wert der Annotation auf den Namespace und den Namen der Instrumentation-Ressource verweist, die wir erstellt haben. Weitere Optionen sind:

  • "true" - injizieren und Instrumentation benutzerdefinierte Ressource aus dem Namespace.

  • "my-instrumentation" - Name der Instrumentation benutzerdefinierten Ressource im aktuellen Namespace.

  • "my-other-namespace/my-instrumentation" - Namespace und Name der Instrumentation benutzerdefinierten Ressource in einem anderen Namespace.

  • "false" - nicht injizieren

Wenn ein Pod mit einer der Annotationen erstellt wird, ändert der Operator den Pod über einen Mutations-Hook:

  • Er fügt einen Init-Container hinzu, der die automatische Instrumentierungsbibliothek bereitstellt.

  • Er ändert den ersten Container des Pods, um die Instrumentierung beim Start zu laden, und fügt Umgebungsvariablen hinzu, um die Instrumentierung zu konfigurieren.

Wenn Sie anpassen müssen, welche Container instrumentiert werden sollen, verwenden Sie die Dokumentation des Operators.

Die Go-Auto-Instrumentierung erfordert erhöhte Berechtigungen. Diese Berechtigungen werden automatisch vom Operator festgelegt:

securityContext:
  privileged: true
  runAsUser: 0

Ergebnisse anzeigen

Gehen Sie zu SUSE Observability und stellen Sie sicher, dass das Open Telemetry Stackpack installiert ist (über das Hauptmenü -> Stackpacks).

Nach kurzer Zeit und wenn Ihre Pods Verkehr erhalten, sollten Sie sie unter ihrem Dienstnamen in den Übersichten von Open Telemetry -> Dienste und Dienstinstanzen finden können. Traces erscheinen im Trace Explorer und in der Trace-Perspektive für die Komponenten Dienst und Dienstinstanz. Die Span-Metriken und sprachspezifischen Metriken (sofern verfügbar) werden in der Metriken-Perspektive für die Komponenten verfügbar sein.

Wenn Sie auch das Kubernetes-Stackpack installiert haben, sind die instrumentierten Pods ebenfalls in der Trace-Perspektive verfügbar.

Rancher RBAC

Damit Rancher RBAC funktioniert, müssen die Telemetriedaten die folgenden Ressourcenattribute enthalten:

  • k8s.cluster.name - der Cluster Name, wie er vom Kubernetes-Stackpack verwendet wird

  • k8s.namespace.name - ein Namespace, der von einem Rancher Projekt verwaltet wird

Der Kubernetes-Operator wird diese Attribute standardmäßig in alle gesendeten Telemetriedaten injizieren.

Nächste Schritte

Sie können neue Diagramme zu Komponenten, zum Beispiel dem Dienst oder der Dienstinstanz, für Ihre Anwendung hinzufügen, indem Sie unserem Leitfaden folgen. Es ist auch möglich, neue Monitore zu erstellen, Metriken zu verwenden und Benachrichtigungen einzurichten, sodass Sie benachrichtigt werden, wenn Ihre Anwendung nicht verfügbar ist oder Leistungsprobleme auftreten.

Der Operator, die OpenTelemetryCollector und die Instrumentation benutzerdefinierte Ressource haben weitere Optionen, die in der README des Operator-Repositories dokumentiert sind. Es ist beispielsweise möglich, einen optionalen Ziel-Allocator über die OpenTelemetryCollector Ressource zu installieren, der verwendet werden kann, um den Prometheus-Empfänger des Collectors zu konfigurieren. Dies ist besonders nützlich, wenn Sie den Prometheus-Operator ersetzen möchten und seine ServiceMonitor und PodMonitor benutzerdefinierten Ressourcen verwenden.

Weitere Informationen