OpenTelemetry mit Shopware auf Kubernetes – so geht’s

Der erste Schritt zur Behebung eines Systemausfalls besteht darin, die Ursache zu identifizieren. Je mehr relevante Informationen über den inneren Zustand des Systems verfügbar sind, desto schneller lässt sich die Wurzel des Problems finden. Die Menge, Relevanz und Qualität dieser Informationen fallen unter den Begriff Observability. Beim Betrieb von Shopware auf Kubernetes erfordert eine gute Observability den Einsatz der richtigen Tools, um Stabilität und Performance im Blick zu behalten.

In diesem Artikel erklären wir, woher eine gute Observability kommt und wie man die besten Werkzeuge auswählt. Zusätzlich zeigen wir, wie man OpenTelemetry für Shopware auf Kubernetes einrichtet.

Was ist Observability?

Observability ist eine Systemeigenschaft, die den Grad definiert, in dem das System umsetzbare Erkenntnisse generieren kann. Sie ermöglicht es Benutzern, den Zustand eines Systems anhand dieser externen Ausgaben zu verstehen und (korrigierende) Maßnahmen zu ergreifen.

— https://glossary.cncf.io/observability/

Je besser die Observability eines Systems ist, desto einfacher lassen sich Probleme mit geringem Vorwissen beheben.

Die drei Säulen der Observability

Observability basiert auf drei Datentypen: Logs, Metriken und Traces. Jeder Typ liefert eine andere Art von Informationen über das System.

Die erste Säule: Logs

Logs sind detaillierte Aufzeichnungen von Ereignissen innerhalb eines Systems. Sie enthalten Informationen zu laufenden Prozessen oder Details zu aufgetretenen Fehlern.

In Kubernetes werden Logs von speziellen Tools wie Loki gebündelt und für die weitere Verarbeitung und Analyse gespeichert.

Die zweite Säule: Metriken

Metriken sind Messungen eines bestimmten Systemzustands zu einem präzisen Zeitpunkt. Sie liefern eine Fülle von Informationen. Zu den häufig verwendeten Metriken zählen unter anderem die Anzahl der erfolgreichen und fehlgeschlagenen HTTP-Antworten, der Speicherverbrauch einer Anwendung oder der verfügbare Speicherplatz auf einem Server.

Metriken sind numerisch. Das macht sie einfach zu verarbeiten, zu korrelieren und ihre Veränderung über die Zeit zu visualisieren. Letztendlich bieten sie jedoch nur einen allgemeinen Überblick über den Systemzustand – nicht detailliert genug für eine tiefere Analyse.

Die dritte Säule: Traces

Traces sind Aufzeichnungen über die inneren Abläufe eines Programms. Sie erfassen Informationen darüber, welche Programmteile in welcher Reihenfolge ausgeführt wurden und wie lange es gedauert hat. Mit Traces können Entwickler Codeteile identifizieren, die unter realen Bedingungen langsam oder instabil sind.

Dies sind die detailliertesten Informationen, die man über Software im Produktivbetrieb erhalten kann. Obwohl sie eine unschätzbare Hilfe bei der Ursachenforschung eines Problems darstellen, sind sie zu detailliert, um einen Überblick über den Gesamtzustand des Systems zu gewinnen. Um das vollständige Bild zu erhalten, müssen alle drei Arten von Observability-Daten genutzt werden.

Logging- und Monitoring-Tools gehören zu den ersten Dingen, die bei der Erstellung eines Kubernetes-Clusters eingerichtet werden. Große Cloud-Anbieter integrieren sie oft bereits in ihre verwalteten Kubernetes-Angebote.

Bei Traces verhält es sich jedoch anders.

Da das Tracing eng mit der von der Anwendung verwendeten Programmiersprache verbunden ist, erfordert es spezielle Tools zur Verarbeitung. Zudem muss man sich zwischen der Nutzung diverser Dienste und dem Aufbau einer eigenen Observability-Toolchain entscheiden.

Wann OpenTelemetry und Grafana einer Observability-Platform-as-a-Service vorzuziehen sind

Bei Kiwee setzen wir seit vielen Jahren auf New Relic. Nachdem wir 2019 jedoch auf Kubernetes umgestiegen waren, wurde klar, dass wir mehr Flexibilität benötigten als eine Observability-Plattform von Drittanbietern zu niedrigeren Kosten bieten kann.

