OpenTelemetry im Jahr 2023

 (bit.kevinslin.com)
2 Punkte von GN⁺ 2023-08-29 | 1 Kommentare | Auf WhatsApp teilen
  • OpenTelemetry, das 2019 aus der Zusammenlegung von OpenTracing und OpenCensus hervorging, hat sich in nur vier Jahren als Observability-Standard etabliert, der Traces, Metriken und Logs umfasst
  • Die zentrale Struktur ist in Spezifikation und Implementierungen unterteilt und bietet sowohl den Maßstab für Vendor-Kompatibilität als auch tatsächliche Instrumentierungs- und Erfassungswerkzeuge
  • Die OTEL-Spezifikation erreichte mit der Stabilisierung von Tracing im Jahr 2020, Metriken im Jahr 2021 und Logs im Jahr 2023 den Status alle Signale stable, auch wenn die Log-Unterstützung je nach SDK noch unterschiedlich ist
  • OTLP und der Collector bilden die Grundlage dafür, Observability-Daten in einem gemeinsamen Format zu senden und zu verarbeiten; auch Vendor-Agenten wie Grafana und Datadog implementieren dies
  • OTEL erweitert seinen Umfang um Collector, Semantic Conventions, OpAMP, OTTL und Demo und wächst zur gemeinsamen Basis für vendor-neutrale Observability

Die aktuelle Stellung von OpenTelemetry

  • OpenTelemetry, kurz OTEL, entstand 2019 durch die Zusammenführung von OpenTracing und OpenCensus
  • Anfangs war es ein auf Tracing fokussiertes Projekt, nach der Zusammenlegung weitete sich der Umfang jedoch auf die gesamte Observability aus
  • Ziel ist es, Organisationen dabei zu helfen, hochwertige, universelle und portable Telemetrie bereitzustellen
  • Nach vier Jahren verfügt OTEL über folgende Grundlagen
    • stabile Standards für Metriken, Logs und Traces
    • einen Collector, der Telemetrie in jeder Umgebung empfangen, verarbeiten und exportieren kann
    • SDKs, die Code-Instrumentierung in den wichtigsten Sprachen unterstützen
    • zusätzliche Standards für Semantic Conventions und Agent-Management
  • Derzeit ist OTEL innerhalb der CNCF nach Kubernetes das aktivste Projekt; Mitwirkende kommen aus der Breite der großen Observability-Vendoren, und das Protokoll ist unter Observability-Anbietern nahezu universell übernommen worden

OTEL-Aufbau: Spezifikation und Implementierungen

  • OTEL besteht im Wesentlichen aus Spezifikation (specification) und Implementierungen (implementation)
  • Die Spezifikation definiert, wie Telemetrie erfasst, gesammelt, verarbeitet und exportiert wird
    • Sie ist im Grunde ein gemeinsamer Standard, dem Vendoren folgen müssen, um mit OTEL kompatibel zu sein
  • Implementierungen sind Client-Bibliotheken und Werkzeuge zum Umgang mit Telemetrie-Daten
    • Das ist der Teil, mit dem Endnutzer direkt in Berührung kommen, wenn sie ihren Code instrumentieren
  • Die Stabilität des Projekts wird üblicherweise pro Signal angegeben
    • In OTEL bezeichnet ein Signal einen Typ von Telemetrie-Daten wie Metriken, Logs oder Traces
  • Die wichtigsten Unterprojekte sind folgende
    • OpenTelemetry Specification
    • OpenTelemetry SDKs
    • OpenTelemetry Protocol
    • OpenTelemetry Collector
    • Open Agent Management Protocol
    • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

  • Die OpenTelemetry Specification ist das Fundament von OTEL und stellt APIs, SDKs und Datenmodelle bereit, die als Basis für andere OTEL-Standards dienen
  • Die Stabilisierung erfolgte signalweise
    • September 2020: Tracing stable
    • November 2021: Metriken stable
    • April 2023: Logs stable
  • Aktuell ist die OTEL-Spezifikation für alle Signale stable
  • Da das Log-Signal erst 2023 stabilisiert wurde, unterstützen viele OTEL-SDKs Logs noch nicht

