So behalten Sie Ihre CI/CD-Pipelines mit OpenTelemetry im Blick

Software ist heute um Größenordnungen komplexer als vor 20 Jahren, was neue Herausforderungen für das Troubleshooting mit sich bringt. Glücklicherweise sind wir durch die Implementierung von Observability in unseren Systemen ziemlich weit gekommen, um zu verstehen, wie unsere Anwendungen funktionieren und wo Probleme auftreten.

Doch nicht nur die Software hat sich weiterentwickelt, sondern auch der Prozess ihrer Erstellung und Entwicklung. DevOps führte das Konzept von CI/CD ein. Da sich damit die Lieferzyklen von monatlich oder vierteljährlich auf wöchentlich oder sogar mehrmals täglich verkürzen, setzen wir in der gesamten Software-Lieferkette auf Automatisierung. 

Leider ist Observability für CI/CD-Pipelines im Vergleich zu Anwendungssoftware nicht sehr weit fortgeschritten. Wenn man bedenkt, dass diese Pipelines das Rückgrat der Softwarebereitstellung sind, ist das überraschend: Wenn Sie keinen Einblick haben, wie können Sie dann Probleme beheben, wenn etwas schiefgeht und Sie die Software nicht in die Produktion bringen können? 

Darauf werden wir uns in diesem Blog konzentrieren: Die Observability von CI/CD-Pipelines. Zunächst werden wir einige Dinge definieren; dann gehen wir darauf ein, warum Observability für Pipelines wichtig ist und wie man Pipelines beobachtbar machen kann; zum Schluss werden wir über einige der verbleibenden Herausforderungen sprechen. 

Wichtige Konzepte

Hier sind einige Definitionen, die Sie kennen sollten:

Observability

Es gibt mehrere Definitionen von Observability, also beschränken wir uns auf unseren Favoriten: 

Observability oder o11y (ausgesprochen „Ollie“) ermöglicht es Ihnen, ein System von außen zu verstehen, da Sie Fragen stellen können, ohne die innere Funktionsweise des Systems zu kennen.

Das bedeutet, dass – auch wenn Sie nicht alle Feinheiten der zugrunde liegenden Geschäftslogik eines Systems verstehen – dieses System genügend Informationen ausgibt, damit Sie die Frage beantworten können: „Warum passiert das?“ Sie können jedoch keine Observability haben, wenn Ihr System keine Informationen aussendet. Wie kommen Sie also an diese Informationen? Eine Möglichkeit ist OpenTelemetry.

Fun Fact: Die 11 in „o11y“ steht für die Anzahl der Zeichen zwischen dem „O“ und dem „y“ in dem Wort „Observability“.

OpenTelemetry

OpenTelemetry (OTel) ist ein Open-Source-Observability-Framework zur Erzeugung, Sammlung, Umwandlung und zum Export von Telemetriedaten. Es bietet eine Reihe von APIs, Software Development Kits (SDKs), Instrumentierungsbibliotheken und Tools, die Sie dabei unterstützen. Seit seiner offiziellen Einführung im Jahr 2019 hat es sich zum De-facto-Standard für die Anwendungsinstrumentierung und Telemetrieerzeugung sowie -erfassung entwickelt und wird von Unternehmen wie eBay und Skyscanner verwendet. 

Einer seiner größten Vorteile ist die Anbieterunabhängigkeit. Sie können Ihre Anwendung einmalig instrumentieren und Ihre Telemetrie an das für Sie am besten geeignete Backend senden. Es bietet auch einige ziemlich coole Tools, wie zum Beispiel den Collector.

Der Collector ist ein anbieteragnostischer Dienst, der für die Erfassung, Umwandlung und den Export von Daten in ein oder mehrere Observability-Backends verwendet wird. Der Collector besteht aus vier Hauptkomponenten, die auf die Telemetrie zugreifen:

• Empfänger erfassen Daten, sei es aus Ihrem Anwendungscode oder Ihrer Infrastruktur.
• Prozessoren verarbeiten Ihre Daten. Ein Prozessor kann z. B. die Daten verschleiern, filtern, Attribute hinzufügen oder entfernen.
• Exporter konvertieren Ihre Daten in ein Format, das mit dem von Ihnen gewählten Observability-Backend kompatibel ist.
• Mit Konnektoren können Sie zwei Pipelines miteinander verbinden.

Sie können sich den OTel Collector wie eine Datenpipeline vorstellen.

CI/CD-Pipelines

CI/CD ist ein automatisierter Ansatz für die Softwarebereitstellung, der sich auf zwei wichtige Praktiken stützt: 

