Runtime-Signale
Monitoring-Alerts und ML-Release-Ereignisse automatisch als Nachweise übernehmen.
Post-Market-Monitoring scheitert selten am Willen, sondern an der Übertragung: Der Alert liegt in Grafana, das Release in GitHub Actions, das Modell in MLflow – und die Compliance-Akte bleibt leer. Die Ereignis-Übernahme schließt diese Lücke. Sie richten je KI-System ein Quellprofil ein, tragen den Endpunkt in Ihrem bestehenden Werkzeug ein, und ab dann entstehen Nachweise dort, wo ohnehin gearbeitet wird.
Auf einen Blick
- Enthalten ab
- Professional (Teil von Incident Management)
- Wo in der App
- KI-System öffnen → Integrationen / Ereignisse
- Ergebnis
- Automatisch erzeugte Monitoring-Signale, Modellregister- und Release-Einträge
- API
- /api/v1/ingestion
Verfügbare Konnektoren
Sechs Konnektoren, drei Ergebnistypen. Der Katalog ist über die API abrufbar, sodass Sie die Endpunkte nicht abtippen müssen.
| Quelle | Endpunkt | Erzeugt |
|---|---|---|
| MLflow | /ingestion/connectors/mlflow/webhook | Modellregister-Eintrag |
| GitHub Actions | /ingestion/connectors/github-actions/webhook | Release-Ereignis |
| GitLab CI | /ingestion/connectors/gitlab-ci/webhook | Release-Ereignis |
| Grafana | /ingestion/connectors/grafana/alerts | Monitoring-Signal |
| Prometheus | /ingestion/connectors/prometheus/alerts | Monitoring-Signal |
| Datadog | /ingestion/connectors/datadog/events | Monitoring-Signal |
Einrichtung – Schritt für Schritt
- 1KI-System öffnen, dem die Signale zugeordnet werden sollen. Jedes Quellprofil gehört zu genau einem System.
- 2Quellprofil anlegen: Quelltyp (z. B. GRAFANA), Bezeichnung des Quellsystems, sowie optional Standardschwere und Standardstatus für erzeugte Einträge.
- 3Gemeinsames Geheimnis („Shared Secret") setzen und den Namen des Signatur-Headers festlegen. Ohne Geheimnis wird die Signatur nicht geprüft – für produktive Quellen sollten Sie eines setzen.
- 4Den Endpunkt aus der Tabelle oben in Grafana, MLflow, GitHub Actions o. ä. als Webhook-Ziel eintragen und die Signatur dort mit demselben Geheimnis konfigurieren.
- 5Ein Testereignis auslösen und in der Ereignisübersicht prüfen, ob es als „verarbeitet" ankommt.
Status eines Ereignisses
Jedes eingehende Ereignis wird protokolliert – auch, wenn es scheitert. Das ist der Unterschied zwischen einer Integration, der man vertrauen kann, und einer, die still ausfällt.
| Status | Bedeutung |
|---|---|
| RECEIVED | Angenommen, Verarbeitung läuft. |
| PROCESSED | Verarbeitet; der erzeugte Eintrag ist mit dem Ereignis verknüpft und aus der Übersicht direkt erreichbar. |
| DUPLICATE | Dieselbe externe Ereignis-ID kam erneut an. Es wird kein zweiter Eintrag erzeugt – Doppelzustellungen Ihres Werkzeugs sind damit unschädlich. |
| FAILED | Verarbeitung fehlgeschlagen, der Fehlertext wird mitgespeichert. Bis zu drei Versuche. |
| DEAD_LETTER | Nach drei Fehlversuchen endgültig liegengeblieben. Diese Einträge sind Ihre Arbeitsliste. |
Was die Übernahme sicher macht
- HMAC-SHA256-Signaturprüfung gegen das hinterlegte Geheimnis. Der Header-Name ist frei wählbar; ohne Angabe wird x-simpleact-signature erwartet.
- Doppelerkennung über die externe Ereignis-ID – ein erneut zugestelltes Ereignis erzeugt keinen zweiten Nachweis.
- Wiederholung auf Knopfdruck: Ein fehlgeschlagenes Ereignis lässt sich erneut verarbeiten. Bereits verarbeitete oder als Duplikat erkannte Ereignisse werden dabei abgelehnt, statt einen zweiten Eintrag zu erzeugen.
- Das gemeinsame Geheimnis wird nie zurückgegeben. Die API meldet nur, ob eines gesetzt ist.
- Jede Übernahme landet im Audit-Trail – erkennbar als maschinelle Änderung, nicht als Handlung einer Person.
Auch ohne Konnektor nutzbar
Neben den sechs Konnektoren gibt es generische Endpunkte für Monitoring-Signale, Modellregister-Einträge und Release-Ereignisse. Wenn Ihr Werkzeug nicht in der Liste steht, senden Sie direkt an diese Endpunkte – Sie brauchen keinen fertigen Konnektor, nur ein System, das einen HTTP-Aufruf absetzen kann.