Was sind die vier Golden Signals, und welches würdest du bei einem brandneuen Service zuerst instrumentieren?

Latenz, Traffic, Errors und Saturation. Latenz ist, wie lange Requests brauchen, getrennt nach erfolgreichen und fehlgeschlagenen Aufrufen. Traffic ist die Nachfrage, etwa Requests pro Sekunde. Errors ist die Rate fehlgeschlagener Requests, inklusive derer, die mit 200 und kaputtem Body zurückkommen. Saturation ist, wie voll deine am stärksten begrenzte Ressource ist. Instrumentier zuerst Errors und Latenz, weil sie direkt auf den Schmerz des Users abbilden.

Latenz, Traffic, Errors, Saturation. Bei einem neuen Service würde ich Errors und Latenz zuerst verdrahten, weil das die zwei sind, die ein User spürt, und ich würde dafür sorgen, dass Latenz-Histogramme nach Ergebnis getrennt sind. Das hat uns mal erwischt: Unser p99 hat sich nach einem schlechten Deploy verbessert, und zwar nur, weil ein Teil der Requests in 12ms fehlschlug, statt in 800ms zu gelingen. Traffic kommt als Nächstes, vor allem weil es jedem anderen Signal Kontext gibt und weil du damit einen Abfall auf null siehst, der Alert, den Leute zu schreiben vergessen. Saturation ist das, was wirklich Nachdenken braucht. Bei einer zustandslosen API war es meist unser Datenbank-Connection-Pool und nicht CPU, wir haben also Pool-Wartezeit und belegte Verbindungen exportiert. Generische Node-CPU hat uns nie etwas Nützliches gesagt. Sind die vier oben, ist alles Weitere Feinschliff und kein neues Dashboard.