• Continuous Integration (CI; kontinuierliche Integration): Dabei wird Ihre Software bei jeder Codeänderung neu kompiliert, paketiert und getestet.
• Continuous Delivery (CD; kontinuierliche Lieferung): Dabei wird das Softwarepaket sofort zur Produktion bereitgestellt.

Automatisierte Pipelines ermöglichen schnelle Produktiterationen, indem Sie neue Features, Bugfixes und allgemeine Updates schneller an Ihre Kund:innen weitergeben können. Es beseitigt das Risiko manueller Fehler und standardisiert die Feedbackschleife zu Ihren Entwickler:innen. 

Warum CI/CD-Pipeline-Observability wichtig ist

Wenn Ihre Pipeline in Ordnung ist, kann Ihr Team kontinuierlich Code- und Konfigurationsänderungen schreiben, kompilieren, testen und bereitstellen. Sie können auch die Entwicklungsagilität verbessern (oder erreichen), sodass Sie nach Ops-Änderungen schneller herausfinden, ob diese sich positiv oder negativ auf die Anwendungs-Health auswirken. 

Umgekehrt kann es zu einem oder mehreren der folgenden Probleme kommen, wenn Ihre Pipeline nicht in Ordnung ist:

• Langsame Deployments: Bugfixes werden möglicherweise nicht schnell genug veröffentlicht, um die Unzufriedenheit der Benutzer:innen einzudämmen, und die Probleme können kritisch werden. 
• Probleme beim Testen: Wenn Sie auf den Abschluss von Tests warten müssen oder nicht genug Zeit haben, um mit verschiedenen Konfigurationen zu testen, kann dies zu Verzögerungen bei Deployments führen und das Erreichen einer akzeptablen App-Performance für Ihre User Base erschweren.
• Technische Schulden: Schwierigkeiten bei der Ermittlung zugrunde liegender Probleme können zu technischen Schulden führen.

Pipelines sind die Produktionssysteme von DevOps-Engineers

Pipelines sind zwar keine Produktionsumgebung, mit der externe Benutzer:innen interagieren, aber als interne Produktionsumgebung werden sie auf jeden Fall von unternehmensinternen Benutzer:innen wie Software-Entwickler:innen und Site Reliability Engineers (SREs) verwendet. Observability für Ihre Produktionsumgebung hat mehrere Vorteile:

• Vermeidung unnötig langer Zykluszeiten oder Vorlaufzeiten für Änderungen, die sich auf die Zeit auswirken, die ein Commit braucht, um in Produktion zu gehen.
• Weniger Verzögerungen bei der Veröffentlichung neuer Features und Bugfixes.
• Verkürzung der Wartezeit für Benutzer:innen.

Code kann fehlschlagen 

CI/CD-Pipelines werden durch Code ausgeführt, der definiert, wie sie funktionieren, und trotz aller Bemühungen kann der Code ab und zu versagen. Ist der Code der Anwendung beobachtbar, wissen Sie bei Produktionsproblemen eher, was los ist. Ebenso können Sie durch Einblick in Ihre Pipelines besser verstehen, was passiert, wenn sie nicht funktionieren.

Troubleshooting ist einfacher

Beobachtbare Pipelines helfen, Fragen wie diese zu beantworten:

• Was ist fehlgeschlagen?
• Warum ist es fehlgeschlagen?
• Ist es schon einmal fehlgeschlagen?
• Was ist am häufigsten fehlgeschlagen?
• Was ist die normale Laufzeit der Pipeline?
• Gibt es Bottlenecks? Wenn ja, welche?
• Können Sie die Vorlaufzeit für die Behebung von Pipeline-Problemen verkürzen?

Welche Art von Daten wollen Sie sammeln? 

Um die obigen Fragen zu beantworten, müssen Sie Informationen über Ihre Pipelines sammeln. Aber wie sollten diese Informationen aussehen? Erfassen Sie Dinge wie:

• Branch-Name
• Commit des sicheren Hash-Algorithmus (SHA)
• Rechner-IP
• Lauftyp (geplant, ausgelöst durch Merge/Push)
• Fehlgeschlagener Schritt
• Schrittdauer
• Build-Nummer

Observability für Pipelines

Sie erinnern sich sicher, dass ein System beobachtbar ist, wenn es genügend Informationen aussendet, um die Frage „Warum passiert das?“ zu beantworten. Zunächst braucht man eine Methode zur Ausgabe dieser Informationen, dann einen Ort, an den sie gesendet werden können, und schließlich muss man sie analysieren und herausfinden, was behoben werden muss. 

An dieser Stelle kommt OpenTelemetry ins Spiel. Sie können OpenTelemetry in Ihren Systemen implementieren, um die für die Observability Ihrer Systeme notwendigen Informationen auszugeben. Und so wie Sie Observability für Anwendungen nutzen, können Sie sie auch für CI/CD-Pipelines verwenden. Sie müssen die generierte Telemetrie zur Analyse an ein Backend wie New Relic senden. 

