Wie sieht gute Observability für einen Service aus, den du verantwortest?

Du solltest Fragen beantworten können, die du nicht vorhergesehen hast. Das heißt strukturierte Logs mit einer Trace-ID in jeder Zeile, Metriken für Rate, Errors und Duration plus Sättigung deiner Schlüsselressourcen, und Distributed Traces, die einem Request über Services hinweg folgen. Alerts feuern auf nutzersichtbare Symptome, gebunden an deine Service Level Objectives, Dashboards starten bei der Kundenerfahrung, und alle Signale teilen konsistente Labels, damit du zwischen ihnen wechseln kannst.

Mein Test ist, ob ich eine Frage beantworten kann, an die beim Bau des Service niemand gedacht hat, etwa warum Requests nur für einen Kunden auf einem Endpoint langsam sind. Dafür müssen die drei Signale zusammenhängen. Jede Logzeile ist strukturiert und trägt die Trace-ID, sodass ich von einem langsamen Trace direkt zu den Logs dieses Requests springen kann, statt nach Zeitstempel zu grepen. Metriken decken Rate, Errors und Duration jedes Endpoints als Perzentile statt als Mittelwerte ab, plus die Sättigung der Dinge, die tatsächlich ausgehen: Connection Pools, Queue-Tiefe, Disk. Traces sind gesampelt, aber ich behalte immer die Errors und den langsamen Tail, denn der Durchschnitts-Request bringt mir nichts bei. Alerting ist der Teil, den viele falsch machen: Ich alarmiere auf Symptome, die Kunden spüren, gebunden an das Objective, nicht darauf, dass die CPU bei achtzig Prozent steht. Und ich achte auf Kosten, denn eine User-ID in ein Metrik-Label zu packen ist der Weg, aus einer Rechnung von zweihundert über Nacht sechstausend zu machen. Detail auf Nutzerebene gehört in Traces und Logs.