Observability — das Read-Model der Engine über sich selbst
Observability (modules/observability) ist eines der 30 Module — wie
live-ingest erfüllt es eine
architektonische Rolle, statt einen Capability-Slot zu besetzen. Es ist das
Read-Model der Engine über sich selbst: drei schreibgeschützte Oberflächen
unter /v1/m/observability/, die jene Fragen beantworten, die der System-Bereich
der Admin-Konsole darstellt, ohne eine einzige Store-Entität zu besitzen.
Die drei Oberflächen
Abschnitt betitelt „Die drei Oberflächen“| Route | Beantwortet |
|---|---|
GET /ingestion-health | was pro Interop-Standard in die Engine hinein- und aus ihr herausfließt — die Standards, die die Engine fixiert (OTel-GenAI-semconv, OCSF, ASIM, die vereinheitlichten SIEM-Formate, der Ledger-Push, Prometheus-Text, W3C Trace Context), jeweils mit ihrer verifizierten Version |
GET /traces, GET /traces/{id} | was das W3C-korrelierte Ledger über einen Trace aussagt — die Audit-seitige Sicht auf einen verteilten Trace, verknüpft über Trace Context |
GET /attestation | was über die Lieferkette des laufenden Binaries beweisbar wahr ist — die Attestation-Oberfläche, die die Kette zur Verifikation eines Releases speist |
Alle drei sind Lesevorgänge mit modul-gebundenen Berechtigungen; nichts hier verändert irgendetwas.
Warum es überhaupt ein Modul ist
Abschnitt betitelt „Warum es überhaupt ein Modul ist“Die Admin-Konsole benötigte eine maßgebliche Antwort auf die Frage „Was spricht diese Engine tatsächlich, und in welcher fixierten Version?” — und der ehrliche Weg, das bereitzustellen, ist aus der Engine selbst heraus, nicht aus einer Dokumentation, die abdriften kann. Die ingestion-health-Tabelle wird aus denselben Pins generiert, gegen die die Connectors und Exporter kompiliert werden, sodass die Oberfläche mitwandert, wenn sich ein Pin bewegt.
Bounded Context, klar benannt
Abschnitt betitelt „Bounded Context, klar benannt“- Es besitzt keine Store-Entitäten und persistiert nichts — ein reines Read-Model über Substrate, die bereits existieren (die Pins, das Ledger, die Attestation-Evidenz).
- Es ist nicht Modul XXII (Health/SLA), das auf die Zuverlässigkeit der Agenten und MCP-Server des Estates beschränkt ist. Dieses Modul betrifft die Engine.
- Es ist nicht der Metrics-Endpunkt: operative Zeitreihen leben auf
/metrics; dieses Modul liefert strukturierte Antworten, keine Zeitreihen.
Verwandt
Abschnitt betitelt „Verwandt“- Mit Prometheus überwachen — die operativen Metriken und SLOs.
- Events-Referenz — das Bus-Vokabular, über das die ingestion-Tabelle berichtet.
- Ein Release verifizieren — die Lieferketten-Evidenz, die die Attestation-Oberfläche widerspiegelt.