OpenTelemetry

Monitoring next Level


28.09.2024

kubectl describe trainer fpommerening
{
  name: "Frank Pommerening",
  employer: {},
  skills: [
    "Senior-Softwareentwickler",
    "Consultant",
    "Trainer"
  ],
  communication:{
    email : "frank@pommerening-consulting.de",
    twitter: "@fpommerening"
  }
}

OpenTelemetry

Überblick

Überblick

High-quality, ubiquitous, and portable telemetry
to enable effective observability.

  • Ursprünglich aus OpenCensus und OpenTracing hervorgegangen
  • Seit August 2021 - Ein Projekt der CNCF in der Inkubationsphase
  • Verarbeitung von Telemetriedaten wie Logs, verteilte Traces und Metriken
  • Verfolgt offene Standards und bietet eine lose Kopplung
  • Herstellerunabhängig und interoperabel
  • Werkzeuge, APIs und SDKs zur Erzeugung, Erfassung
    und Export von Telemetriedaten

Bestandteile

OpenTelemetry Protocol (OTLP)

  • Mechanismen zum Kodierung, Transport und
    Übertragung von Telemetriedaten
  • Gilt für Telemetriequellen, Zwischenknoten und Backends
  • Verwendet HTTP oder gRPC mit dem gleichen Protobuf-Schema
  • Bietet binäre oder JSON-Übertragung (Experimentell)
  • Enthält Optionen zur Übertragungssteuerung, einschließlich Throttling

OpenTelemetry Collector

  • Das zentrale Element von OpenTelemetry
  • Sammlung, Verarbeitung und Weiterleitung von Telemetriedaten
  • Verwendet eine Pipeline-Verarbeitung

APIs und SDKs

  • Gemeinsame Schnittstellen, einschließlich Protobuf
  • Bibliotheken zur Integration in eigene Anwendungen

Sprachunterstützung

Aktuell werden elf Programmiersprachen von OpenTelemetry unterstützt.
Der Entwicklungsstand variiert dabei erheblich.
C++  .NET  Erlang/Elixir  GO  
Java  JavaScript  PHP  Python  
Ruby  Rust  Swift  

OpenTelemetry

.NET

Übersicht

  • Unterstützung für Full-Framework < 4.6.1 und .NET (Core)
  • Bereitstellung als Nuget-Pakete

Exporter

Die Exporter leiten die gesammelten Dateien zur Verarbeitung weiter.
Das Ziel muss dabei nicht zwangsläufig ein OpenTelemetry Collector bzw. OpenTelemetry Agent sein.
Auch Systeme wie Jaeger , Prometheus oder Zipkin sind möglich.

Instrumentation

OpenTelemetry liefert bereits Implementierungen der Telemetrie von
ASP.NET ASP.NET Core HTTP clients
Grpc.Net.Client Redis Client MS SQL Client

Integration

Dependency Injection

services.AddOpenTelemetry().ConfigureResource(rb => 
            rb.AddEnvironmentVariableDetector().AddService(ServiceName))
  .WithMetrics(metricsBuilder =>
  {
    metricsBuilder.AddAspNetCoreInstrumentation();
    metricsBuilder.AddHttpClientInstrumentation();
    metricsBuilder.AddOtlpExporter(otlpOptions =>{ otlpOptions.Endpoint = new Uri(...);}));
  })
  .WithTracing(WithTracing =>
  {
    traceBuilder.SetSampler(new AlwaysOnSampler());
    traceBuilder.AddAspNetCoreInstrumentation();
    traceBuilder.AddHttpClientInstrumentation();
    traceBuilder.AddOtlpExporter(otlpOptions =>{ otlpOptions.Endpoint = new Uri(...);}));
  });

Manuell

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .ConfigureResource(res => res.AddService(ServiceName))
    .AddAspNetCoreInstrumentation()
    .AddHttpClientInstrumentation()
    .AddOtlpExporter(otlpOptions =>{ otlpOptions.Endpoint = new Uri(...);
    .Build();
using var meterProvider = Sdk.CreateMeterProviderBuilder()
    .ConfigureResource(res => res.AddService(ServiceName))
    .AddAspNetCoreInstrumentation()
    .AddHttpClientInstrumentation()
    .AddOtlpExporter(otlpOptions =>{ otlpOptions.Endpoint = new Uri(...);
    .Build();

Eigene Instrumentation

Für die Integration in eigene Anwendungen bzw. Bibliotheken ist keine Abhängigkeit zu OpenTelemetry erforderlich.

Activity / ActivitySource

ActivitySource ActivitySource = new ActivitySource(ActivitySourceName, ...)
using var activity = ActivitySource.StartActivity(ActivityName);

Metriken

Meter Meter = new Meter(MeterName, ...)
var counter = Meter.CreateCounter<int>(CounterName, Unit, Description);
var gauge = Meter.CreateObservableGauge<int>(CounterName, ()=>GetValue(), Unit, Description);

Logging

Das Logging erfolgt über das Interface ILogger bzw. ILogger<T>.

OpenTelemetry

Collector

Überblick

  • Der Collector ist das zentrale Element von OpenTelemetry.
  • Er sammelt, verarbeitet und leitet Telemetriedaten in einer Pipeline weiter.
  • Die Ein- und Ausgänge der Pipelines folgen etablierten Standards, darunter Prometheus, Jaeger und Fluent Bit.
  • Die Umstellung der Systeme auf den Collector kann schrittweise erfolgen.
  • Unterstützung verschiedener CPU Architekturen
    u.a. x86/x64, PPC und ARM7/ARM64.
  • Für verschiedene Betriebssysteme
    wie Windows, MacOS und Linux verfügbar.
  • Die Konfiguration erfolgt in YAML oder CRD für den Operator.

Bestandteile

Receiver

Der Receiver liefert die Eingangswerte, die entweder über
eine Schnittstelle empfangen (Push) oder abgerufen (Pull) werden können.
Es erfolgt eine Umsetzung in einen einheitlichen Datenstrom.
Die Parameter der Receiver sind spezifisch.

Exporter

Die Exporter stellen die Ausgabewerte bereit, die
entweder passiv über Schnittstellen abgerufen (Pull)
oder aktiv an ein System weitergeleitet (Push) werden.

Processor

Die Prozessoren verarbeiten den Datenstrom innerhalb der Pipeline. Dabei erfolgt die Filterung, Anreicherung und Umwandlung der Daten.

Extensions

Diese Erweiterungen erweitern die primären Funktionen des Collectors um Aspekte wie Monitoring (Health-Checks) und Speichermanagement.

Service / Pipelines

Die Pipeline beschreibt den Fluss der Telemetriedaten vom Receiver zu einem Exporter. Dabei können Prozessoren und Erweiterungen durchlaufen werden.

Konfiguration 

receivers:
  otlp:
    protocols:
      grpc:{}
      http:{}
exporters:
  jaeger:
    endpoint: jaeger.fqdn:14250
extensions:
  health_check: {}
processors:
  batch: {}
service:
  extensions:
  - health_check
  pipelines:
    traces:
      exporters:
      - jaeger
      processors:
      - batch
      receivers:
      - otlp

Struktur

Beispielanwendung