OpenTelemetry verwenden

OpenTelemetry eignet sich besonders für die Instrumentierung von CI/CD-Pipelines, da zahlreiche Anwendungen bereits damit instrumentiert sind. Akzeptanz und Implementierung haben in den letzten Jahren stetig zugenommen. 

New Relic verwenden

Sie haben folgende Möglichkeiten, wenn es um das Monitoring von CI/CD-Pipelines mit New Relic geht:

Weiterleitung von CircleCI Logs an New Relic

Sie können den CircleCI-Webhook-Service konfigurieren, um CI/CD-Logs an New Relic zu senden. 

GitHub Actions Exporter

Sie können diesen Exporter zum Monitoring Ihrer GitHub Actions verwenden. So ist es einfacher, einen Einblick in die Health und Performance Ihrer CI/CD-Workflows zu erhalten. Er erfasst die Logs aus Ihren GitHub-Actions-Schritten und fügt dann Trace- und Span-IDs hinzu, um sie mit Traces zu korrelieren.

Das können Sie mit dem Exporter tun:

• Visualisierung der wichtigsten Metriken zu Ihren GitHub Actions, z. B. wie lange Ihre Workflows/Jobs/Schritte dauern und wie oft sie fehlschlagen.
• Visualisierung von Workflows/Jobs und Schritten als Distributed Traces mit Logs in Context, mit New Relic an eine OpenTelemetry-Service-Entity gemeldet.
• Ermitteln des genauen Ursprungs von Problemen in Ihren Workflows.
• Erstellen von Alerts zu Ihren Workflows.

Bitte beachten Sie, dass dieses Tool von unserem Außendienstteam entwickelt wurde und in unserem Experimental Repository zu finden ist. Das bedeutet, dass der Code nicht notwendigerweise in der Produktion verwendet wird, sondern offen entwickelt wird – was aber auch bedeutet, dass Ihre Beiträge stets willkommen sind.

Change Tracking mit New Relic

New Relic bietet auch ein Change-Tracking-Feature, mit dem Sie die Auswirkungen von Änderungen auf Ihre Kund:innen und Systeme verfolgen können. Dabei bestimmen Sie, welche Änderungen überwacht werden sollen, und überprüfen dann die Ergebnisse in Ihrem New Relic Konto. Auf diese Weise können Sie alle Änderungen nachverfolgen, die Sie in Ihrer Umgebung während der Release-Pipeline vornehmen. 

Sie können dieses Feature mit GitHub Actions (Beispiel hier) und auch mit Jenkins (Tutorial hier) verwenden und dann lernen, wie Sie Ihre Änderungen in der UI aufrufen und analysieren. 

Welche anderen Möglichkeiten gibt es?

Gegenwärtig bietet sich ein uneinheitliches Bild:

• Kommerzielle SaaS-Monitoring-Lösungen.
• Drittanbietertools, die Sie in bestehende CI/CD-Tools integrieren können, um CI/CD-Observability zu erreichen (z. B. Honeycomb buildevents). 
• Eigene GitHub-Aktionen (siehe Beispiele hier, hier und hier), um Observability in der CI/CD-Pipeline zu ermöglichen.
• Eigener CircleCI-Webhook für OTel.
• Eigener Drone-CI-Webhook für OTel.
• Native OpenTelemetry-Integration für Jenkins und Tekton. 

Sie können diese Tools auch in Ihre CI/CD-Pipeline integrieren; sie geben OpenTelemetry-Signale aus und helfen so, Ihre Pipelines beobachtbar zu machen:

• Die OTel-Erweiterung für Maven-Builds gibt Distributed Traces von Java-Builds aus.
• Ansible-OpenTelemetry-Callback sorgt für das Tracing von Ansible-Playbooks.
• Die OpenTelemetry-Erweiterung für JUnit Jupiter von Dynatrace ist ein Gradle-Plugin zum Sammeln von Daten von JUnit-Testausführungen über OpenTelemetry. Es gibt auch eine Maven-Version.
• pytest-otel zeichnet Distributed Traces ausgeführter Python-Tests auf.
• otel-cli ist eine in Go geschriebene Befehlszeilenschnittstelle (CLI), die Shell-Skripts die Ausgabe von Traces ermöglicht.
• Der Filelog-Empfänger (OTel Collector) liest und parst Logs aus Dateien.
• Der Git-Provider-Empfänger (OTel Collector) liest Daten von Git-Anbietern aus.

Beispiel für eine beobachtbare Pipeline

