sixty

für Teams, die OpenTelemetry bereits nutzen

Alle Exporter behalten. Release-Erkennung ergänzen.

Dein Collector besitzt bereits verbundene Traces, Runtime-Metriken, Service-Identität und Fan-out. Behalte jedes Ziel, ergänze Sixty als OTLP/HTTP-Exporter und mache aus derselben Telemetrie einen Release-Detektor.

Was es misst

Verbundene HTTP-, RPC- und Datenbank-Spans
Operationen, Abhängigkeiten, Latenzverteilungen, Eigenzeit, Fehler, Datenbankaufrufe und Zeilen, sofern semantische Attribute sie liefern.
Nützliche semantische Histogramme
HTTP- und RPC-Dauerhistogramme bilden ohne Traces eine Baseline mit geringerer Genauigkeit.
Runtime- und Pool-Druck
CPU, Speicher, Event-Loop, GC-Pausen und Pool-Druck werden begrenzter Befundkontext.
Service-, Umgebungs- und Release-Identität
service.name wählt den Service, deployment.environment.name die Umgebung und deployment.revision oder service.version das Release.

Was es findet

Jedes davon wird gegen das Release davor verglichen, der Befund benennt also die Änderung und nicht den Tag.

Ein Endpoint wurde nach einem Release langsamer

Verteilungen werden pro Operation und Release verglichen, damit gemeinsame Last nicht als Code-Regression erscheint.

Ein Datenbankpfad erledigt mehr Arbeit

Verbundene Spans zeigen Änderungen bei Aufrufen, Round Trips, Latenz und Zeilen, wenn semantische Belege vorliegen.

Sättigung hinter mehreren langsamen Operationen

CPU, Speicher, Event-Loop, GC und Pool-Druck bestätigen eine gemeinsame Ressourcenursache.

Eine Abhängigkeit wird langsam oder fehlerhaft

Ausgehende Spans bleiben Abhängigkeiten und werden nicht in deine Eigenzeit gemischt.

Telemetrie ohne vergleichbare Identität

Fehlendes service.name wird teilweise abgewiesen; fehlende oder konstante Releases erscheinen als Ingest-Status.

Was in deinem Verlauf landet

Kein Dashboard zum Lesen. Eine Karte pro Befund, mit den Zahlen, dem Release, das sie verändert hat, und den Belegen, die dein Coding-Agent braucht, um die Lösung zu schreiben.

Erzeugt von apps/otel-demo-app: sechs reine OTEL-Releases laufen ohne nativen Agent über den öffentlichen Receiver.

LatenzGET /checkout
118 ms286 ms2.4×

Der Server-Span wurde langsamer, während Runtime-Sättigung und Pool-Druck im selben Release stiegen.

im OTEL-Demo über sechs Releases

DatenbankaufrufeGET /checkout
2 Aufrufe7 Aufrufe3.5×

Verbundene Datenbank-Spans zeigen mehr Downstream-Arbeit und halten sie am Endpoint.

im OTEL-Demo über sechs Releases

Wie es installiert wird

Ergänze einen Exporter neben den vorhandenen Zielen. Ersetze keine Receiver, Prozessoren, Sampling-, Redaktions- oder Exporter-Regeln und füge keine Sixty-Log-Pipeline hinzu.

exporters:
  otlphttp/sixty:
    endpoint: https://ingest.sixty.sh
    headers:
      Authorization: "Bearer ${env:SIXTY_OTEL_KEY}"
    compression: gzip
    retry_on_failure:
      enabled: true

service:
  pipelines:
    traces:
      exporters: [your_existing_exporter, otlphttp/sixty]
    metrics:
      exporters: [your_existing_exporter, otlphttp/sixty]

Validiere und starte nur den Collector neu. Sende Traffic unter zwei Release-Werten; check_service bestätigt Daten und Identität.

Was es nicht tut

  • OTEL ist keine native Agent-Parität: automatische Funktions-Spans, treiberspezifische Query-Details und Quellzuordnung fehlen. Priorität: nativer Agent, OTEL-Trace, OTEL-Metrik.
  • Sixty ist kein Trace-Warehouse. Es speichert begrenzte Skizzen und Exemplare, keine Trace-Suche oder Dashboards.
  • Logs und beliebige Custom Metrics werden per Partial Success abgewiesen; rohe SQL-Statements werden nicht gespeichert.
  • Ein Gateway für viele Anwendungen darf kein globales service.name setzen; Identität und Release gehören je Anwendung gesetzt.

Falls du wegen einer dieser Sachen hier bist

Finde heraus, was deine letzte Änderung angerichtet hat.

Probier es aus!

Du baust etwas anderes? Sieh dir Node-Dienste, Python-Dienste oder Go-Dienste an — diese Seiten sind anders, und was wir sehen können, auch.

Release-Regressionen aus OpenTelemetry-Traces und -Metriken — Sixty