OpenTelemetry-Tracing, ohne deine Infrastruktur anzufassen
Die meisten „Observability zu deiner Rails-App hinzufügen“-Anleitungen starten damit, einen Collector aufzusetzen. Der eigentlich mühsame Teil ist aber nicht der Collector – es ist, die richtigen Umgebungsvariablen konsistent in jede Umgebung zu bekommen, von Hand, ohne Tippfehler, jedes Mal, wenn ein neuer Service dazukommt.
Was die Plattform tatsächlich setzt
Settings → General → OpenTelemetry nimmt einen OTLP-Endpoint, ein Protokoll (http/protobuf, http/json oder grpc) und optionale Header entgegen – etwa einen API-Key für Honeycomb. Header werden verschlüsselt gespeichert. Beim nächsten Deploy setzt Railyard genau das, was jedes OpenTelemetry-SDK bereits erwartet zu lesen:
OTEL_EXPORTER_OTLP_ENDPOINT,OTEL_EXPORTER_OTLP_PROTOCOL,OTEL_EXPORTER_OTLP_HEADERSOTEL_SERVICE_NAME– der eigene Name der App, nichts, das du erfinden musstOTEL_RESOURCE_ATTRIBUTES– trägt Commit-SHA, Umgebung, App und Team, sodass ein Trace einem exakten Deploy zuordenbar ist, ohne das selbst zu verdrahten
Setze eine dieser Variablen selbst, und dein Wert gewinnt – das ist ein Default, kein Lock-in.
Was mit deiner App kommt, nicht mit der Plattform
Die Variablen sind plattformseitig. Die eigentliche Instrumentierung ist weiterhin das herstellerneutrale SDK, das du wie jede andere Abhängigkeit hinzufügst:
- Rails:
opentelemetry-sdk,opentelemetry-exporter-otlp,opentelemetry-instrumentation-allmitc.use_all, aufhttp/protobuf. - Node:
@opentelemetry/auto-instrumentations-node/register. - Python:
opentelemetry-instrument.
An diesem Teil ist nichts Railyard-spezifisch – dasselbe SDK funktioniert unverändert gegen jeden OTLP-Collector, was der eigentliche Zweck des Protokolls ist. Die Aufgabe der Plattform endet dabei, die Variablen jedes Mal richtig zu setzen, nicht dabei, die Instrumentierungsebene zu ersetzen.
Die eigenen Metriken der Plattform, auf derselben Leitung
Aktivier auch Railyards CPU-, Speicher- und Request-Metriken senden, und die Plattform postet ihre eigenen Zahlen jede Minute an <endpoint>/v1/metrics, über OTLP HTTP – sodass Infrastruktur-Metriken und Anwendungs-Traces im selben Backend landen, statt in zwei getrennten Dashboards, die du gedanklich korrelieren musst.
Wo das neben Logs und Alerts steht
OpenTelemetry deckt Traces und Metriken ab; die tägliche Log-Suche, gespeicherte Suchen mit Alerts und Log-Drains zu deiner eigenen Senke sind ein separater, einfacherer Weg, der überhaupt kein SDK braucht – nützlich, wenn ein Trace Overkill ist und du einfach Produktions-Output durchsuchen musst. Metrik-Alerts (p95-Antwortzeit, 5xx-Rate, Speicher, CPU) funktionieren unabhängig davon, ob OTel konfiguriert ist.
Vollständige Referenz: Logs, metrics and alerts.