Ruby Monitoring von Ende zu Ende für schnellere Ursachenanalyse
Mit zwei OpenTelemetry-Gems verfolgt Obseria jeden Rails-Request und jeden Sidekiq-Job, verknüpft langsame Queries, Redis-Aufrufe und GC-Last und zeigt die Ursache einer Verlangsamung.
Warum Ruby mit Obseria überwachen
Ein Initializer, volle Abdeckung
opentelemetry-instrumentation-all instrumentiert Rails, ActiveRecord, Sidekiq, Redis, Net::HTTP und viele weitere Gems mit einem einzigen use_all-Aufruf.
Requests und Jobs in einem Trace
Der Trace-Kontext wandert vom Rails-Controller über Redis bis in den Sidekiq-Worker. Hintergrundjobs sind damit kein blinder Fleck mehr.
Vom Symptom zur Ursache
Obseria Intelligence verknüpft eine Latenzspitze mit dem Deployment, dem langsamen SQL-Statement oder dem ausgelasteten Puma-Pool, der sie ausgelöst hat.
Ruby-Frameworks und Bibliotheken, die Obseria überwacht
- Ruby on Rails. Controller, Action-View-Rendering, Active Job und Action Cable erscheinen als Spans mit Route und Statuscode.
- ActiveRecord, pg und mysql2. Jedes SQL-Statement wird zum Client-Span, N+1-Queries werden im Trace-Wasserfall sichtbar.
- Sidekiq und Active Job. Enqueue- und Perform-Spans verbinden Web-Requests mit den Workern, die sie abarbeiten, inklusive Wartezeit in der Queue.
- Puma, Rack und Sinatra. Rack-Middleware erzeugt Server-Spans für jede Rack-App, die Thread-Auslastung von Puma erscheint als Metrik.
- Redis, Faraday und Net::HTTP. Cache-Aufrufe und ausgehende HTTP-Requests tragen den W3C-Trace-Kontext zu nachgelagerten Diensten.
- CRuby-Runtime. Heap-Slots, GC-Läufe und Prozessspeicher zeigen, wie sich der Interpreter unter echter Last verhält.
Die Ruby-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Tempo und Fehler
Zeigt, wie schnell Ihre Ruby-Anwendung Besuchern antwortet und wie oft eine Seite mit einem Fehler statt einem Ergebnis endet.
Kapazität und Datenbankzugriff
Zeigt, ob die Anwendung genug freie Arbeiter und Datenbankverbindungen hat, um alle Anfragen ohne Wartezeit zu bedienen.
Aufgaben im Hintergrund
Macht sichtbar, ob Aufgaben wie der Versand von E-Mails oder Rechnungen pünktlich laufen oder sich stauen und scheitern.
Verbrauch an Speicher
Zeigt, wie viel Speicher die Anwendung belegt und wie oft sie aufräumt, damit wachsender Bedarf vor einem Absturz auffällt.
Alle 9 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
ruby_http_request_duration_seconds | s | Zeit, die Rails pro Request benötigt, das zentrale Latenzsignal je Controller und Action. |
ruby_http_requests_total | {request} | Anzahl der Requests je Statuscode, Grundlage für Durchsatz und Fehlerrate. |
ruby_puma_busy_threads | {thread} | Aktuell belegte Puma-Threads; nahe am Maximum beginnen Requests zu warten. |
ruby_active_record_connection_pool_waiting | {thread} | Threads, die auf eine Datenbankverbindung warten, ein direktes Zeichen für einen zu kleinen Pool. |
ruby_sidekiq_queue_latency_seconds | s | Alter des ältesten Jobs je Queue; steigende Werte heißen, die Worker kommen nicht hinterher. |
ruby_sidekiq_failed_jobs_total | {job} | Fehlgeschlagene Sidekiq-Jobs je Worker-Klasse, um defekte Jobs nach einem Deployment zu erkennen. |
ruby_heap_live_slots | {slot} | Belegte Objekt-Slots im Ruby-Heap; stetiges Wachstum deutet auf zurückgehaltene Objekte. |
ruby_major_gc_ops_total | {run} | Major Garbage Collections; häufige volle GCs kosten CPU und erhöhen die Latenz. |
ruby_rss | By | Resident Memory des Ruby-Prozesses, um Speicherwachstum zu sehen, bevor der Container beendet wird. |
Ruby-Monitoring in wenigen Minuten einrichten
- Schritt 1
Gems hinzufügen
Ergänzen Sie opentelemetry-sdk, opentelemetry-exporter-otlp und opentelemetry-instrumentation-all im Gemfile und führen Sie bundle install aus.
- Schritt 2
Initializer anlegen
Rufen Sie in config/initializers/opentelemetry.rb OpenTelemetry::SDK.configure mit use_all auf; Endpoint und Token kommen aus OTEL_*-Variablen.
- Schritt 3
Runtime-Metriken ergänzen
Stellen Sie Puma-, Sidekiq- und GC-Metriken mit dem Gem prometheus_exporter bereit und lassen Sie sie vom Obseria Agent oder OpenTelemetry Collector abholen.
# Gemfile
gem "opentelemetry-sdk"
gem "opentelemetry-exporter-otlp"
gem "opentelemetry-instrumentation-all"
# config/initializers/opentelemetry.rb
require "opentelemetry/sdk"
require "opentelemetry/exporter/otlp"
require "opentelemetry/instrumentation/all"
# Umgebungsvariablen (im Deployment setzen):
# OTEL_SERVICE_NAME=storefront
# OTEL_RESOURCE_ATTRIBUTES=deployment.environment.name=production
# OTEL_EXPORTER_OTLP_ENDPOINT=${OBSERIA_OTLP_ENDPOINT}
# OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20${OBSERIA_TOKEN}
OpenTelemetry::SDK.configure do |c|
c.use_all # Rails, ActiveRecord, Sidekiq, Redis, Net::HTTP, Faraday ...
endSofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Rails-Service-Health mit RED-Metriken je Action
- Sidekiq-Queues: Latenz, Rückstau, Fehler
- Alert bei ausgelasteten Puma-Threads
- Alert bei zu hoher Sidekiq-Queue-Latenz
- Langsamste ActiveRecord-Queries je Endpoint
Ruby-Monitoring: Darauf kommt es an
Warum Ruby Monitoring wichtig ist
Ruby on Rails betreibt Onlineshops, SaaS-Produkte und interne Werkzeuge, bei denen Teams schnell liefern wollen. Diese Geschwindigkeit hat in Produktion ihren Preis: Puma bedient Requests mit einer festen Zahl an Threads, ActiveRecord versteckt SQL hinter bequemen Methoden, und ein großer Teil der eigentlichen Arbeit läuft asynchron in Sidekiq. Wird eine Seite langsam, kann die Ursache in jeder dieser Schichten liegen. Ruby Monitoring verbindet sie, damit Sie sehen, ob Zeit im eigenen Code, in der Datenbank, in Redis oder in einer Job-Queue verloren geht.
OpenTelemetry Ruby bietet ein als stabil eingestuftes Tracing und eine große Zahl an Instrumentierungs-Gems. Das Meta-Gem opentelemetry-instrumentation-all bindet sie ein, und ein einziger Aufruf von use_all aktiviert die Instrumentierung für jede unterstützte Bibliothek in Ihrem Bundle. So wird Ruby APM ohne proprietären Agent und ohne Änderung am Anwendungscode möglich.
Die wichtigsten Signale für Ruby Performance Monitoring
Ein brauchbares Ruby Performance Monitoring kombiniert Traces mit einer kurzen Liste von Runtime- und Queue-Metriken:
- Latenz und Fehler: Server-Spans je Controller-Action und
ruby_http_request_duration_secondsliefern die RED-Sicht. Fehler-Spans enthalten Exception-Klasse und Stacktrace. - Puma-Kapazität:
ruby_puma_busy_threadsim Vergleich zum konfigurierten Maximum zeigt, ab wann Requests auf einen freien Thread warten. - Datenbank-Pool:
ruby_active_record_connection_pool_waitingmacht Threads sichtbar, die blockieren, bevor die Query überhaupt startet. - Sidekiq:
ruby_sidekiq_queue_latency_secondsundruby_sidekiq_failed_jobs_totalzeigen, ob Hintergrundarbeit pünktlich und fehlerfrei läuft. - Speicher und GC:
ruby_heap_live_slots,ruby_major_gc_ops_totalundruby_rsszeigen Allokationsdruck und wachsenden Speicherbedarf.
Metriken in OpenTelemetry Ruby befinden sich noch in Entwicklung. Runtime-, Puma- und Sidekiq-Metriken erfassen Sie daher am besten mit dem verbreiteten Gem prometheus_exporter und lassen sie neben den Traces in Obseria einlesen.
Typische Probleme mit Rails und Sidekiq erkennen
N+1-Queries
Eine Listenansicht, die Assoziationen einzeln nachlädt, setzt Dutzende fast identische SQL-Statements ab. Im Trace-Wasserfall erscheint das als lange Treppe kurzer ActiveRecord-Spans unter einem Request. Gruppiert nach Statement wird das Muster sofort sichtbar.
Ausgelastete Threads und Pools
Ist der ActiveRecord-Pool kleiner als die Summe aus Puma-Threads und Sidekiq-Concurrency, warten Threads auf Verbindungen. Sie sehen gleichzeitig wartende Threads, flache CPU-Last und steigende Latenz.
Wachsender Rückstau in Sidekiq
Eine langsame externe API oder ein neuer, teurer Job lässt Queues über Stunden anwachsen. Ein Alert auf die Queue-Latenz statt auf die Queue-Größe erfasst Verzögerungen, die Kunden bemerken, etwa verspätete E-Mails oder Rechnungen.
Wachsender Speicherbedarf
Ruby-Prozesse, die viele Objekte allokieren, vergrößern ihren Heap und geben Speicher selten zurück. Steigender ruby_rss und häufige Major GCs nach einem Release zeigen, welcher Codepfad ins Profiling gehört.
Regressionen nach einem Release
Eine neue Gem-Version oder ein geänderter Scope kann einen Endpoint verlangsamen, ohne dass ein Fehler auftritt. Der Vergleich von Latenz und Query-Anzahl je service.version direkt nach einem Deployment trennt echte Regressionen von Rauschen und zeigt, welches Release Sie zurückrollen sollten.
Best Practices für Ruby on Rails Monitoring
- Setzen Sie
service.name,service.versionunddeployment.environment.namegetrennt für Web- und Worker-Prozesse, damit Puma und Sidekiq als eigene Services erscheinen. - Starten Sie mit
use_allund schalten Sie nicht benötigte Instrumentierungen ab, um das Span-Volumen fokussiert zu halten. - Dimensionieren Sie den Datenbank-Pool anhand von Puma-Threads und Sidekiq-Concurrency und alarmieren Sie auf wartende Threads.
- Schreiben Sie Trace-IDs in die Rails-Logs, damit jede Fehlerzeile direkt zu ihrem Trace führt.
- Nutzen Sie Tail-based Sampling, um jeden langsamen oder fehlerhaften Request und Job zu behalten.
So unterstützt Obseria Ruby APM
Obseria empfängt Traces aus OpenTelemetry Ruby per OTLP und liest Prometheus-Metriken Ihrer Ruby-Prozesse über den Obseria Agent oder den OpenTelemetry Collector ein. TopoGraph ordnet Rails-Apps, Sidekiq-Worker, PostgreSQL und Redis automatisch zu. Steigt die Latenz, prüft Obseria Intelligence Deployments, langsame Statements, ausgelastete Pools und Queue-Verzögerungen und präsentiert die Ursache mit nachvollziehbarer Beweiskette. Dashboards, Alerts und SLOs sind inklusive, und alle Daten bleiben per OTLP exportierbar.
Verwandte Integrationen
Passende Funktionen
Distributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenFehler-Tracking
Die Errors Inbox gruppiert Exceptions aus Backend, Frontend und Mobile Apps zu Issues, zeigt deren Auswirkung und bündelt Zuweisung und Lösung in einem Workflow.
Mehr erfahrenQueue Monitoring
Behalten Sie Consumer Lag, Durchsatz und Nachrichtenalter über alle Broker und Topics im Blick und verfolgen Sie Nachrichten vom Producer bis zum Consumer.
Mehr erfahrenMehr erfahren
Was ist APM (Application Performance Monitoring)?
Was ist APM? Wie Application Performance Monitoring Latenz, Durchsatz und Fehler misst, wie Distributed Tracing funktioniert und welche Kennzahlen zählen.
Was ist eine Root-Cause-Analyse (RCA)?
Was ist eine Root-Cause-Analyse? Der RCA-Prozess für Software-Incidents, 5 Whys, Fishbone und Fehlerbaum, ein Praxisbeispiel und RCA mit KI.
Häufige Fragen zum Ruby-Monitoring
Nein. Sie fügen drei Gems und einen Initializer mit use_all hinzu. Rails, ActiveRecord, Sidekiq, Redis und HTTP-Clients werden automatisch instrumentiert. Eigene Spans für Geschäftslogik sind optional.
Das OpenTelemetry Ruby SDK unterstützt CRuby ab Version 3.1 sowie aktuelle Versionen von JRuby und TruffleRuby. Framework-spezifische Versionsbereiche finden Sie in der Dokumentation der jeweiligen Instrumentierungs-Gems.
Die Sidekiq-Instrumentierung erzeugt Enqueue- und Perform-Spans, die mit dem auslösenden Request verknüpft sind. Für Queue-Latenz, Rückstau und Fehlerzahlen ergänzen Sie die Sidekiq-Collectors des Gems prometheus_exporter.
Tracing in OpenTelemetry Ruby ist stabil, Metriken und Logs befinden sich noch in Entwicklung. Deshalb empfehlen wir für Ruby derzeit Prometheus-basierte Runtime-Metriken; Obseria speichert beides nebeneinander.
Ja. Installieren Sie den Obseria Agent per Helm als DaemonSet und setzen Sie die OTEL_*-Variablen in der Pod-Spezifikation. Traces werden mit Pod-, Namespace- und Node-Metadaten angereichert.
Starten Sie heute mit dem Ruby-Monitoring
Binden Sie Ruby in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.