GBIM: So gelingt effektive Observability mit Prometheus, k6 und Correlation IDs

Unternehmen kämpfen oft damit, technische Monitoring-Daten sinnvoll mit geschäftlichen Zielen zu verknüpfen. Eine aktuelle Fallstudie zeigt, wie das GBIM-Team genau dieses Problem löste – mit einer maßgeschneiderten Observability-Strategie, die Prometheus-Metriken, durchgängige Correlation IDs und k6-Smoke-Tests kombiniert.

Das Ergebnis ist eine Plattform, auf der sich nicht nur Server-Antwortzeiten, sondern auch kritische Geschäftsprozesse wie Registrierungen, Kontoaktivierungen oder Antragsstatus-Updates in Echtzeit überwachen lassen. Besonders beeindruckend: Die Lösung entstand aus einer klaren Fokussierung auf nachweisbare Mehrwerte – weg von generischen HTTP-Metriken, hin zu messbaren Business-Outcomes.

Warum generische Monitoring-Daten selten reichen

Vor der Umstellung verfügte GBIM bereits über eine Prometheus-Grafana-Infrastruktur. Doch die meisten Metriken zeigten lediglich technische Kennzahlen wie Antwortzeiten oder Fehlerquoten – ohne direkten Bezug zu den eigentlichen Geschäftsprozessen.

So blieben wichtige Fragen offen:

• Wie viele Registrierungsversuche scheitern tatsächlich an der Validierung?
• Führen ungültige Tokens oder Rate-Limits zu vermehrten Aktivierungsfehlern?
• Wo genau scheitern Administratoren bei der Bearbeitung von Anträgen?

Die Lösung lag nicht in zusätzlicher Komplexität, sondern in der gezielten Anreicherung bestehender Systeme mit geschäftsrelevanten Metriken und konsistenten Trace-IDs.

Drei Säulen für echte Observability

GBIM baute seine Lösung auf drei zentralen Bausteinen auf, die nahtlos zusammenarbeiten:

1. Business-Metriken mit Prometheus: Vom HTTP-Logging zum Prozessmonitoring

Das Backend-Team erweiterte die bestehende Prometheus-Integration um maßgeschneiderte Metriken für die wichtigsten Geschäftsflüsse. Diese wurden direkt in den relevanten Code-Segmenten implementiert – etwa im Authentifizierungsmodul oder bei der Bearbeitung von Anträgen.

Die neuen Metriken decken kritische Ereignisse ab:

• gbm_auth_register_total{role="user",outcome="success"} – Erfolgreiche Nutzerregistrierungen
• gbm_auth_activation_total{outcome="token_invalid"} – Aktivierungsfehler durch ungültige Tokens
• gbm_admin_account_verification_total{action="list",outcome="failed"} – Fehlgeschlagene Administratoren-Verifizierungen im Listenmodus
• gbm_pengajuan_admin_status_update_total{status="rejected",outcome="validation_error"} – Abgelehnte Anträge aufgrund von Validierungsfehlern

Diese granularen Metriken ermöglichen es den Teams nun, nicht nur technische Probleme zu erkennen, sondern auch geschäftliche Zusammenhänge zu verstehen. So lässt sich etwa schnell identifizieren, ob ein Anstieg der Fehlerquoten bei Anträgen auf technische Probleme oder auf inhaltliche Validierungslogik zurückzuführen ist.

2. Durchgängige Correlation IDs: Vom Frontend bis zum Backend-Log

Ein häufiges Hindernis bei der Fehleranalyse ist die fehlende Verknüpfung von Anfragen über verschiedene Systemkomponenten hinweg. GBIM löste dieses Problem mit einem durchgängigen Correlation-ID-System.

Die Implementierung folgt einem klaren Workflow:

1. Frontend-Integration: Die React-Anwendung sendet in der Datei lib/api.ts bei jeder API-Anfrage einen Header X-Correlation-ID. Selbst beim Aktualisieren von Tokens wird die ID konsistent übertragen.

1. Backend-Validierung: Ein spezieller CorrelationIdMiddleware prüft die eingehende ID:

• Ist sie leer oder ungültig (z. B. kein UUID-Format), generiert das System eine neue.
• Die ID wird in den Log-Kontext übernommen und an die Response angehängt.

