01 · Problem
Wofür braucht man das?
Querschnittliche Telemetrie soll ergänzt werden, ohne in jede Geschäftsoperation denselben Messcode zu kopieren.
02 · Denkmodell
Das mentale Modell
Ein Wrapper legt sich um die Originaloperation und aktualisiert eine einmalig registrierte Metrik; Typ, Labels und beobachteter Wert sind explizite Konfiguration.
Vier Legacy-Decorators werden exportiert, erzeugen Metriken aber bei jedem Zugriff neu. Histogram und Summary werden nie observe't, Labelwerte fehlen und Property-State wird zwischen Instanzen geteilt.
03 · Kontrollfluss
Was passiert in welcher Reihenfolge?
- Metrikkonfiguration validieren und über einen stabilen Namen einmalig registrieren.
- Originalmethode unter Erhalt von this und Argumenten aufrufen.
- Calls, Wert, Dauer oder Fehler mit passenden Labels beobachten.
- Sync- und Async-Ergebnis unverändert an den Aufrufer zurückgeben.
04 · Bauteile
Die entscheidenden Verträge
PromCounter / PromGauge
Legacy-Decorators für Zähler und veränderliche Messwerte.
PromHistogram / PromSummary
Exportiert, aber im vorhandenen trackMetric ohne observe-Pfad.
TrackOption.Calls / Value
Wählt Aufrufzählung oder Messung des Rückgabewerts.
IMetricConfig
Verbindet Metriktyp, Prometheus-Konfiguration und Track-Modus.
05 · Build it yourself
Selbst implementieren
Beginne mit einer normalen Wrapperfunktion; Decorator-Syntax kann später dieselbe getestete Instrumentierung aufrufen.
- Definiere eine minimale Metrikschnittstelle und eine Registry pro Prozess.
- Cache Metriken anhand Name plus Typ statt sie pro Invocation zu erzeugen.
- Erfasse Promise-Erfolg und -Fehler erst nach Settlement.
type Counter = { inc(labels?: Record<string, string>): void };
function countCalls<A extends unknown[], R>(
counter: Counter,
run: (...args: A) => R,
) {
return function (this: unknown, ...args: A): R {
counter.inc();
return run.apply(this, args);
};
}06 · Verifizieren
Was du testen solltest
- Mehrere Aufrufe nutzen dieselbe registrierte Metrik und erhöhen sie exakt einmal je Call.
- this, Argumente, Rückgabewert und geworfener Fehler bleiben unverändert.
- Async-Dauer und Rejection werden erst beim Settlement mit korrekten Labels erfasst.
07 · Grenzen
Kompromisse und Stolperfallen
- Decorators reduzieren Boilerplate, verstecken Observability aber im Metaprogramming.
- Hohe Label-Kardinalität kann Prometheus-Speicher und Abfragen massiv belasten.
- Property-Decorators sind bei instanzlokalem State besonders fehleranfällig.
Metriken mit demselben Namen dürfen in prom-client nicht bei jedem Aufruf neu registriert werden. Histogram und Summary benötigen observe statt inc oder set.
08 · Weiterdenken