OpenTelemetry SDK und Auto-Instrumentierung

  • Das OTEL SDK bietet clientseitige Instrumentierung auf Basis der OTEL-Spezifikation
  • Bei den sprachspezifischen SDKs gibt es für Metrik-, Log- und Trace-Signale jeweils einen eigenen Reifegrad
  • Einige SDKs unterstützen je nach Programmiersprache Auto-Instrumentierung (auto instrumentation)
    • Auto-Instrumentierung bedeutet, dass das SDK Signale, vor allem Traces, automatisch in den Anwendungscode einfügt und so den Aufwand manueller Instrumentierung reduziert
  • In kompilierten Sprachen wie go und rust funktioniert Auto-Instrumentierung nicht
  • Außerhalb des SDKs lässt sich automatische Trace-Injektion jedoch mit auf eBPF oder Service Mesh basierenden Werkzeugen erreichen

OTLP 1.0 und der Standard für Datenübertragung

  • OTLP ist ein gemeinsames Wire Protocol zur Übertragung von Observability-Daten
  • Es gibt zwei offizielle Transportarten
  • Diese Spezifikation gilt als stable und kann von allen Services implementiert werden, die OTEL-Daten empfangen, verarbeiten und exportieren
  • OTLP wird vom OpenTelemetry Collector implementiert; auch Agenten von Observability-Vendoren wie Grafana und Datadog unterstützen es

OpenTelemetry Collector 0.83.0

  • Der OTEL Collector ist ein vendor-neutraler Agent zum Sammeln, Transformieren und Übertragen von Observability-Daten
  • Der Collector besteht aus folgenden Komponenten
    • receivers: empfangen Daten aus verschiedenen Quellen per Push/Pull
    • processors: transformieren, filtern, erweitern und leiten Daten während der Übertragung ab
    • exporters: senden Daten an nachgelagerte Ziele
    • connectors: arbeiten zugleich als receiver und exporter und verbinden mehrere Pipelines miteinander
    • pipelines: Ketten aus receiver, null oder mehr processors und exporter
    • extensions: stellen Funktionen außerhalb der Telemetrieverarbeitung bereit, etwa basic auth oder health check
  • Zusammen bilden diese Komponenten eine Observability-Pipeline, die Telemetrie aus beliebigen Quellen erfassen, unterwegs verarbeiten und an das gewünschte Ziel senden kann
  • Der Collector ist in zwei Projekte aufgeteilt
    • otel-collector: enthält nur die Kernkomponenten des Collectors und vor allem Logik, die direkt mit der Verarbeitung von OTLP-Daten zusammenhängt
    • otel-collector-contrib: eine Sammlung von Integrationen mit Exportern und Receivern für die meisten Observability-Anbieter
  • Zum Zeitpunkt des Schreibens umfasst otel-collector-contrib 91 receiver, 48 exporter und 24 processor
  • Endnutzern wird empfohlen, mit dem OpenTelemetry Collector Builder einen Custom-Build von otel-collector-contrib zu erstellen, der nur die benötigten Komponenten enthält
  • Vendoren wie AWS und Splunk bieten außerdem eigene OTEL-Distributionen an

OpAMP und Remote-Management von Agenten

  • OpAMP ist ein Netzwerkprotokoll für das Remote-Management von Agenten
  • Es ist ein relativ neuer Standard, der 2022 zu OTEL hinzugefügt wurde, und bietet einen vendor-neutralen Ansatz zur Steuerung einer Agenten-Flotte
  • Die verwalteten Ziele können otel-collector-Instanzen oder vendor-spezifische Agenten sein, die OpAMP implementieren
  • Mit OpAMP lassen sich folgende Funktionen aktivieren
    • dynamische Konfigurationsverteilung
    • Agent-Updates
    • Verwaltung von Zugangsdaten
  • Aktuell befindet sich die Go-Implementierung der OpAMP-Spezifikation in Bearbeitung

