Logs, Metriken und Alerts

Alles hier findest du auf der App-Seite, in den Tabs Logs und Metrics, und in der API. In deiner App muss nichts installiert werden, außer dem OpenTelemetry-SDK, wenn du Traces willst.

Live-Logs

Der Logs-Tab streamt, was deine Container ausgeben, in dem Moment, in dem sie es ausgeben. Du kannst nach Prozess filtern. railyard logs my-app --follow --process web macht dasselbe im Terminal. Download speichert die letzte Ausgabe.

Log-Historie und Aufbewahrung (Beta)

Railyard speichert außerdem jede Zeile, damit die Karte Log history zeitlich zurück suchen kann.

• Wie lange Logs aufbewahrt werden: Team → Logs → Keep app logs for (days). Standard sind 7 Tage.
• Zeitraum: letzte Stunde, 24 Stunden, 7 Tage, 30 Tage, oder zwischen zwei Daten und Uhrzeiten.
• Suche: Klartext, oder /regex/ (/regex/i ignoriert Groß-/Kleinschreibung). Du kannst auch nach Mindest-Level, Prozess filtern, und bei Access-Logs nach Status und Pfad.
• Paging: 200 Zeilen auf einmal, neueste zuerst. Older results macht dort weiter, wo du aufgehört hast.
• Download these lines speichert den Bereich als Textdatei.

Gespeicherte Suchen und Log-Alerts

Speichere eine Suche und richte optional einen Alert dafür ein: N passende Zeilen innerhalb von M Minuten. Alerts gehen an Benachrichtigungsregeln mit aktiviertem log alerts, höchstens einmal pro Zeitfenster.

Log-Drains

Logs-Tab → Log drains sendet jede Log-Zeile an deine eigene Senke, entweder einen HTTPS-Endpunkt, der JSON entgegennimmt, oder einen Syslog-Server (syslog://logs.example.com:514). Access-Log-Zeilen kommen mit source: "router" an.

Access-Logs

Jede Anfrage, die über Railyards Proxy deine App erreicht, wird zu einer router-Zeile:

at=info method=GET path="/cart?id=7" host=shop.example.com status=200 duration=12.3ms bytes=532 fwd="203.0.113.9" user_agent="curl/8.4.0"

5xx-Antworten werden auf Error-Level geloggt, sodass Error-Filter und Log-Alerts sie erfassen. Access-Logs erscheinen in Live-Logs, Log-Suche, Downloads und Drains. Railyards eigene Uptime-Probes werden ausgelassen. Um sie abzuschalten, deaktiviere Settings → Networking → Access logs → Collect access logs. Das wirkt sofort, ohne dass ein Deploy nötig ist.

Metriken

Der Metrics-Tab zeigt Requests pro Minute, p50/p95/p99-Latenz, Fehlerrate, Bandbreite und die langsamsten Endpunkte.

Metric Alerts

Im Metrics-Tab lässt die Karte Alerts Deployer und höher Regeln wie p95 response time above 800 ms for 5 minutes hinzufügen. Du kannst Alerts setzen auf:

• p95-Antwortzeit, in ms;
• 5xx-Fehlerrate, in %;
• Speicher, als % des Container-Limits;
• CPU, in % (100 bedeutet einen Kern).

Regeln werden jede Minute geprüft. Eine Regel löst aus, sobald der Wert für die gesamte Dauer über dem Schwellenwert geblieben ist, und ein einmaliges Unterschreiten setzt die Uhr zurück. Wenn sie auslöst, geht eine Nachricht an Benachrichtigungsregeln mit aktiviertem metric alerts, und ein Eintrag öffnet sich in der History der Karte mit Startzeit, Dauer und Spitzenwert. Fällt der Wert wieder zurück, geht eine back to normal-Nachricht raus. Du kannst Regeln pausieren und fortsetzen.

Background-Job-Queues (Beta)

Für Apps, die Sidekiq, Solid Queue, GoodJob, Resque oder Delayed Job laufen lassen, zeigt der Metrics-Tab eine Karte Background jobs. Railyard liest sie jede Minute aus dem eigenen Redis oder Postgres deiner App. Sie zeigt:

• die Queue-Tiefe und den ältesten wartenden Job;
• wie viele Jobs beschäftigt, verarbeitet und fehlgeschlagen sind;
• die 50 letzten Fehlschläge, jeweils mit Retry und Discard;
• ein 24-Stunden-Diagramm.

Bleibt die Queue gestaut, bekommen Regeln mit aktiviertem job backlog eine Nachricht, und eine weitere, wenn sie aufgeholt hat.

Sie kann kein Redis außerhalb von Railyard lesen, kein Solid Queue auf MySQL und keine Sidekiq-Namespaces.

OpenTelemetry

Settings → General → OpenTelemetry. Gib einen OTLP-Endpunkt, ein Protokoll (http/protobuf, http/json oder grpc) und optionale Header wie x-honeycomb-team=YOUR_KEY ein. Header werden verschlüsselt gespeichert. Beim nächsten Deploy setzt Railyard die Variablen, die jedes OpenTelemetry-SDK liest:

• OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL und OTEL_EXPORTER_OTLP_HEADERS;
• OTEL_SERVICE_NAME, der Name der App;
• OTEL_RESOURCE_ATTRIBUTES, das die Commit-SHA, die Umgebung, die App und das Team trägt.

Eine Variable, die du selbst setzt, gewinnt immer.

Aktiviere also send Railyard’s CPU, memory and request metrics, um sie jede Minute an <endpoint>/v1/metrics zu senden. Dieser Export nutzt immer OTLP über HTTP (Port 4318 bei den meisten Collectors).

Um die App zu instrumentieren, füge das herstellerneutrale SDK hinzu und lass es diese Variablen lesen. Für Rails sind das opentelemetry-sdk, opentelemetry-exporter-otlp und opentelemetry-instrumentation-all mit c.use_all, auf dem http/protobuf-Protokoll. Für Node ist es @opentelemetry/auto-instrumentations-node/register, und für Python opentelemetry-instrument.

API

Methode	Pfad	Zweck
GET	/api/applications/:id/logs	Letzte Container-Logs
GET	/api/applications/:id/log_search	Gespeicherte Zeilen: q, level, process, status, path, range oder from/to
GET	/api/applications/:id/log_download	Dieselben Filter, als Text
GET / PATCH / DELETE	/api/applications/:id/otel_export	OpenTelemetry-Einstellungen
GET / POST	/api/applications/:id/metric_alerts	Alert-Regeln und ihre Historie
GET	/api/applications/:id/job_queue	Queue-Statistiken und fehlgeschlagene Jobs, mit Retry und Discard