Hier kam Grafana ins Spiel. Es avancierte schnell zu unserem bevorzugten Tool für die Verarbeitung von Kubernetes-Metriken und -Logs. Für das Tracing verließen wir uns allerdings noch eine Zeit lang auf New Relic - bis zur Einführung von Grafana Tempo und der nativen Unterstützung von OpenTelemetry durch Shopware.

So schneidet New Relic im Vergleich zu Grafana mit OpenTelemetry ab:

Kernmerkmale

Alle in diesem Artikel benötigten Komponenten zur Verarbeitung von Traces sind Open-Source-Projekte. Sie nutzen das OpenTelemetry-Protokoll (OTLP), das Teil des von der Cloud Native Computing Foundation verwalteten OpenTelemetry-Projekts ist.

Die Verwendung eines gemeinsamen, offenen Standards ermöglicht den Aufbau eines eigenen, hochgradig anpassbaren Observability-Stacks. In diesem Setup spezialisiert sich jede Komponente auf eine bestimmte Aufgabe, wie die Verarbeitung von Logs, Metriken und Traces, die Datenvisualisierung oder die Alarmierung.

Kommerzielle Plattformen hingegen zielen darauf ab, ein All-in-One-Tool für Observability bereitzustellen. Sie kombinieren Datenverarbeitung, Visualisierung und Alarmierung in einem einzigen Dienst. Das bedeutet: Nach dem Senden der Daten übernimmt die Plattform die Kontrolle. Sie entscheidet über Verarbeitung, Darstellung, Zugriff und Integration mit anderen Diensten, z. B. für Warnmeldungen.

Erste Schritte

Mit einer geführten Installation ist die Einrichtung der New Relic-Instrumentierung recht einfach. Nach der Kontoerstellung installiert man den Agenten und gibt ihm einen Anwendungsnamen sowie New Relic API-Anmeldeinformationen. Sobald dies erledigt ist, erscheinen die Traces in New Relic.

Um Anwendungs-Traces in Grafana zu visualisieren, müssen hingegen einige separate Komponenten eingerichtet werden - darunter der OTel-Exporter für PHP, der OpenTelemetry Collector, Grafana Tempo und Grafana selbst.

Der Aufbau eines eigenen Observability-Stacks ist in der Tat aufwendiger als die Integration eines externen Dienstes. Im Falle von Kubernetes wird die Einrichtung jedoch weitgehend durch die Verwendung von Helm-Charts und Operatoren vereinfacht.

Verwendung von New Relic mit OpenTelemetry

Es ist erwähnenswert, dass es möglich ist, New Relic mit OpenTelemetry zu verwenden.

Wie in der Dokumentation angegeben, gibt es erhebliche Überschneidungen zwischen New Relics eigener Instrumentierung und OpenTelemetry, aber “mit der New Relic-Instrumentierung gibt es inhärente Vorteile bei der Entwicklung von Instrumentierung und Plattformfunktionen, die zusammenarbeiten, und New Relic-Integrationen funktionieren in der Regel besser von Haus aus.”

Dennoch ist OpenTelemetry eine praktikable Option für New Relic-Nutzer, die einen herstellerneutraleren Ansatz suchen.

Flexibilität

Open-Source-Tools ermöglichen es Nutzern, einen auf die spezifischen Bedürfnisse ihrer Organisation zugeschnittenen Observability-Stack aufzubauen. Als Tool zur Datenvisualisierung kombiniert Grafana Daten aus verschiedenen Quellen - darunter Grafana Tempo für Traces, aber auch Loki für Logs, Prometheus für Metriken und viele mehr.

All-in-One-Dienste von Drittanbietern müssen hingegen für die Benutzerfreundlichkeit eine gewisse Flexibilität opfern. Selbst mit seinem umfangreichen Funktionsumfang erfüllt eine Plattform manchmal nicht alle Observability-Anforderungen eines bestimmten Projekts.

Datensicherheit

Beim Self-Hosting eines eigenen Observability-Stacks behält man die volle Kontrolle über Speicherung, Zugriff und sichere Aufbewahrung von Telemetriedaten - trägt aber auch die Verantwortung dafür.

