OpenTelemetry-Logs in Rails: So haben wir es konfiguriert
How we configured OpenTelemetry logs in Rails
Wir zeigen, wie wir OpenTelemetry-Logs in einer Rails-Anwendung direkt an Grafana Cloud exportiert haben – ohne OpenTelemetry Collector. Der Beitrag erklärt die Einrichtung des Ruby SDK, die benötigten Gems und die Konfiguration per Umgebungsvariablen. Dabei stoßen wir auf zwei Bugs im Ruby SDK: Der Exporter verlor den Basis-Pfad des Endpunkts und behandelte HTTP-204-Antworten fälschlich als Fehler. Beide Probleme meldeten wir und lieferten Fixes, die inzwischen veröffentlicht wurden. Abschließend geben wir einen Ausblick auf strukturiertes Logging mit rails_semantic_logger.
Grafana Cloud gibt nach dem Empfang von Logs den Status 204 No Content zurück, aber der Exporter behandelte nur 200 OK als Erfolg – die Exporte waren erfolgreich, aber unsere App protokollierte jeden als Fehler.
- willcodeforfoo
Würde gerne sehen, was die Leute so machen, um das in Grafana zu visualisieren.
- jasondjk
Ich würde behaupten, dass es viel mächtiger ist, das Nutzerverhalten direkt in eure monolithische App-Datenbank zu loggen – etwa mit dem ahoy-Gem – statt in ein externes System wie Grafana oder ähnliches. Denn dann könnt ihr einen Agenten auf eine Kopie eurer Datenbank loslassen, und der kann gleichzeitig alle eure operativen und geschäftlichen Kennzahlen verknüpfen, ohne dass ihr versuchen müsst, etwa ein Nutzerprofil zwischen Grafana/Salesforce/Hubspot/Intercom etc. zu verbinden. Zum Beispiel: „Claude, sag mir, welche Kunden aktivieren und konvertieren, welche abspringen und warum, und mach einen Plan, um den Trichter zu optimieren.“ Das anzubinden war noch nie einfacher: https://insidertrades.directory/built-with-rails/ahoy-blazer... also: bauen statt kaufen im Zeitalter von KI.