Semantic Conventions und weitere Projekte

  • Die OTEL Semantic Conventions definieren einen gemeinsamen Satz von Attributen für Observability-Daten
  • Der Anwendungsbereich umfasst Cloud-Ressourcen, Datenbanken, Ausnahmen, Systeme und mehr
  • Semantic Conventions werden von OTEL-SDKs verwendet und bei SDKs mit Unterstützung für Auto-Instrumentierung automatisch angewendet
  • Eine gemeinsame Semantik ermöglicht die Korrelation zwischen unterschiedlichen Signalen
  • Weitere wichtige OTEL-Bausteine existieren ebenfalls separat
    • OpenTelemetry Transformation Language (OTTL): eine gemeinsame Transformationssprache für Telemetrie, die Performance und Flexibilität bietet und in otel-collector-contrib entworfen und implementiert wurde
    • OTEL Demo: eine Microservices-basierte Shopping-Website, die OTEL-Funktionen und die meisten Sprach-SDKs demonstriert

Veränderungen in vier Jahren

  • OTEL entwickelte sich aus der Zusammenführung konkurrierender Tracing-Spezifikationen zu einem Industriestandard für Observability
  • Die vergangenen vier Jahre waren eine Phase des Aufbaus einer gemeinsamen Grundlage über Vendoren und Werkzeuge hinweg

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-29
Meinungen auf Hacker News

  • OpenTelemetry hat zwei Probleme

    1. Es ist unklar, was es eigentlich ist. Ob es ein semantischer Standard, ein Protokoll, eine Fassade, eine Bibliothek ist und welche Abstraktionsebene es bietet, bleibt vage; die Antwort liegt nahe bei „alles zusammen“
    2. Auf Seiten von OpenTelemetry wirkt es so, als habe niemand tatsächlich einmal eine Bibliothek instrumentiert. Es gibt auch keine Empfehlungen dazu, wie Instrumentierer Metriken, Traces und Logs verwenden sollen, ob sie alle drei oder nur eines davon nutzen sollen. Vor zwei Jahren gefragt, aber keine Antwort erhalten: https://github.com/open-telemetry/opentelemetry-specificatio...
    • Zustimmung. Es ist, als bekäme man eine Küchenspüle samt daran angebautem Haus auf einmal; dadurch wird auch die Dokumentation dünn und verwirrend
      Ähnlich wollte ich für eine Desktop-App einen einfachen Heartbeat implementieren, um die Nutzung zu erfassen, aber gemessen am Projektnamen war das überraschenderweise nahezu unmöglich. Auf Fragen gab es auch kaum Resonanz, also habe ich die OpenTelemetry-Pläne komplett aufgegeben: https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
    • Zustimmung. Einiges von dem, was OpenTelemetry empfiehlt, ist mit den tatsächlichen SDKs nicht möglich
      Zum Beispiel kann man Buckets nicht in der Nähe der Stelle definieren, an der man ein Histogramm definiert. Man muss irgendwo, etwa bei einem globalen Exporter, eine Liste von „Overrides“ übergeben, die Histogrammnamen auf Buckets abbildet. Wenn es eine Bibliothek gibt, die Metriken ausgibt, wird das sehr unsauber: https://github.com/open-telemetry/opentelemetry-go/issues/38...
    • Das sind gute Fragen, aber ich halte sie nicht für besonders wichtig. Solche Fragen sind im Bereich Observability, egal ob bei OpenTelemetry oder einem anderen proprietären System, schwer eindeutig zu beantworten
      Selbst auf den Websites führender Observability-Unternehmen gibt es zu Custom Instrumentation vielleicht vier Seiten, und die behandeln nur sehr grundlegende Dinge. OTel hängt nicht besonders hinterher; die Antwort lautet meist eher „es kommt darauf an“. Mit wachsender Erfahrung kann man diese für Einsteiger verwirrenden Punkte auflösen
    • Nötig gewesen wäre nur, etwa drei JSON-Schema-Dateien zu pflegen
    • Die dritte Frage lautet, ob es skalierbar ist

  • Ich mag OpenTelemetry sehr und möchte nahezu jeden Span verfolgen. Hätte ich irgendeinen Vendor genutzt, wäre ich an den Kosten bankrottgegangen
    Mit Java-Autoinstrumentierung habe ich OpenTelemetry mit fast keinem Aufwand angebunden und schicke es an selbst gehostetes ClickHouse, wo ich über 700 Millionen Spans pro Tag auf einer 100-Dollar-EC2-Instanz speichere: https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

    • In einem kleinen persönlichen Projekt schicke ich über SigNoz Traces/Logs/Metriken an ClickHouse. Es sind etwa 400.000 bis 800.000 Spans pro Tag (https://i.imgur.com/s0J6Mzo.png); auf einer einzelnen t4g.small liegt die CPU meist bei 11 %, die IOPS bei 4 %
      Bei einem Monat Trace-Aufbewahrung hat signoz_index_v2 26,9 Millionen Zeilen und 17.06GiB, trace_log 123 Millionen Zeilen und 2.64GiB, samples_v2 949 Millionen Zeilen und 345MiB, die Kompression ist also gut. Mit einer ClickHouse-Maschine gemäß Empfehlung hätte ich weniger Zeit fürs Tuning gebraucht, aber auch so läuft es gut
      Der Nachteil ist, dass die IOPS der kleinen sc1-Disk bei etwa 4 liegen, weshalb ClickHouse ungefähr 5 Minuten zum Starten braucht, und dass die SigNoz-UI zwar funktional ausreicht, man aber kein Datadog-Niveau an Polish erwarten sollte
    • Man sollte eine Sampling-Rate festlegen, aber sicherstellen, dass alle Fehler gesendet werden
      In einem früheren Job haben wir nur 5 % der fehlerfreien Traces gesammelt
    • Realistisch betrachtet wollen die meisten keinen eigenen ClickHouse-Speicher betreiben, und auch nicht alle Engineers gehen mit SQL so effizient um wie mit Code. Trotzdem ist das ein ziemlich cooles Setup
    • Cool ist auch, dass der Einrichtungsaufwand gering war. Es ist die Kombination aus Java-Autoinstrumentierung + ClickHouse-Exporter + Grafana-ClickHouse-Plugin

  • Ich war von OpenTelemetry ziemlich enttäuscht. Meiner Erfahrung nach ist es ein überdesigntes, verwirrendes Gebilde, und die grundlegende Nutzungserfahrung ist sehr nutzerfeindlich.
    Es vermarktet sich selbst als universelles Format für Traces/Metriken/Logs und als Bündel von Plug-and-play-Bibliotheken mit Adaptern für alles, was man braucht. In der Praxis leaken jedoch viele interne Implementierungsdetails, die Adapterqualität ist schlecht und der Funktionsumfang eher begrenzt – eher ein halbgares Bibliotheksbündel.

    • Stimme zu. Jedes Mal, wenn ich das SDK benutze, fühlt es sich an, als müsste ich in einer Weise denken, die quer zum gesunden Menschenverstand steht. Nichts verhält sich wie erwartet, alles hat drei Schichten unnötiger Abstraktion, und man muss durch die Hintertür zugreifen.
      Viele Funktionen kommen mit Hinweisen wie: wann, wo, wie oft, bei welcher Mondphase, wenn Jupiter am Himmel sichtbar ist und die String-Länge einen bestimmten Wert hat, sie funktionieren.
      Wenn man die undichten SDK-APIs und die halb implementierten Features ignoriert, hält es das Versprechen der Austauschbarkeit aber zu einem gewissen Grad. Vor OTel war alles ein proprietärer Stack; jetzt kann man erwarten, ein anderes Logging-Backend an ein Standard-SDK anzustecken und dass es im Großen und Ganzen funktioniert. Es ist schlechter als ein vertikal integrierter Stack, aber aus Architektursicht ein Teilerfolg, weil es Wettbewerb und Weiterentwicklung einzelner Teile ermöglicht, ohne den gesamten Observability-Stack auszutauschen.
    • Ich habe denselben Schmerz erlebt, aber Alternativen, die behaupten, dank OpenAPI-Spezifikation besser zu sein, sind beim Ausprobieren auch nicht wirklich besser: https://github.com/openzipkin/zipkin-api-example
      Das Beispiel zeigt nur, wie man mit Swagger-Tools die OpenAPI-Spezifikation (https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...) parst, Go-Glue-Code automatisch generiert und dann eine automatisch generierte Funktion aufruft, um einen Trace aufzuzeichnen.
      Es gibt keinerlei Dokumentation und auch keine anderen Beispiele, sodass ich mich gefragt habe, ob diesen Ansatz überhaupt jemand praktisch nutzt. Am Ende habe ich die Service-API (https://zipkin.io/zipkin-api/#/) direkt per REST-Aufruf verwendet. OTel ist schmerzhaft, aber die Alternativen sind nicht besser. Da SLO- und SLI-Messungen immer wichtiger werden, würde ich mir wünschen, dass diesem Bereich mehr Aufmerksamkeit zukommt.
    • Mich würde interessieren, ob man dann eine Alternative empfehlen kann oder ob man OTel einfach in Kauf nimmt.
    • Es wäre gut, konkrete Erfahrungen und Verbesserungsvorschläge zu hören.

  • Die offiziellen OTel-Bibliotheken funktionieren im Web-Frontend noch nicht gut. Zum Beispiel gibt es im Standardzustand keine Möglichkeit, Fehler mit Source Maps zu verknüpfen.
    Der vom OTel-Projekt bereitgestellte Web-Browser-Collector verwendet Zone.js, um nahezu alles im Browser als Kontext abzufangen. Wer modernes Angular verwendet hat, weiß, dass Zone.js manchmal ziemlich schmerzhaft sein und durch Eingriffe in globale Zustände unvorhersehbares Verhalten erzeugen kann.
    Ich kenne auch keinen OTel-Standard für Dinge wie Session Replay. Viele Telemetrie-Plattformen wie Sentry, Rollbar und DataDog unterstützen das. Backend-Teams scheinen es ziemlich zu mögen, und mir gefällt die Eigenschaft von Spans, Grenzen zu überschreiten, sodass man mit eindeutigen Tags dem gesamten System folgen kann. Allerdings sind die erzeugten Payloads bisweilen sehr ausführlich, während manche Logging-Plattformen kompakter sind. In der Praxis habe ich das nicht als großes Problem empfunden.

    • In Umgebungen mit nativen Promises und async/await scheint es derzeit keine Möglichkeit zu geben, etwas wie Zone.js sauber zu implementieren.
      Ich habe auch selbst instrumentiert, aber das war fehleranfällig und umständlich. Browser brauchen wirklich etwas wie https://nodejs.org/api/async_context.html#class-asynclocalst....
    • Auf den meisten Plattformen war Otel eher ein Ausgangspunkt, um eine gute Instrumentierungsbibliothek zu bauen.
      In unserem Paket setzen wir Session Replay, verbessertes Exception-Tracking usw. auf die Browser-SDK-Implementierung von Otel/Splunk auf. Leider sind solche Dinge weit davon entfernt, standardmäßig enthalten zu sein. Trotzdem denke ich, dass die Möglichkeit, Frontend-Sessions mit Backend-Traces/-Logs zu verknüpfen, die Developer Experience deutlich verändert hat: https://www.hyperdx.io/blog/browser-based-distributed-tracin...
    • Auch diese Dokumentation von Otel ist sehenswert: https://opentelemetry.io/docs/instrumentation/js/getting-sta...
      Sie löst das Problem nicht vollständig, ist aber ein Ausgangspunkt.
    • Auch Real User Monitoring, DataDogs Frontend-Instrumentierung, wirkt auffällig unausgereift. Die Feinfühligkeit entspricht ungefähr dem Hantieren mit Duplo-Steinen.
      Mich würde interessieren, ob überhaupt jemand mit Frontend-Tracing nennenswert angefangen hat.
    • Mich würde interessieren, ob du Grafana Faro gesehen hast. Man kann es an Grafana Agent senden lassen; Grafana Agent ist Open Source und kann Traces an anderer Stelle speichern.

  • Ein paar Kollegen und ich hatten die etwas abwegige Idee, dass man keine Logs mehr braucht. Statt Log-Nachrichten hängt man einfach Span-Events an: https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
    Danach loggt man nur noch den Span-Titel und den Link zum entsprechenden Span in Jaeger. Ich habe das nur in einem privaten Projekt ausprobiert, fand es aber ziemlich gut; schön wäre nur, wenn die Jaeger-UI diese Art der Nutzung besser unterstützen würde.
    Tatsächlich halten diese Kollegen zu dem Thema auch einen Vortrag. Wer in der Nähe von Hannover ist, kann unter https://javaforumnord.de/2023/programm/ nach „Nie wieder Log-Files!“ suchen.

    • Je nachdem, wie sehr ein Projekt Greenfield ist, braucht man möglicherweise nicht einmal Span-Events, außer man benötigt nur den Zeitstempel einer bestimmten Aktion und nicht ihre Dauer.
      Für jede sinnvolle Aktion Spans zu verwenden, ähnelt der Nutzung stärker strukturierter Logs. Für viele Systeme, die bestehende Logs mitschleppen müssen, ist das schwierig, aber bei ausreichend viel Greenfield würde ich es empfehlen.
    • Ich habe auch über diesen Ansatz nachgedacht, mag aber, dass man mit einfachen Werkzeugen grob nachvollziehen kann, was passiert.
      Damit Traces funktionieren, müssen viele Dinge korrekt zusammenspielen. Oder vielleicht fehlt mir noch die Erfahrung und die Tools wirken deshalb einschüchternd.
    • Das war die Idee hinter Stripes Veneur-Projekt: Spans, Logs und Metriken im selben Format behandeln und die Kardinalität bei Bedarf „automatisch“ zusammenrollen.
      Als ich vor ein paar Jahren einen Vortrag dazu gesehen habe, fand ich das cool, aber ich hatte den Eindruck, dass es sehr schwer wäre, Entwickler außerhalb des SRE-Bereichs davon zu überzeugen: https://github.com/stripe/veneur
    • Man muss Traces auch nirgendwohin schicken. Man kann sie im Prozess behalten und auf diesen In-Memory-Trace-Daten eine API aufbauen.
    • Genau darüber sprechen wir auch im Unternehmen. Es ergibt ziemlich viel Sinn, und ich denke, man könnte Logs damit fast vollständig abschaffen.

  • OpenTelemetry ist ein marketinggetriebenes Projekt, naiv und ineffizient im Ausschussverfahren entworfen und implementiert, und es wirkt so, als sei sein Hauptziel, Fortune-X00-CTOs ein Häkchen in ihren strategischen Roadmap-Dokumenten zu ermöglichen.
    Das ist nichts, was jemand verwenden sollte, der eine Wahl hat.

    • Die anderen Kommentare in diesem Thread sind überwiegend wohlwollend oder sehr positiv; ich würde gern genauer hören, was konkret daran schlecht ist.
    • Als Gründer von highlight.io habe ich aus Nutzersicht viel Wert in OTEL gesehen. Wir haben es genutzt, um die Sprachunterstützung für mehrere Kunden auszubauen, und die Community war sehr aufgeschlossen.
      Ein Beispiel für eine unserer Änderungen ist hier: https://github.com/open-telemetry/opentelemetry-js/pull/4049
      Ich würde mich freuen, wenn du teilen könntest, warum deiner Meinung nach niemand es verwenden sollte.
    • Diese Einschätzung halte ich für falsch. Für mich wirkt es eher nach: „Open-Source-Software exportiert Prometheus-Metriken und Jaeger-Traces, wir wollen aber ein proprietäres Alternativprodukt verkaufen und nicht in jedem Projekt Patches einreichen.“
      Datadog hat tatsächlich in großem Stil Leute eingesetzt, um Datadog-Support in OSS-Projekte einzubauen. In fremde Codebasen einzusteigen ist eine starke Fähigkeit, also war das für den Berufseinstieg vielleicht gar nicht schlecht.
      OTel bringt Open-Source-Projekte dazu, eine Abstraktionsschicht zu nutzen, damit Nutzer kaufen können, statt selbst zu hosten. Begeistert bin ich davon nicht, aber bei Diensten, die von Leuten außerhalb des Unternehmens betrieben werden, würde ich heute wohl OTel in Betracht ziehen. Denn wenn ein Nutzer Datadog verwenden möchte, stehen wir ihm dann nicht im Weg.
      Als ich sehr frühes OTel genutzt habe, war ich enttäuscht, weil die Go-API sehr ineffizient war. Zum Erhöhen eines Counters brauchte man context.Context, und die Abstraktion leckte an Stellen wie der fehlenden Möglichkeit, beim Export nach Prometheus Histogram-Buckets zu konfigurieren. Ich nehme an, das ist inzwischen behoben.
    • Das ist übertrieben hart. Das Datenmodell sehe ich als Fortschritt in die richtige Richtung.
      Auch der Prozessor ist ziemlich leistungsfähig, und die Sammlung von Receivern und Exportern in contrib ist insgesamt ordentlich. Ich sage nicht, dass es die beste Lösung ist, und es hängt vom Anwendungsfall ab, aber so scharfe Kritik scheint mir nicht gerechtfertigt. Zur Einordnung: Ich gehöre zum Maintainer-Team von fluent-bit.
    • Es ist großartig, Services OTLP sprechen zu lassen und die Anwendungskonfiguration darauf zu vereinfachen, Daten an den OTEL Collector zu senden.
      Aus Betriebssicht kann man zentral Filterung erzwingen, egal welche Observability Entwickler in den Code einbauen, und es braucht nur einen zentralen Einstiegspfad, mit dem Anwendungen sprechen.
      Da alles OTLP exportiert, muss man beim Wechsel auf ein neues Backend nur eine YAML-Datei ändern und die Anwendung nicht neu schreiben, um ein neues Logging-Backend zu unterstützen. Lieber bleibe ich trotz aller Schwächen in 10 von 10 Fällen bei OTEL, als zur alten Welt mit vendorspezifischen Logging-Libraries zurückzukehren.

  • Ich hasse das Abo-Popup dieses Blogs wirklich. Es gibt keinen x-Button, daher ist überhaupt nicht klar, dass man es schließen kann, ohne seine E-Mail-Adresse anzugeben.
    Unter dem Abo-Button steht ein sehr unintuitives „continue reading“; ich hätte nicht erwartet, dass das funktioniert, und ein Klick außerhalb schließt es auch nicht. So etwas muss besser werden.
    Was OpenTelemetry angeht, wollte ich schon lange ausprobieren, ob es alle Funktionen bietet, die wir brauchen, wenn wir Daten an Datadog senden. Wenn wir aber neben den Grundfunktionen weiterhin den Datadog-Agent brauchen, wäre das nur eine weitere Sache, die wir verwalten und schulen müssen, und deshalb zögere ich.
    Mich würde interessieren, ob es jemand tatsächlich an Datadog angebunden hat. Das Ziel ist nicht unbedingt, dauerhaft an Datadog gebunden zu bleiben, aber da ein großer Teil unserer Alerts und Logs derzeit dort liegt, könnten wir theoretisch später leichter zu etwas anderem wechseln, wenn wir zuerst auf OpenTelemetry umstellen.

    • Dieses Popup ist eine Funktion von medium.com. Ich stimme zu, dass es sehr nervig ist.
    • Für mich persönlich war die Umfrage noch schlimmer. Sie fragten nach meiner Meinung, ich klickte auf eine Option, und als Belohnung bekam ich ein bildschirmfüllendes Fenster zur Kontoerstellung.
      Als ich auf Zurück klickte, landete ich wieder bei HN.

  • Ich frage mich, ob es noch ein Frontend gibt, das die Einnahmequellen nicht durch Personal-, Infrastruktur- und Lizenzkosten stark auffrisst.
    Bei mehr als 2.000 Requests pro Sekunde ist schon allein das Vorhalten von Logs teuer.

    • Falls ihr es noch nicht macht: Ich empfehle Trace-Sampling. Datadog APM hat mich nicht überzeugt, weil es keine günstige Konfiguration gibt.
      Wir betreiben unseren eigenen Jaeger-Stack mit 0,1 % Sampling, und im Vergleich zu Datadog APM sind die Kosten vernachlässigbar.
      Für Metriken und Logs ist Sampling nicht besonders nützlich, daher gibt es dafür keine gute Antwort. Wenn Datadogs Bruttomarge 80 % beträgt, entfallen von euren Zahlungen höchstens 20 % auf Infrastrukturkosten. Wenn die Personalkosten unter diesen 80 % liegen, könnt ihr mit einem selbst betriebenen Open-Source-Stack viel Geld sparen. Selbst wenn man Datadog nutzt, macht man alle drei Monate ein Projekt zur Reduzierung der Nutzung; man muss sich also ohnehin ständig darum kümmern.
    • Die Antwort ist Sampling. Erfolgreiche Requests nur zu 1 % sampeln und Fehler vollständig erfassen.
      Kosten sind ein Thema, aber ihr könntet überrascht sein, wie schwer Observability für einen Service tatsächlich wiegt. Sie verbraucht ziemlich viel CPU.
    • Man muss festlegen, was „stark“ bedeutet. In einer früheren Firma haben wir Traces nach Cassandra geroutet, in einer AWS-Elasticsearch-Domain gespeichert und mit Jaeger visualisiert.
      Um grundlegende Reports zum Finden langsamer Queries zu erstellen, habe ich auch ein paar Elasticsearch-Queries geschrieben. Wenn man den OTEL/Jaeger-Tutorials folgt, ist das eine ziemlich standardmäßige Konfiguration.
      Die Traces lagen bei einigen Hundert pro Sekunde, und wir haben alles ohne Downsampling erfasst. Die Aufbewahrungsdauer konnte auf 7 Tage eingestellt werden, und als ich ging, gab es praktisch keine echte Optimierung. Die monatlichen Kosten lagen meiner Erinnerung nach im Bereich von einigen Dutzend bis einigen Hundert Dollar.
      Das Verhalten des Tracing-Samplers lässt sich über Umgebungsvariablen definieren, die man für den Container setzen kann. Siehe OTEL_TRACES_SAMPLER in der Dokumentation: https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
    • Die meisten Observability-Anbieter unterstützen inzwischen OTEL. Auch das OSS-Projekt, an dem ich beteiligt bin, unterstützt OTEL-Ingestion: https://github.com/grafana/tempo/
    • Ich weiß nicht, warum das downgevotet wird. Wir haben denselben Schmerz, nur eben bei 500.000 Requests pro Sekunde.
      Aktuell nutzen wir Datadog, aber alle wissen, dass es viel zu teuer ist.

  • In den meisten Beiträgen in diesem Thread geht es darum, Metriken/Logs mit OpenTelemetry an selbst gehostete Collector-Jobs zu schicken.
    Es ist schon für sich genommen nützlich, eine Standardbibliothek zu verwenden, die von vielen Collector-Tools wie ClickHouse unterstützt wird. Ein weiterer Vorteil ist aber, dass die Spezifikation es ermöglicht, Trace-IDs über Systemgrenzen hinweg weiterzugeben.
    Wenn sowohl man selbst als auch die Abhängigkeiten die OpenTelemetry-Spezifikation implementieren, erhält man Spans, die sehr detailliert zeigen, was auf dem Weg passiert ist. So kann man zum Beispiel erkennen, ob ein langsamer Seitenaufbau durch das Laden einer Disk-Page in der Datenbank verursacht wurde oder ob ein Span der Metadata Plane eines Cloud-Service für die hohe Latenz verantwortlich war.

  • Ich bin sehr zufrieden mit den Fortschritten von OpenTelemetry. Als ich vor ein paar Jahren seine Einführung vorangetrieben habe, zögerten die Entwickler, weil es neu war und sie noch nie davon gehört hatten. Als ich vor einem Jahr wieder darauf schaute, war OpenTelemetry überall in unseren Systemen zu finden, und auch unser Logging-/Tracing-Anbieter war dabei, darauf umzusteigen.