Bei Lösungen von Drittanbietern wie New Relic verlässt man sich darauf, dass der Anbieter ein angemessenes Maß an Sicherheit bietet.

Beim Betrieb von Shopware sollte man bereits über die Prozesse und die Infrastruktur verfügen, um sensible Daten zu schützen. Schließlich sind sie erforderlich, um die Einhaltung von Datenschutzbestimmungen wie der DSGVO zu gewährleisten. Dadurch kann es potenziell einfacher sein, einen selbst gehosteten Observability-Stack in das eigene System zu integrieren, als die Compliance einer Integration von Drittanbietern sicherzustellen.

Kosten

New Relics kostenlose Stufe umfasst ein einziges vollwertiges Benutzerkonto und 100 GB Datenaufnahme. Das reicht in der Regel für einen kleinen eCommerce-Shop mit geringem Traffic aus. Alles darüber hinaus erfordert einen kostenpflichtigen Plan, dessen Preis sich nach Nutzerzahl und verarbeiteter Datenmenge richtet.

Nach der Ersteinrichtung beschränken sich die Kosten für das Self-Hosting eines eigenen Shopware-on-Kubernetes-Observability-Stacks auf die Infrastrukturkosten und die für die Wartung aufgewendete Zeit.

Unserer Erfahrung nach verbraucht der Observability-Stack nur einen Bruchteil der Rechenressourcen, die für den Betrieb von Shopware benötigt werden. Außerdem ist die Zeit für Konfigurationsanpassungen und gelegentliche Updates vergleichbar mit der Zeit für die Anpassung der Konfiguration von Diensten Dritter.

Alles in allem muss sich mit der Weiterentwicklung eines Projekts auch das unterstützende Tooling weiterentwickeln.

Wie entscheidet man sich?

Die wichtigsten Überlegungen bei der Wahl zwischen einer All-in-One-Observability-Plattform as a Service und einem selbst gehosteten Observability-Stack sind Flexibilität, Datensicherheit und Kosten.

Dienste wie New Relic sind von unschätzbarem Wert, um bestehenden Projekten schnell Telemetrie hinzuzufügen - insbesondere solchen, die auf Bare-Metal oder einem VPS laufen.

Andererseits ist Grafana die natürlichere Wahl für Cloud-native Anwendungen.

Shopware-on-Kubernetes-Observability in der Praxis - Visualisierung von Traces in Grafana

Der vollständige Observability-Stack verfügt über einige Komponenten zur Handhabung von Traces:

• Zunächst generiert der OTel-Exporter Traces und sendet sie an den OpenTelemetry Collector.

• Dann fügt der Collector einzelne Traces zu größeren Batches zusammen und sendet sie an Grafana Tempo.

• Schließlich fragt Grafana Tempo nach Traces und visualisiert sie in einer für den Menschen lesbaren Form.

Lassen Sie uns Schritt für Schritt durch das komplette Setup gehen, beginnend mit dem Export von Traces aus dem Shopware-Container. Nacheinander senden wir die Traces zum OpenTelemetry Collector, leiten sie an Tempo weiter und visualisieren sie schließlich in Grafana.

Voraussetzungen

Ein Kubernetes-Cluster mit bereitgestelltem Shopware

Für diesen Artikel habe ich unser Shopware on Kubernetes-Setup verwendet, das alles Nötige für die Bereitstellung von Shopware auf Kubernetes bietet. Außerdem kamen Skaffold und Kind zum Einsatz, um das lokale Cluster-Setup zu erleichtern.

Konfigurieren des Shopware-Containers zur Erzeugung von Traces

Wenn alles gut geht, sollten am Ende dieses Schritts Meldungen ähnlich der folgenden in den Shopware-Container-Logs erscheinen:

