Überwachung: Health, Protokolle, Auswertung

Der Health-Endpunkt

GET /health ist der Endpunkt für Lebens- und Bereitschaftsprüfung: öffentlich, ohne Schlüssel, ohne Kontingentverbrauch — und damit der richtige Prüfpunkt für einen Dienst- oder Container-Healthcheck.

{ "status": "Healthy", "schemas": "ok", "db": "ok", "version": "1.0.42", "buildDate": "…" }

Antwort	Bedeutung
`200` + `"Healthy"`	Dienst oben, beide Prüfungen bestanden
`503` + `"Degraded"`	mindestens eine Prüfung fehlgeschlagen; `schemas` bzw. `db` steht dann auf `"missing"`

Was genau geprüft wird — und warum nur zwei Dinge

Jedes der beiden, weil sein Ausfall still wäre:

Feld	Prüfung	Warum
`schemas`	liegt die EN-16931-Codelisten-Datei im Ausgabeverzeichnis?	Fehlt sie, prüfen die Codelisten still „grün“ — eine ungeprüfte Rechnung sähe aus wie eine geprüfte
`db`	ist die SQLite vorhanden, lesbar und migriert?	deckt auf Linux zugleich die nativen Bibliotheken mit ab

Protokolle

Ort	Inhalt
`<Zielverzeichnis>\logs\invoice-api-JJJJMMTT.log`	Anwendungsprotokoll, Tageswechsel, 30 Dateien Aufbewahrung
`%TEMP%\Setup Log*.txt`	Protokoll des Installers
Dienststeuerung	`sc query Invoiceflair`, `sc stop …`, `sc start …`

Die Mindeststufe ist Information; die Framework-Kategorien sind gedämpft.

Nutzungsauswertung

Invoiceflair.Api.exe usage --days 7

Beantwortet die Betriebsfragen aus dem Protokoll: wie oft welches Werkzeug lief, wie viele Aufrufe fehlschlugen, wie viele Adressen beteiligt waren, welcher API-Schlüssel wie viel verbraucht hat.

Was überwacht gehört

Prüfung	Wie
Dienst läuft	`/health` gegen den HTTP-Port und `localhost` — nicht über den Proxy, sonst wäre ein frisches Zertifikat der erste Stolperstein
Platz im Datenverzeichnis	Archiv und Protokoll wachsen
Protokoll auf Warnungen	besonders die Warnung über eine fehlende öffentliche Adresse hinter einem Proxy