Wenn wir unseren Observability-Fokus nach links verlagern, können wir Probleme in CI/CD lösen, bevor sie eskalieren, wie zwei Grafana-Ingenieure feststellten.
Übersetzt aus CI/CD Observability: A Rich New Opportunity for OpenTelemetry , Autor Giordano Ricci;
Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) sind das Rückgrat der modernen Softwarebereitstellung, die Transparenz ihrer Prozesse bleibt jedoch begrenzt. Hier erfahren Sie, wie OpenTelemetry (OTel) dies ändert und warum diese Änderungen so aufregend sind.
CI/CD hat unterschiedliche Definitionen, je nachdem, wen Sie fragen, aber das Gleiche ist, dass es kontinuierlich ist – eine nie endende Feedbackschleife, bei der es darum geht, manuelle Prozesse zu reduzieren, einsetzbare Software zu erstellen und Software bereitzustellen, wenn Probleme auftreten. Beseitigen Sie sie vor der Produktionsumgebung.
Diese Praxis ist notwendig geworden, um manuelle Prozesse zu reduzieren, einsetzbare Software zu erstellen und das Vertrauen in den Softwarebereitstellungsprozess zu erhöhen, aber uns fehlen die Werkzeuge, um zu verhindern, dass er instabil wird.
Die Beobachtbarkeit von CI-Systemen steckt noch in den Kinderschuhen – und jetzt ist diese Chance dank einer Kombination von Faktoren möglich. Werfen wir einen genaueren Blick auf die historisch nicht beobachtbaren Aspekte von CI/CD-Pipelines, darauf, wie OpenTelemetry und verwandte Arbeiten die Beobachtbarkeit von CI ermöglichen, und auf die hohe Obergrenze für zukünftige Verbesserungen der Entwicklerproduktivität.
Es gibt noch viel Spielraum nach links
CI und Alarmierung werden traditionell als Lösungen mit einem gemeinsamen Ziel eingesetzt. Sie arbeiten eng zusammen und bilden wesentliche Komponenten für eine kontinuierliche automatisierte Überwachung. Die kontinuierliche Integration schützt in den frühen Phasen: Sie erkennt Änderungen, erhält den Build-Zustand aufrecht und überwacht kontinuierlich Systemsignale. Warnungen werden häufig in späteren Phasen verwendet. Es identifiziert Probleme, die CI übersehen hat. Somit legt CI den Grundstein, während Warnungen auf Bedrohungen reagieren – kontinuierliche Zusammenarbeit zur Lösung desselben Problems.
Doch in der Vergangenheit lag der Schwerpunkt der Beobachtbarkeit auf dem „laufenden“ Teil der Dinge und ignorierte wertvolle Erkenntnisse aus frühen Phasen wie Build, Test und Bereitstellung sowie anderen wichtigen Bereichen mit Chancen in den frühen Phasen einer CI-Pipeline.
Wir setzen Dinge ein, wir sehen, wie Dinge Feuer fangen, und dann versuchen wir, das Feuer zu löschen.
Aber wenn wir nur die letzten Phasen des Entwicklungs- und Bereitstellungszyklus betrachten, wird es zu spät sein. Wir wissen nicht, was während der Build- oder Testphase passiert ist, oder wir haben Schwierigkeiten mit der Ursachenanalyse oder einer längeren durchschnittlichen Wiederherstellungszeit, und wir verpassen Optimierungsmöglichkeiten. Wir wussten, dass die Ausführung unserer CI-Pipelines lange dauerte, aber wenn wir wollten, dass sie schneller laufen, wussten wir nicht, was wir verbessern sollten.
Wenn wir unseren Observability-Fokus nach links verlagern, können wir Probleme lösen, bevor sie eskalieren, die Effizienz steigern, indem wir Probleme im Prozess reduzieren, die Robustheit und Vollständigkeit unserer Tests erhöhen und die Kosten und Ausgaben nach der Bereitstellung und im Zusammenhang mit Ausfällen minimieren.
Es gibt einen Grund, warum OpenTelemetry eines der aktivsten Projekte der Cloud Native Computing Foundation (CNCF) ist (technisch gesehen das „zweitschnellste Projekt“). Es ist ein hervorragendes Protokoll zur Definition semantischer Konventionen und zur Vereinheitlichung von Signaltypen für Protokolle, Metriken und Traces (die „drei Säulen“ der Beobachtbarkeit) sowie für Analysen und andere neue Signaltypen.
Wir haben gesehen, wie OTel im letzten Jahr für Aufsehen gesorgt hat, nachdem es breite Unterstützung für offene Standards und Gemeinsamkeiten in einem ehemaligen Black-Box-Bereich geschaffen hat. Einst stark proprietäre Observability-Bereiche wie Datenbanken, Cloud-Anbieter, Abfragesprachen und Protokolldateiformate wurden mit einem klar definierten Protokoll geknackt, das funktioniert und nahezu alles unterstützt, was in unserer modernen mehrsprachigen Programmiersprache beliebt ist.
Die Welt der CI/CD-Anbietertools hat ihre eigene Blackbox. Jedes Entwicklungsteam verwendet ein CI-System und die meisten Teams verwenden mehrere CI-Systeme. Das Konzept, „eigene CI-Daten zu besitzen“, gewinnt heute immer mehr an Bedeutung, da immer mehr Benutzer keine Lust mehr auf komplexe Problemumgehungen haben, um diese Daten in ihre eigene, gut verstandene Backend-Architektur zu übertragen, aber Probleme mit dem Kontextwechsel und dedizierten Backends haben.
Aus diesem Grund herrschte große Aufregung, als die CI/CD-Arbeitsgruppe von OTel erstmals die Einführung neuer semantischer Konventionen für die CI/CD-Beobachtbarkeit vorschlug und anschließend eine neue Special Interest Group (SIG) speziell für die CI/CD-Beobachtbarkeit vorschlug.
Wie die Zukunft der Observability-Daten aussehen wird
Wenn Sie über Ihre eigenen Daten verfügen, entscheiden Sie selbst, wohin diese gehen und wie sie gespeichert werden. Durch die Ausführung von OpenTelemetry zwischen unserem CI-System und dem Ziel unserer Wahl kümmert sich OpenTelemetry um die Umwandlung in die von uns gewünschte Datenbank und das gewünschte Schema. Das bedeutet, dass viele Innovationen, die auf zuvor isolierten CI-Daten basieren, jetzt das Observability-Tool-Feld einführen.
Beispielsweise haben wir eine OpenTelemetry Collector-Distribution erstellt – eine Binärdatei, deren Empfänger, Prozessoren und Exporteure CI-Daten aus Drone extrahieren, sie in das von Ihnen benötigte Format konvertieren und diese Daten dann an die Datenbank senden. Jenkins verfügt über ein Plugin zum Exportieren von Daten über das OpenTelemetry Protocol (OTLP).
Dies ist eine sehr aufregende Zeit für die Observability-Community. Indem wir die Daten aus unserem CI übernehmen und sie in das Observability-System integrieren, können wir einen Drilldown in die Protokolle des Builds durchführen und wichtige Informationen aus unserem CI einsehen – beispielsweise den Zeitpunkt des ersten Fehlers. Von dort aus können wir herausfinden, was den Fehler verursacht hat, und so genauer bestimmen, wann er aufgetreten ist.
Der CI/CD-Bereich erschließt riesige Mengen an Vorkriminalitätsdaten für Observability-Systeme. Durch das Abrufen von Telemetriedaten aus Ihren Builds können Sie eine Zeitleiste Ihrer Bereitstellungszweige erstellen und Einblick in die aufgetretenen Fehler gewinnen, eine Vielzahl instabiler Testprobleme beheben, die Grundursache von Problemen einfach finden und reproduzieren sowie die Leistung und Leistung der CI/CD-Pipeline analysieren Dauer. Führen Sie eine Fehlerbehebung durch.
Da sich die Observability in der CI-Pipeline immer weiter nach links verschiebt, können wir Probleme lösen, bevor sie eskalieren, die Effizienz steigern, indem wir Probleme aus dem Prozess entfernen, die Testrobustheit und -vollständigkeit verbessern und die mit der Nachbereitung und Ausfallzeit verbundenen Kosten und Ausgaben minimieren.
Angetrieben durch OpenTelemetry gehen wir davon aus, dass der CI/CD-Bereich zu einem der sich am stärksten entwickelnden Bereiche für Observability wird und sich mit anderen wichtigen Observability-Anwendungsfällen wie Infrastrukturüberwachung und Anwendungsleistungsüberwachung verbindet.
CI/CD ist die Grundlage – und oft auch die Voraussetzung – jedes modernen Produktionssystems. Daher sollten wir seine Bedeutung hervorheben, indem wir die Best Practices anwenden, die wir für Produktionsdienstleistungen verwenden.
Ein in den 1990er Jahren geborener Programmierer hat eine Videoportierungssoftware entwickelt und in weniger als einem Jahr über 7 Millionen verdient. Das Ende war sehr bestrafend! High-School-Schüler erstellen im Rahmen einer Coming-of-Age-Zeremonie ihre eigene Open-Source-Programmiersprache – scharfe Kommentare von Internetnutzern: Der inländische Dienst Taobao (taobao.com) verließ sich aufgrund des grassierenden Betrugs auf RustDesk und stellte die inländischen Dienste ein und startete die Arbeit zur Optimierung der Webversion von Java neu 17 ist die am häufigsten verwendete Java LTS-Version. Windows 11 erreicht weiterhin einen Rückgang. Open Source Daily unterstützt die Übernahme von Open Source Rabbit R1; Electric schließt die offene Plattform Apple veröffentlicht M4-Chip Google löscht Android Universal Kernel (ACK) Unterstützung für RISC-V-Architektur Yunfeng ist von Alibaba zurückgetreten und plant, in Zukunft unabhängige Spiele für Windows-Plattformen zu produzierenDieser Artikel wurde zuerst auf Yunyunzhongsheng ( https://yylives.cc/ ) veröffentlicht, jeder ist herzlich willkommen.