Production‑Observability Starter‑Pack für Tag eins: die minimalen Logs, Metriken und Traces, die Sie hinzufügen sollten, plus ein einfacher Triage‑Flow für „es ist langsam“‑Meldungen.
Das erste, was kaputt geht, ist selten die ganze App. Meistens ist es ein einzelner Schritt, der plötzlich viel Arbeit bekommt, eine Abfrage, die in Tests ok war, oder eine Abhängigkeit, die zu Timeouts neigt. Echte Nutzer bringen echte Vielfalt: langsamere Telefone, instabile Netze, seltsame Eingaben und Traffic‑Spitzen zu ungünstigen Zeiten.
Wenn jemand sagt „es ist langsam“, kann das sehr Verschiedenes bedeuten. Die Seite lädt vielleicht zu langsam, Interaktionen ruckeln, ein API‑Aufruf time‑outet, Hintergrundjobs türmen sich auf oder ein Drittanbieter zieht alles in die Länge.
Deshalb brauchen Sie Signale, bevor Sie Dashboards brauchen. Am ersten Tag brauchen Sie keine perfekten Diagramme für jeden Endpunkt. Sie brauchen gerade so viele Logs, Metriken und Traces, dass Sie schnell eine Frage beantworten können: Wohin geht die Zeit?
Es gibt auch ein echtes Risiko, zu früh zu über‑instrumentieren. Zu viele Events erzeugen Rauschen, kosten Geld und können die App sogar verlangsamen. Schlimmer noch: Teams verlieren das Vertrauen in Telemetrie, weil sie unordentlich und inkonsistent wirkt.
Ein realistisches Day‑One‑Ziel ist einfach: Wenn Sie eine „es ist langsam“‑Meldung bekommen, finden Sie den langsamen Schritt in unter 15 Minuten. Sie sollten sagen können, ob die Bottleneck im Client‑Rendering, im API‑Handler und dessen Abhängigkeiten, in der Datenbank oder im Cache, oder in einem Hintergrundworker oder externen Service liegt.
Beispiel: Ein neuer Checkout‑Flow fühlt sich langsam an. Auch ohne Berg von Tools wollen Sie sagen können: „95 % der Zeit gehen in Zahlprovider‑Aufrufe“ oder „die Warenkorb‑Abfrage scannt zu viele Zeilen“. Wenn Sie Apps schnell mit Tools wie Koder.ai bauen, ist diese Day‑One‑Baseline noch wichtiger — schnelle Auslieferung hilft nur, wenn Sie auch schnell debuggen können.
Ein gutes Production‑Observability‑Starter‑Pack verwendet drei verschiedene „Sichten“ auf dieselbe App, weil jede eine andere Frage beantwortet.
Logs sind die Geschichte. Sie erzählen, was für eine einzelne Anfrage, einen Nutzer oder einen Hintergrundjob passiert ist. Eine Logzeile kann sagen „Zahlung für Bestellung 123 fehlgeschlagen“ oder „DB‑Timeout nach 2s“, plus Details wie request ID, user ID und Fehlermeldung. Wenn jemand einen seltsamen Einzelfall meldet, sind Logs oft der schnellste Weg zu bestätigen, dass es passiert ist und wen es betroffen hat.
Metriken sind die Anzeigetafel. Es sind Zahlen, die Sie trendbasiert überwachen und alarmieren: Request‑Rate, Fehlerquote, Latenz‑Perzentile, CPU, Queue‑Tiefe. Metriken sagen, ob etwas selten oder weit verbreitet ist und ob es schlimmer wird. Wenn die Latenz für alle um 10:05 gestiegen ist, zeigen Metriken das.
Traces sind die Landkarte. Ein Trace verfolgt eine einzelne Anfrage, wie sie durch Ihr System läuft (Web -> API -> Datenbank -> Drittanbieter). Er zeigt Schritt für Schritt, wo Zeit verbracht wird. Das ist wichtig, weil „es ist langsam“ fast nie ein großes Mysterium ist. Meistens ist es ein einzelner langsamer Hop.
Während eines Incidents sieht ein praktischer Ablauf so aus:
Eine einfache Regel: Wenn Sie nach ein paar Minuten keinen Bottleneck benennen können, brauchen Sie nicht mehr Alerts. Sie brauchen bessere Traces und konsistente IDs, die Traces mit Logs verbinden.
Die meisten „wir können es nicht finden“‑Vorfälle entstehen nicht durch fehlende Daten. Sie passieren, weil dieselben Dinge über Services hinweg unterschiedlich aufgezeichnet werden. Ein paar gemeinsame Konventionen am ersten Tag sorgen dafür, dass Logs, Metriken und Traces beim Bedarf schnell zusammenpassen.
Beginnen Sie damit, pro deploybarem Unit genau einen Service‑Namen zu wählen und stabil zu halten. Wenn „checkout‑api“ in der Hälfte Ihrer Dashboards zu „checkout“ wird, verlieren Sie Historie und Alerts brechen. Machen Sie das Gleiche für Environment‑Labels. Wählen Sie ein kleines Set wie prod und staging und verwenden Sie diese überall.
Machen Sie jede Anfrage leicht nachverfolgbar. Erzeugen Sie eine request ID am Edge (API‑Gateway, Webserver oder erster Handler) und geben Sie sie über HTTP‑Aufrufe, Message‑Queues und Background‑Jobs weiter. Wenn ein Support‑Ticket sagt „es war um 10:42 langsam“, erlaubt eine einzelne ID, die exakten Logs und den Trace ohne Raten zu ziehen.
Ein Konventionsset, das sich am Tag eins bewährt:
Einigen Sie sich früh auf Zeiteinheiten. Wählen Sie Millisekunden für API‑Latenz und Sekunden für längere Jobs und bleiben Sie dabei. Gemischte Einheiten erzeugen Diagramme, die gut aussehen, aber die falsche Geschichte erzählen.
Ein konkretes Beispiel: Wenn jede API duration_ms, route, status und request_id loggt, wird aus einem Bericht wie „Checkout ist langsam für Tenant 418“ ein schneller Filter, statt einer Debatte, wo man anfangen soll.
Wenn Sie nur eins in Ihr Starter‑Pack aufnehmen, machen Sie Logs durchsuchbar. Das beginnt mit strukturierten Logs (meist JSON) und denselben Feldern über alle Services hinweg. Plain‑Text‑Logs sind ok für lokale Entwicklung, aber bei echtem Traffic, Retries und mehreren Instanzen werden sie zum Rauschen.
Eine gute Regel: Loggen Sie, was Sie im Incident tatsächlich brauchen. Die meisten Teams müssen beantworten: Welche Anfrage war das? Wer war es? Wo ist es fehlgeschlagen? Was hat es berührt? Wenn eine Logzeile bei keiner dieser Fragen hilft, sollte sie wahrscheinlich nicht existieren.
Halten Sie an Tag eins ein kleines, konsistentes Feldset, damit Sie Events über Services filtern und joinen können:
Bei einem Fehler: Loggen Sie ihn einmal mit Kontext. Fügen Sie einen Fehler‑Typ (oder Code), eine kurze Nachricht, einen Stacktrace für Server‑Fehler und die beteiligte Upstream‑Abhängigkeit (z. B. postgres, payment provider, cache) hinzu. Vermeiden Sie, denselben Stacktrace bei jedem Retry zu wiederholen. Hängen Sie stattdessen die request_id an, damit Sie die Kette verfolgen können.
Beispiel: Ein Nutzer meldet, dass er Einstellungen nicht speichern kann. Eine Suche nach request_id zeigt einen 500 bei PATCH /settings und dann ein Downstream‑Timeout zu Postgres mit duration_ms. Sie brauchten keine vollständigen Payloads, nur Route, User/Session und den Namen der Abhängigkeit.
Datenschutz ist Teil des Loggings, nicht eine spätere Aufgabe. Loggen Sie keine Passwörter, Tokens, Auth‑Header, vollständige Request‑Bodies oder sensible PII. Wenn Sie einen Nutzer identifizieren müssen, loggen Sie eine stabile ID (oder einen Hash) statt E‑Mails oder Telefonnummern.
Wenn Sie Apps mit Koder.ai (React, Go, Flutter) bauen, lohnt es sich, diese Felder von Anfang an in jede generierte Service‑Vorlage zu integrieren, damit Sie „Logging reparieren“ nicht mitten im ersten Vorfall tun müssen.
Ein gutes Starter‑Pack beginnt mit einem kleinen Satz Metriken, die eine Frage schnell beantworten: Ist das System gerade gesund und wenn nicht, wo tut es weh?
Die goldenen Signale
Die meisten Produktionsprobleme zeigen sich in vier „goldenen Signalen“: Latenz (Antworten sind langsam), Traffic (Last hat sich verändert), Fehler (Dinge schlagen fehl) und Saturation (gemeinsame Ressource ist ausgelastet). Wenn Sie diese vier Signale für die Hauptteile Ihrer App sehen, können Sie die meisten Vorfälle triagieren, ohne zu raten.
Latenz sollte in Perzentilen gemessen werden, nicht im Durchschnitt. Verfolgen Sie p50, p95 und p99, damit Sie sehen, wann eine kleine Nutzergruppe schlechte Erfahrungen macht. Für Traffic beginnen Sie mit Requests pro Sekunde (oder Jobs pro Minute für Worker). Für Fehler teilen Sie 4xx vs 5xx auf: steigende 4xx deuten oft auf Client‑Verhalten oder Validierungsänderungen; steigende 5xx zeigen auf Ihre App oder deren Abhängigkeiten. Saturation ist das Signal „uns geht etwas aus“ (CPU, Speicher, DB‑Connections, Queue‑Backlog).
Metrik‑Checklist nach Komponente
Ein minimales Set, das die meisten Apps abdeckt:
Konkretes Beispiel: Wenn Nutzer „es ist langsam“ melden und API p95‑Latenz steigt, während Traffic stabil bleibt, prüfen Sie als Nächstes Saturation. Wenn DB‑Pool‑Nutzung nahe am Maximum ist und Timeouts steigen, haben Sie einen wahrscheinlichen Flaschenhals gefunden. Wenn die DB in Ordnung aussieht, aber Queue‑Tiefe schnell wächst, könnten Hintergrundjobs gemeinsame Ressourcen blockieren.
Wenn Sie Apps auf Koder.ai bauen, behandeln Sie diese Checkliste als Teil Ihrer Day‑One‑Definition of Done. Es ist einfacher, diese Metriken hinzuzufügen, solange die App klein ist, als während des ersten echten Vorfalls.
Wenn ein Nutzer sagt „es ist langsam“, sagen Logs oft, was passiert ist, und Metriken sagen, wie oft es passiert. Traces sagen, wohin die Zeit in einer einzelnen Anfrage ging. Diese einzelne Timeline verwandelt eine vage Beschwerde in eine klare Reparaturanweisung.
Beginnen Sie serverseitig. Instrumentieren Sie eingehende Requests am Rand Ihrer App (der erste Handler, der die Anfrage empfängt), sodass jede Anfrage einen Trace erzeugen kann. Clientseitiges Tracing kann warten.
Ein guter Day‑One‑Trace enthält Spans, die den Teilen entsprechen, die normalerweise Slowness verursachen:
Um Traces durchsuchbar und vergleichbar zu machen, erfassen Sie ein paar Schlüsselattribute und halten Sie sie über Services hinweg konsistent.
Für den eingehenden Request‑Span: Route (als Template wie /orders/:id, nicht die volle URL), HTTP‑Methode, Statuscode und Latenz aufnehmen. Für DB‑Spans: DB‑System (PostgreSQL, MySQL), Operationstyp (select, update) und, wenn leicht hinzufügbar, den Tabellennamen. Für externe Aufrufe: Abhängigkeitsname (payments, email, maps), Zielhost und Status.
Sampling zählt am ersten Tag, sonst wachsen Kosten und Rauschen schnell. Verwenden Sie eine einfache head‑based Regel: trace 100% der Errors und langsamen Requests (wenn Ihr SDK das kann) und sampeln Sie einen kleinen Prozentsatz normalen Traffics (z. B. 1–10%). Starten Sie höher bei geringem Traffic und reduzieren Sie mit zunehmender Nutzung.
Was „gut“ aussieht: ein Trace, in dem Sie die Geschichte von oben nach unten lesen können. Beispiel: GET /checkout dauerte 2,4s, die DB hat 120ms verbraucht, Cache 10ms und ein externer Payment‑Call nahm 2,1s inklusive Retry. Jetzt wissen Sie, dass die Abhängigkeit das Problem ist, nicht Ihr Code. Das ist der Kern eines Production‑Observability‑Starter‑Packs.
Wenn jemand sagt „es ist langsam“, ist der schnellste Sieg, dieses vage Gefühl in ein paar konkrete Fragen zu verwandeln. Dieser Triage‑Flow funktioniert, selbst wenn Ihre App ganz neu ist.
Die 5‑Schritte‑Triage
Beginnen Sie damit, das Problem einzugrenzen, und folgen Sie dann der Evidenz in der richtigen Reihenfolge. Springen Sie nicht sofort in die Datenbank.
Nachdem Sie stabilisiert haben, machen Sie eine kleine Verbesserung: Schreiben Sie auf, was passiert ist, und fügen Sie ein fehlendes Signal hinzu. Wenn Sie z. B. nicht sehen konnten, ob die Verlangsamung nur in einer Region auftrat, fügen Sie ein Region‑Tag zu Latenzmetriken hinzu. Wenn Sie einen langen DB‑Span ohne Hinweis auf die Query sahen, fügen Sie vorsichtig Query‑Labels oder ein „query name“‑Feld hinzu.
Kurzes Beispiel: Wenn checkout p95 von 400 ms auf 3 s springt und Traces einen 2,4 s Span im Payment‑Call zeigen, können Sie aufhören, über App‑Code zu raten, und sich auf den Provider, Retries und Timeouts konzentrieren.
Wenn jemand „es ist langsam“ sagt, können Sie eine Stunde damit verschwenden, herauszufinden, was er meint. Ein Starter‑Pack ist nur nützlich, wenn es Ihnen hilft, das Problem schnell einzukreisen.
Beginnen Sie mit drei klärenden Fragen:
Dann schauen Sie sich ein paar Zahlen an, die meist zeigen, wohin Sie als Nächstes gehen sollten. Suchen Sie nicht nach dem perfekten Dashboard. Sie wollen nur „schlechter als normal“‑Signale.
Wenn p95 steigt, Errors aber stabil sind, öffnen Sie einen Trace für die langsamste Route der letzten 15 Minuten. Ein einzelner Trace zeigt oft, ob Zeit in der DB, bei einem externen API‑Call oder im Warten auf Locks verbracht wurde.
Führen Sie dann eine Log‑Suche durch. Wenn Sie eine konkrete Nutzer‑Meldung haben, suchen Sie nach ihrer request_id (oder correlation ID) und lesen Sie die Timeline. Wenn nicht, suchen Sie nach der häufigsten Fehlermeldung im gleichen Zeitfenster und prüfen Sie, ob sie mit der Verlangsamung übereinstimmt.
Entscheiden Sie abschließend, ob Sie jetzt mildern oder tiefer graben. Wenn Nutzer blockiert sind und Saturation hoch ist, kann eine schnelle Maßnahme (skalieren, rollbacken oder ein nicht‑essentielles Feature deaktivieren) Zeit kaufen. Wenn der Impact klein und das System stabil ist, untersuchen Sie weiter mit Traces und slow query logs.
Ein paar Stunden nach einem Release kommen Support‑Tickets: „Checkout dauert 20–30 Sekunden.“ Niemand kann es lokal reproduzieren, also beginnt man zu raten. Hier zahlt sich ein Starter‑Pack aus.
Zuerst zu Metriken, um das Symptom zu bestätigen. Das p95‑Latenz‑Diagramm für HTTP‑Requests zeigt einen klaren Spike, aber nur für POST /checkout. Andere Routen sind normal, und die Fehlerquote ist stabil. Das grenzt das Problem von „die ganze Seite ist langsam“ auf „ein Endpoint ist langsamer nach dem Release“ ein.
Als Nächstes öffnen Sie einen Trace für eine langsame POST /checkout‑Anfrage. Die Trace‑Wasserfall macht den Schuldigen deutlich. Zwei häufige Ergebnisse:
PaymentProvider.charge‑Span dauert 18 Sekunden, die meiste Zeit wird im Warten verbracht.DB: insert order‑Span ist langsam und zeigt lange Wartezeiten, bevor die Abfrage zurückkommt.Validieren Sie das mit Logs, indem Sie dieselbe request ID aus dem Trace verwenden (oder das trace ID, falls Sie sie in Logs speichern). In den Logs dieser Anfrage sehen Sie wiederholte Warnungen wie „payment timeout reached“ oder „context deadline exceeded“ plus Retries, die im neuen Release hinzugefügt wurden. Wenn es der Datenbankpfad ist, zeigen Logs möglicherweise Lock‑Wait‑Meldungen oder ein über‑Threshold geloggtes slow query statement.
Wenn alle drei Signale übereinstimmen, wird die Lösung klar:
Der Punkt ist: Sie haben nicht gerätselt. Metriken zeigten die Route, Traces zeigten den langsamen Schritt und Logs bestätigten das Fehlverhalten mit der exakten Anfrage.
Die meiste Incident‑Zeit geht auf vermeidbare Lücken zurück: Die Daten sind da, aber sie sind laut, riskant oder das eine Detail fehlt, das Symptome mit Ursache verbindet. Ein Starter‑Pack hilft nur, wenn es unter Stress nutzbar bleibt.
Eine Falle ist zu viel zu loggen, besonders rohe Request‑Bodies. Das klingt hilfreich, bis Sie für riesigen Speicher bezahlen, Suchen langsam werden und Sie versehentlich Passwörter, Tokens oder persönliche Daten erfassen. Bevorzugen Sie strukturierte Felder (route, status code, latency, request_id) und loggen Sie nur kleine, explizit erlaubte Ausschnitte der Eingaben.
Ein weiterer Zeitfresser sind Metriken, die zwar detailliert aussehen, sich aber nicht aggregieren lassen. Hochkardinale Labels wie volle User‑IDs, E‑Mails oder einzigartige Bestellnummern können Ihre Metrik‑Serie explodieren lassen und Dashboards unzuverlässig machen. Verwenden Sie stattdessen grobe Labels (Route‑Name, HTTP‑Methode, Status‑Klasse, Abhängigkeitsname) und behalten Sie Benutzerspezifisches in Logs.
Fehler, die wiederholt schnelle Diagnose blockieren:
Ein kleines praktisches Beispiel: Wenn checkout p95 von 800ms auf 4s springt, wollen Sie in Minuten zwei Fragen beantworten: Begann es direkt nach einem Deploy, und wird die Zeit in Ihrer App oder in einer Abhängigkeit (DB, Payment Provider, Cache) verbracht? Mit Perzentilen, einem Release‑Tag und Traces mit Route‑ und Abhängigkeitsnamen schaffen Sie das schnell. Ohne diese Signale verbrennen Sie die Incident‑Zeit mit Spekulationen.
Der eigentliche Gewinn ist Konsistenz. Ein Starter‑Pack hilft nur, wenn jeder neue Service mit denselben Basics shipped, gleich benannt und bei Vorfällen leicht zu finden ist.
Machen Sie Ihre Day‑One‑Entscheidungen zu einer kurzen Vorlage, die Ihr Team wiederverwendet. Halten Sie sie klein, aber konkret.
Erstellen Sie eine „Home“‑Ansicht, die jeder bei einem Incident öffnen kann. Ein Screen sollte requests per minute, Fehlerquote, p95‑Latenz und Ihre Haupt‑Saturation‑Metrik zeigen, mit Filtern für Environment und Version.
Halten Sie Alerting anfangs minimal. Zwei Alerts decken viel ab: ein Fehlerquote‑Spike auf einer Schlüsselroute und ein p95‑Latenz‑Spike auf derselben Route. Wenn Sie mehr hinzufügen, stellen Sie sicher, dass jede einen klaren Action‑Plan hat.
Führen Sie eine monatliche Review ein. Entfernen Sie laute Alerts, schärfen Sie Naming und fügen Sie ein fehlendes Signal hinzu, das beim letzten Vorfall Zeit gespart hätte.
Um das in Ihren Build‑Prozess zu integrieren, fügen Sie eine „Observability‑Gate“ in Ihre Release‑Checklist ein: kein Deploy ohne request IDs, Version‑Tags, das Home‑View und die zwei Basis‑Alerts. Wenn Sie mit Koder.ai deployen, können Sie diese Day‑One‑Signale in Planning Mode definieren, bevor Sie live gehen, und dann sicher mit Snapshots und Rollbacks iterieren, wenn Sie schnell anpassen müssen.
Beginnen Sie dort, wo Nutzer zuerst in Ihr System treten: Webserver, API‑Gateway oder Ihr erster Handler.
request_id hinzu und geben Sie sie bei allen internen Aufrufen weiter.route, method, status und duration_ms für jede Anfrage.Das allein bringt Sie in der Regel schnell zu einem konkreten Endpunkt und einem Zeitfenster.
Zielen Sie auf dieses Minimum: Sie sollen den langsamen Schritt in unter 15 Minuten identifizieren können.
Sie brauchen an Tag eins keine perfekten Dashboards. Sie brauchen genug Signale, um zu beantworten:
Setzen Sie sie zusammen ein — jede beantwortet eine andere Frage:
Während eines Vorfalls: Impact mit Metriken bestätigen, Flaschenhals mit Traces finden, mit Logs erklären.
Wählen Sie ein kleines Set von Konventionen und wenden Sie sie überall an:
Standardmäßig strukturierte Logs (meist JSON) mit denselben Schlüsseln überall.
Minimale Felder, die sich sofort auszahlen:
Beginnen Sie mit den vier „goldenen Signalen“ pro Hauptkomponente:
Dann eine kleine Checkliste pro Komponente:
Instrumentieren Sie zuerst Serverseitig, sodass jede eingehende Anfrage einen Trace erzeugen kann.
Ein nützlicher Day‑One‑Trace enthält Spans für:
Machen Sie Spans durch konsistente Attribute durchsuchbar, z. B. (als Template), und einen klaren Abhängigkeitsnamen (, , ).
Ein einfaches, sicheres Default‑Setup ist:
Starten Sie mit höherer Sampling‑Rate, wenn Traffic gering ist, und reduzieren Sie mit wachsendem Volumen.
Ziel ist, Traces nützlich zu halten, ohne Kosten oder Lärm explodieren zu lassen, und trotzdem genug Beispiele des langsamen Pfads zu haben.
Verwenden Sie einen wiederholbaren Ablauf, der Beweise folgt:
Diese Fehler kosten am meisten Zeit (und manchmal Geld):
service_name, environment (z. B. prod/staging) und versionrequest_id, die am Edge erzeugt und über Aufrufe und Jobs propagiert wirdroute, method, status_code und tenant_id (falls multi‑tenant)duration_ms)Ziel ist, dass ein Filter über Services hinweg funktioniert, statt bei jedem Vorfall neu anzufangen.
timestamp, level, service_name, environment, versionrequest_id (und trace_id, falls vorhanden)route, method, status_code, duration_msuser_id oder session_id (stabile ID, keine E‑Mail)Loggen Sie Fehler einmal mit Kontext (Fehlertyp/Code + Nachricht + Abhängigkeitsname). Vermeiden Sie, denselben Stacktrace bei jedem Retry zu wiederholen.
routestatus_codepaymentspostgrescacheSchreiben Sie danach ein fehlendes Signal auf, das die Diagnose schneller gemacht hätte, und fügen Sie es hinzu.
Halten Sie es einfach: stabile IDs, Perzentile, klare Abhängigkeitsnamen und Versions‑Tags überall.