1. Logging-Filter: Im Backend sorgt der CorrelationIdFilter dafür, dass jeder Log-Eintrag das Feld corr_id enthält. Bei Fehlern kann das Frontend die zurückgelieferte ID direkt für die Suche in den Backend-Logs nutzen.

Diese Konsistenz reduziert die Fehlerbehebungszeit deutlich – besonders in verteilten Systemen, in denen eine einzige Anfrage mehrere Microservices durchläuft.

3. Automatisierte Smoke-Tests mit k6: Performanz als Teil der Observability

Smoke-Tests sind nicht nur für die Qualitätssicherung relevant, sondern auch ein mächtiges Werkzeug für die Observability. GBIM nutzt k6, um synthetische Anfragen an kritische Endpunkte zu senden und die Ergebnisse direkt in Prometheus zu schreiben.

Die Implementierung umfasst drei zentrale Komponenten:

• Testskript: Die Datei k6/monitoring-smoke.js enthält definierte Szenarien wie:

  import http from 'k6/http';
  import { check } from 'k6';
  
  export let options = {
    vus: 1,
    duration: '30s',
  };
  
  export default function() {
    let res = http.get(');
    check(res, {
      'status is 200': (r) => r.status === 200,
    });
  }

• Kubernetes-Job: Die YAML-Datei k8s/job/k6-monitoring-smoke.yaml stellt sicher, dass die Tests regelmäßig und automatisiert ausgeführt werden.

• Prometheus-Integration: Über den Parameter --web.enable-remote-write-receiver nimmt Prometheus die Testergebnisse entgegen und macht sie in Grafana sichtbar. Die Metriken werden mit dem Tag testid=monitoring-smoke versehen, um sie leicht von anderen Daten zu unterscheiden.

Die Tests decken nicht nur technische Gesundheitschecks ab, sondern auch geschäftskritische Szenarien – etwa den Versuch, einen Anmelde-Link mit einem ungültigen Token aufzurufen. So lassen sich Probleme wie Rate-Limits oder abgelaufene Tokens noch vor dem Auftreten von Nutzerbeschwerden erkennen.

Zusätzliche Signale: Frontend-Analytics als Ergänzung

Während die Hauptobservability-Lösung auf Prometheus, Correlation IDs und k6 basiert, ergänzte das Team die Strategie um gezielte Frontend-Analytics. Über eine Helferbibliothek in lib/analytics.ts werden Ereignisse an Google Analytics 4 (GA4) gesendet – allerdings nur unter klar definierten Bedingungen:

• Die Umgebungsvariable NEXT_PUBLIC_GA_MEASUREMENT_ID muss gesetzt sein.
• Die Anwendung läuft in staging oder production.
• Die Host-Domain ist in einer Allowlist enthalten.

Die erfassten Events umfassen:

• Registrierungsversuche (register_submitted, register_success)
• Aktivierungsstatus (activation_verified, activation_expired)
• Administratoren-Aktionen (admin_verification_list_viewed)
• Anpassungen von Antragsstatus (pengajuan_admin_status_updated)

Wichtig: Da Next.js Umgebungsvariablen mit Präfix NEXT_PUBLIC_ bereits beim Build verarbeitet, musste die CI/CD-Pipeline so angepasst werden, dass die Analytics-ID erst nach dem Deployment verfügbar war. Andernfalls wären die Events in Staging nicht erfasst worden.

Fazit: Observability als Investition in die Zukunft

GBIMs Ansatz zeigt, wie Observability nicht als technisches Add-on, sondern als integraler Bestandteil der Anwendungsentwicklung verstanden werden kann. Durch die Kombination von maßgeschneiderten Metriken, durchgängigen Trace-IDs und automatisierten Tests entstand ein System, das nicht nur technische Probleme sichtbar macht, sondern auch direkte Einblicke in die geschäftliche Performance liefert.

Die nächste Herausforderung wird sein, diese Prinzipien auf weitere Geschäftsprozesse auszuweiten und die Observability noch stärker in die DevOps-Pipeline zu integrieren. Langfristig könnte dies den Weg für eine vollautomatisierte Fehlererkennung und -behebung ebnen – ein Ziel, das viele Unternehmen noch anstreben.