Dieses Diagramm zeigt, wie man mit einigen der oben genannten Tools Pipeline-Observability erreichen kann. Angenommen, Sie kompilieren eine Java-Anwendung und stellen sie bereit. Sie verwenden Jenkins zur Orchestrierung von Build und Deployment:

1. Die Jenkins-CI/CD-Pipeline kann über das Jenkins-OTel-Plugin Telemetriesignale ausgeben.
2. In der Kompilierungsphase:
   1. Sie können die Maven-OTel-Erweiterung verwenden, um Distributed Traces von Java-Builds auszugeben.
   2. Wenn Ihr Build Shell-Skripts enthält, können Sie das Tool otel-cli verwenden, damit Ihre Shell-Skripts Traces ausgeben können.
3. In der Testphase ermöglicht das JUnit-Jupiter-Plug-in für Maven das Sammeln von Daten der JUnit-Testausführungen über OpenTelemetry.
4. Wenn Sie zur Paketierung Ihrer Anwendung Artifactory verwenden, können Sie in der Paketierungsphase die dazugehörigen Logs über den Filelog-Empfänger, der Logs aus den Dateien ausliest und parst, an den OTel Collector senden.
5. In der Deployment-Phase (bei Verwendung von Ansible zur Orchestrierung Ihrer Deployments) fügt der Ansible-OpenTelemetry-Callback Traces zu Ihren Ansible-Playbooks hinzu. Wenn Ihr Ansible-Playbook auch Shell-Skripts verwendet, kann es die Vorteile des otel-cli-Tools nutzen, damit Ihre Shell-Skripts zusätzliche Trace-Daten ausgeben können.
6. Die von den verschiedenen Plug-ins ausgegebenen Signale werden von einem OTel Collector erfasst. Die Datenerfassung kann mit dem Standard-OTLP-Empfänger zur Erfassung von Telemetriedaten, dem Git-Provider-Empfänger und dem Filelog-Empfänger erfolgen. Die Telemetriesignale werden dann vom Collector an ein Observability-Backend gesendet.
7. Sobald Ihre Daten in Ihrem Observability-Backend angekommen sind, können Sie Ihre Daten einsehen und abfragen, Alerts einrichten und mehr. 

Herausforderungen hinsichtlich beobachtbarer Pipelines

Obwohl es sinnvoll ist, OpenTelemetry zu verwenden, um die CI/CD-Pipeline-Observability zu ermöglichen, mangelt es an Standardisierung, und die Tooling-Landschaft ist unübersichtlich.

OpenTelemetry ist in die meisten CI/CD-Tools nicht integriert. Es besteht zwar der Wunsch, CI/CD-Tools wie GitLab und GitHub Actions um Observability-Funktionen zu erweitern, aber diese Initiativen kommen nur langsam voran. So wurde beispielsweise zwar an der GitLab-Anfrage für die Pipeline-Observability mit OTel gearbeitet, aber dieser Punkt ist seit zwei Jahren offen. Der OTel-Vorschlag für Observability von CI/CD-Pipelines wurde im Januar 2023 vorgestellt, aber (Stand November 2023) seit Juli 2023 ist nichts mehr passiert.

Daher ist man auf Gedeih und Verderb Einzelpersonen und Unternehmen ausgeliefert, die ihr eigenes Ding machen, wenn man deren Tools nutzen will. Was passiert aber, wenn sie beschließen, diese Tools nicht mehr zu pflegen?

Mehr erfahren

Wenn Sie Ihre CI/CD-Pipelines beobachtbar machen, können Sie Fehler effektiver beheben, Entwicklungsagilität erreichen und Einblicke in die inneren Abläufe gewinnen. Damit können Sie sie optimieren, damit sie effizienter laufen.

Eine gesunde Pipeline bedeutet, dass Sie kontinuierlich neuen Code schreiben, kompilieren, testen und bereitstellen können. Umgekehrt kann eine ungesunde Pipeline zu Deployment-Verzögerungen, Problemen beim Testen und technischen Schulden führen. 

Sie können OpenTelemetry verwenden, um Observability für Ihre Pipeline herzustellen. Obwohl die Möglichkeiten derzeit begrenzt sind, bewegen sich die Dinge in die richtige Richtung, und wir sind gespannt, was die Zukunft von CI/CD bringt.

Lesen Sie weiter:

• Nutzung von OpenTelemetry zur Verbesserung von Ansible mit Jaeger-Tracing
• Besuchen Sie den Channel cicd-o11y auf CNCF Slack

Sehen Sie sich auch Folgendes an:

• New Relic CircleCI-Quickstart
• Weiterleitung Ihrer CircleCI-Logs an New Relic

Eine Version dieses Blogbeitrags wurde ursprünglich auf The New Stack veröffentlicht.