10.244.0.1 - - [19/Dec/2024:17:25:33 +0000] "GET /api/_info/health-check HTTP/1.1" 200 5 "-" "kube-probe/1.27" "-"
127.0.0.1 -  19/Dec/2024:17:25:33 +0000 "GET /index.php" 200
{
    "resource": {
        "attributes": {
            "host.name": "shopware-web-57fc87c8d9-n8w8r",
            "host.arch": "x86_64",
            "os.type": "linux",
            "os.description": "6.8.0-49-generic",
            "os.name": "Linux",
            "os.version": "#49-Ubuntu SMP PREEMPT_DYNAMIC Mon Nov  4 02:06:24 UTC 2024",
            "process.pid": 94,
            "process.executable.path": "\/usr\/local\/sbin\/php-fpm",
            "process.owner": "application",
            "process.runtime.name": "fpm-fcgi",
            "process.runtime.version": "8.3.14",
            "telemetry.sdk.name": "opentelemetry",
            "telemetry.sdk.language": "php",
            "telemetry.sdk.version": "1.1.2",
            "telemetry.distro.name": "opentelemetry-php-instrumentation",
            "telemetry.distro.version": "1.1.0",
            "service.name": "shopware",
            "service.version": "1.0.0+no-version-set"
        },
        "dropped_attributes_count": 0
    },
    "scopes": [

Erforderliche PHP OpenTelemetry-Erweiterung installieren und aktivieren

Zuerst wird die opentelemetry Auto-Instrumentierungs-PHP-Erweiterung in das Shopware-Container-Image installiert:

# Dockerfile

RUN MAKEFLAGS="-j $(nproc)" pecl install \
    opentelemetry-1.1.0 \
    ;

RUN docker-php-ext-enable \
    opentelemetry \
    ;

OpenTelemetry Composer-Pakete installieren

Als Nächstes wird eine Reihe von Composer-Paketen installiert, um die Generierung von Anwendungs-Traces in Shopware zu ermöglichen:

composer require \
    shopware/opentelemetry \
    open-telemetry/exporter-otlp \
    open-telemetry/opentelemetry-logger-monolog \
    ;

OpenTelemetry-Exporter konfigurieren

Schließlich wird der OTel-Exporter so konfiguriert, dass er Traces in die Container-Logs ausgibt. Dies erleichtert die Bestätigung, dass dieser Teil des Setups korrekt konfiguriert wurde:

# deploy/bases/app/config/otel.env

OTEL_PHP_AUTOLOAD_ENABLED=true
OTEL_PHP_LOG_DESTINATION=stderr
OTEL_PHP_INTERNAL_METRICS_ENABLED=true
OTEL_SERVICE_NAME=shopware
OTEL_LOGS_EXPORTER=console
OTEL_METRICS_EXPORTER=console
OTEL_TRACES_EXPORTER=console

Traces für die Weiterverarbeitung sammeln

Jetzt brauchen wir eine Möglichkeit, Traces von Shopware zu sammeln und zur Weiterverarbeitung weiterzuleiten. Dafür verwenden wir den OpenTelemetry Collector, den wir mithilfe eines Operators und einer Custom Resource bereitstellen.

Nach Abschluss dieses Teils sollten Sie ein StatefulSet namens shopware-collector im Cluster laufen haben. In seinen Container-Logs sollten Einträge ähnlich dem folgenden Beispiel zu sehen sein:

ResourceSpans #0
Resource SchemaURL: https://opentelemetry.io/schemas/1.30.0
Resource attributes:
    -> host.name: Str(shopware-web-855d46dd5d-cbzsv)
    -> host.arch: Str(x86_64)
    -> os.type: Str(linux)
    -> os.description: Str(6.8.0-52-generic)
    -> os.name: Str(Linux)
    -> os.version: Str(#53-Ubuntu SMP PREEMPT_DYNAMIC Sat Jan 11 00:06:25 UTC 2025)
    -> process.pid: Int(114)
    -> process.executable.path: Str(/usr/local/sbin/php-fpm)
    -> process.owner: Str(application)
    -> process.runtime.name: Str(fpm-fcgi)
    -> process.runtime.version: Str(8.3.14)
    -> telemetry.sdk.name: Str(opentelemetry)
    -> telemetry.sdk.language: Str(php)
    -> telemetry.sdk.version: Str(1.2.2)
    -> telemetry.distro.name: Str(opentelemetry-php-instrumentation)
    -> telemetry.distro.version: Str(1.1.0)
    -> service.name: Str(shopware)
    -> service.version: Str(1.0.0+no-version-set)

OpenTelemetry Kube Stack bereitstellen

Zuerst installieren wir den OpenTelemetry Kube Stack. Er enthält den OpenTelemetry Operator und ein paar integrierte Collectors zum Sammeln von Daten aus Kubernetes.

Der Einfachheit halber deaktivieren wir vorübergehend die integrierten Collectors. Sie können später für ein umfassenderes OpenTelemetry-Setup aktiviert werden.

OpenTelemetry Kube Stack wird als Helm-Chart verteilt, was die Installation mit Skaffold bequem macht:

# skaffold.yaml

deploy:
  statusCheck: true
  kubectl: {}
  helm:
    releases:
    - name: opentelemetry-kube-stack
      remoteChart: opentelemetry-kube-stack
      repo: https://open-telemetry.github.io/opentelemetry-helm-charts
      wait: true
      setValues:
        collectors:
          cluster:
            enabled: false
          daemon:
            enabled: false

Eine Instanz des OpenTelemetry Collectors bereitstellen

Nachdem der Operator läuft, erstellen wir eine OpenTelemetryCollector Custom Resource. Damit erstellt der Operator eine neue Instanz des OpenTelemetry Collectors. Es wird ein StatefulSet namens shopware-collector sein.

Vorerst wird der Collector alle eingehenden Daten in seine Logs ausgeben, um die Bestätigung zu erleichtern, dass er Traces von Shopware empfängt:

# deploy/overlays/local/opentelemetry-collector.yaml

apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: shopware
spec:
  mode: statefulset
  replicas: 1
  managementState: managed
  config:
    receivers:
      otlp:
        protocols:
          http:
            endpoint: 0.0.0.0:4318
    processors:
      batch:
      memory_limiter:
        # 80% of maximum memory up to 2G
        limit_mib: 400
        # 25% of limit up to 2G
        spike_limit_mib: 100
        check_interval: 5s

    exporters:
      nop: {}
      debug:
        verbosity: detailed
        sampling_initial: 5
        sampling_thereafter: 200
        use_internal_logger: false
      otlp:
        endpoint: tempo.default.svc.cluster.local:4317
        tls:
          insecure: true

    logging:
      loglevel: debug

    service:
      telemetry:
        logs:
          level: debug
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [debug]
        metrics:
          receivers: [otlp]
          processors: []
          exporters: [debug]
        logs:
          receivers: [otlp]
          processors: []
          exporters: [debug]

OpenTelemetryCollector Custom Resource-Manifest

OpenTelemetry-Konfiguration im Shopware-Container aktualisieren, um Daten an den OpenTelemetry Collector zu senden

Schließlich aktualisieren wir die Konfiguration des OTel-Exporters, um alle Daten an den OpenTelemetry Collector weiterzuleiten, anstatt sie wie zuvor in die Shopware-Container-Logs auszugeben. Dies geschieht durch Aktualisierung der Umgebungsvariablen, die die Konfiguration des OTel-Exporters im Shopware-Container steuern:

# deploy/bases/app/config/otel.env

OTEL_PHP_AUTOLOAD_ENABLED=true
OTEL_PHP_LOG_DESTINATION=stderr
OTEL_PHP_INTERNAL_METRICS_ENABLED=true
OTEL_SERVICE_NAME=shopware
OTEL_LOGS_EXPORTER=otlp
OTEL_METRICS_EXPORTER=otlp
OTEL_TRACES_EXPORTER=otlp
OTEL_EXPORTER_OTLP_PROTOCOL=http/json
OTEL_EXPORTER_OTLP_ENDPOINT=http://shopware-collector:4318

Traces in Grafana visualisieren

Sobald der OpenTelemetry Collector beginnt, Traces von Shopware zu empfangen, bleibt nur noch übrig, Grafana und Grafana Tempo bereitzustellen, um die Daten zu verarbeiten und zu visualisieren.

Grafana Operator und Tempo bereitstellen

Im letzten Schritt müssen wir alle Daten vom OTel-Exporter an den OpenTelemetry Collector senden, anstatt die Traces nur in die Shopware-Container-Logs auszugeben. Dazu müssen wir die Umgebungsvariablen aktualisieren, die die Konfiguration des OTel-Exporters steuern:

# skaffold.yaml

deploy:
  statusCheck: true
  kubectl: {}
  helm:
    releases:
      - name: tempo
        remoteChart: tempo
        repo: https://grafana.github.io/helm-charts
        wait: true
        version: 1.12.0
        setValues:
          tempoQuery:
            enabled: true
      - name: grafana-operator
        remoteChart: oci://ghcr.io/grafana/helm-charts/grafana-operator
        version: v5.15.1
        wait: true
        setValues:
          installCRDs: true

Traces vom OpenTelemetry Collector an Grafana Tempo senden

Wenn Grafana Tempo läuft, besteht der letzte Schritt darin, alle Daten vom OpenTelemetry Collector an Grafana Tempo weiterzuleiten:

# deploy/overlays/local/otel-collector.yaml

apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: shopware
spec:
  mode: statefulset
  replicas: 1
  managementState: managed
  config:
    receivers:
      otlp:
        protocols:
          http:
            endpoint: 0.0.0.0:4318
    processors:
      batch:
      memory_limiter:
        # 80% of maximum memory up to 2G
        limit_mib: 400
        # 25% of limit up to 2G
        spike_limit_mib: 100
        check_interval: 5s

    exporters:
      nop: {}
      debug:
        verbosity: detailed
        sampling_initial: 5
        sampling_thereafter: 200
        use_internal_logger: false
      otlp:
        endpoint: tempo.default.svc.cluster.local:4317
        tls:
          insecure: true

    logging:
      loglevel: debug

    service:
      telemetry:
        logs:
          level: debug
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [otlp]
        metrics:
          receivers: [otlp]
          processors: []
          exporters: [otlp]
        logs:
          receivers: [otlp]
          processors: []
          exporters: [otlp]

Sobald diese letzte Änderung übernommen wurde, öffnen Sie Grafana in Ihrem Browser und wählen Sie Explore im Hauptmenü. In der Suche nutzen Sie Shopware für den Dienste-Filter.

Dann sehen Sie Shopware-App-Traces hier:

Wie geht es weiter?

Die Verfügbarkeit von Shopware-Traces in Grafana eröffnet wertvolle Einblicke in die inneren Abläufe von Shopware. Dies allein wird Ihnen helfen, Leistungsengpässe zu identifizieren und besser zu verstehen, wie sich Ihr Online-Shop in der Praxis verhält.

Wenn Sie Kubernetes einsetzen, nutzen Sie wahrscheinlich bereits Tools wie Fluentd oder Loki und Prometheus für die Handhabung von Logs und Metriken. Jetzt ist der Zeitpunkt gekommen, diesen Observability-Stack zu Ihrem eigenen zu machen. Mit diesen Werkzeugen können Sie Logs, Metriken und Traces verschiedener Dienste korrelieren und analysieren. Visualisieren Sie all diese Informationen auf maßgeschneiderten Dashboards und richten Sie Warnmeldungen ein, falls etwas aus dem Ruder läuft.

Fazit

Observability ist von entscheidender Bedeutung für eine stabile Bereitstellung von Shopware auf Kubernetes. Ohne geeignete Werkzeuge zur Untersuchung des inneren Zustands ist es nahezu unmöglich, einen stabilen, leistungsfähigen Online-Shop in der Cloud zu betreiben.

Kommerzielle Observability-Plattformen bieten zwar einen schnellen Weg zu Einblicken in Produktionssysteme, unterliegen jedoch inhärenten Einschränkungen. Benutzerfreundlichkeit geht zu Lasten von Flexibilität und Anpassungsfähigkeit. Zudem kann ihre Nutzung, selbst in kleinen Projekten, recht kostspielig werden, um die erforderlichen Erkenntnisse zu gewinnen.

Wie hier gezeigt, erfordert die Integration von Tracing in die Standard-Kubernetes-Überwachungstools nicht allzu viel Aufwand - oft vergleichbar mit dem für die Einbindung eines externen Dienstes. Damit wurde es möglich, OpenTelemetry als Teil des Shopware-on-Kubernetes-Observability-Toolkits einzusetzen.

Möchten Sie die Stabilität und Leistung Ihres Online-Shops verbessern? Kontaktieren Sie uns! Wir unterstützen Sie gerne bei der Auswahl der optimalen Lösungen für Ihr Unternehmen.

• DevOps
• Kubernetes
• Observability
• Shopware