# Observability für PROCUREX

## Vorhandener Anwendungsanschluss

`procurex-app` stellt über Spring Boot Actuator die Endpunkte `/actuator/health`,
`/actuator/health/liveness`, `/actuator/health/readiness` und `/actuator/prometheus` bereit.
Prometheus kann damit Metriken des Backends scrapen.

## Repository-Artefakte

- `observability/prometheus/procurex-alerts.yml`: Regeln für Backend-Ausfall, 5xx-Fehlerrate und
  p95-Latenz.
- `observability/grafana/procurex-overview.json`: minimales Dashboard für Request-Rate,
  5xx-Fehler und p95-Latenz.
- `docs/runbooks/incident.md`: Vorgehen bei Störungen.

## Einbindung in enterprise-infrastructure

**Umsetzungsstatus: angebunden und verifiziert (29.08.2026).** Die zentrale Prometheus-/Grafana-
Installation gehört zur externen `enterprise-infrastructure` und wird nicht durch das PROCUREX-Compose-File
dupliziert; PROCUREX ergänzt dort nur den in `shared/enterprise-infrastructure/prometheus/prometheus.yml`
dokumentierten Job-Eintrag (`job_name: "procurex-app"`, Target `procurex-app:8081`, genau das im
Kommentar dieser Datei vorgesehene Muster für angeschlossene Projekte).

Smoke-Test durchgeführt: `procurex-app` lief über `podman compose up -d` (Podman als lokaler
Container-Workflow, siehe `shared/enterprise-infrastructure/README.md`), Prometheus-Target `procurex-app` stand auf
`up == 1`, und `http_server_requests_seconds_count{job="procurex-app"}` lieferte nach den
E2E-/k6-Läufen 24 Metrikserien — reale, keine synthetischen Werte. Das vorbereitete Dashboard
(`observability/grafana/procurex-overview.json`) wurde per Grafana-API importiert
(`/d/afwlw2y1w0buoc/procurex-overview`) und zeigt Request-Rate, 5xx-Fehler und p95-Latenz aus
genau diesen Metriken.

Die Alert-Regeln (`observability/prometheus/procurex-alerts.yml`) sind weiterhin **nicht**
geladen — `shared/enterprise-infrastructure/docker-compose.yml` mountet aktuell nur `prometheus.yml` selbst, kein
separates Regelverzeichnis. Ein Laden würde eine zusätzliche Volume-Ergänzung in der geteilten,
projektübergreifenden `shared/enterprise-infrastructure/docker-compose.yml` erfordern; das wurde bewusst nicht
vorgenommen, um eine für mehrere Lernprojekte gemeinsam genutzte Infrastrukturdatei nicht
strukturell zu verändern. Ein Test-Alert wurde entsprechend ebenfalls nicht ausgelöst.

Zentrales Logging und Distributed Tracing sind in diesem Lernstand noch nicht vollständig
automatisiert. Container-Logs können über die vorhandene Plattform gesammelt werden, aber eine
versionierte Loki-/ELK-Pipeline und Trace-Korrelation sind noch ein eigener Ausbaupunkt.