Sammelcommit fuer den ueber mehrere Sitzungen gewachsenen, bisher nicht
eingecheckten Stand. Getrennte Commits waeren ehrlicher gewesen, sind es
nachtraeglich aber nicht mehr: BugRepo, changelog.json und die Doku tragen
Aenderungen aus allen Straengen gleichzeitig, und keine Zwischenstufe waere
lauffaehig.
ROADMAP IM DEPLOYMENTCENTER (2.7.0)
Planungsstand, Reihenfolge und Zustaendigkeit lagen in handgepflegten
Markdown-Dateien neben einem Bugtracker, der genau diese drei Dinge bereits
fuehrt. Zwei Pfleger fuer dasselbe Feld - Drift war eine Frage der Zeit.
Ab jetzt: Zustand im DC, Begruendung in der Datei. Kein Feld hat zwei Pfleger.
- Migration 016: epic, roadmap_rank, target_build, defer_trigger,
doc_anchor, Status "deferred", Tabelle roadmap_epics.
KEINE Roadmap-Tabelle - ein Eintrag ist ein bugtracker_item.
- Zugehoerigkeit ist ein Feld: Ein Item steht auf der Roadmap, wenn es ein
epic hat. Ein zweites Kennzeichen daneben koennte auseinanderlaufen.
- Kennung ist die Item-ID. Handvergebene Kuerzel ("A12") erzeugen die
schlimmste Fehlerart: Beide Seiten stimmig, Verschiedenes gemeint, weil
die Kennung nach einer Loeschung neu vergeben wurde.
- Zurueckstellen verlangt defer_trigger. Ohne benannten Anlass ist ein
Vorhaben nicht zurueckgestellt, sondern vergessen. Die Regel sitzt im
Repository, damit sie auf allen drei Schreibwegen gleich greift.
- Modules/Bugtracker/Roadmap.php, /api/bugtracker/v1/roadmap.php,
WebUI-Modul mit Filtern, cli/roadmap.php --write/--check,
dc_roadmap und dc_roadmap_set im MCP-Adapter.
- cli/roadmap.php --write ERZEUGT den Zustandsteil der Markdown-Datei;
--check prueft nur die Prosa. Was erzeugt wird, kann nicht driften.
- docs/ROADMAP_MIGRATION.md: Uebernahme fuer die anderen Projekte.
TESTINSTANZ UND TESTTOR
- dc-dev.mhdf.de: zweite Installation, eigene DB, eigene Schluessel,
Basic-Auth davor, Rocket.Chat aus.
- 124 Testfaelle in tests/e2e gegen API, Rechte, Migrationen, Sperre.
- scripts/deploy.py bringt vor jedem Upload erst den anstehenden Stand auf
die Testinstanz und laesst dann den Testlauf laufen. Erst bei
Rueckgabewert 0 geht etwas auf die Produktion (--ohne-test als Notausgang).
Andersherum prueft der Lauf aelteren Code als den, der gleich hochgeht.
- tests/ ist aus dem Produktiv-Deploy ausgeschlossen; testctl.php kann
nicht versehentlich auf dc.mhdf.de landen.
- Ein Lauf mit mehr uebersprungenen als geprueften Faellen endet mit
Rueckgabewert 2 statt 0. Nichts ist kaputt, geprueft wurde es aber auch
nicht - der Unterschied darf nicht am Rueckgabewert verschwinden.
SUPERVISOR, PROJEKTLANDSCHAFT, NACHPRUEFUNG (2.6.0/2.6.1)
- Migration 013: projektuebergreifend melden (dev_agent, evidence,
triage_external, affects).
- Migration 014: supervisor_findings, Katalog, fuenf serverseitige
Detektoren im Tick.
- Migration 015: Nachpruefung als Arbeitsschlange statt Benachrichtigung.
- DEV-Lizenzschluessel zur Selbstbedienung, dc-testkit fuer die Test-VM.
- MCP-Adapter: 15 Werkzeuge, ohne Fremdabhaengigkeiten, mit Abgrenzung
von Fremddaten gegen Prompt-Injektion.
BEHOBEN
- observe und status im Supervisor legten den Zustand des Befundes als
"status" in die Antwort. Http::ok() merged ['status' => 'success']
darunter, also gewann der Befundzustand - eine angenommene Meldung kam
als status="open" an. Heisst jetzt finding_status. War Item #59.
Migrationen 013-016 sind auf dem Produktivserver noch NICHT ausgefuehrt.
Ohne sie bricht das WebUI, weil die Roadmap-Ansicht bei jedem Seitenaufruf
gegen bugtracker_items.epic abfragt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
104 lines
4.7 KiB
SQL
104 lines
4.7 KiB
SQL
-- Migration 014: Supervisor-Befunde
|
|
--
|
|
-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
|
|
--
|
|
-- Ein Befund ist keine Fehlermeldung. Er behauptet nicht, dass etwas kaputt
|
|
-- ist, sondern dass etwas ungewoehnlich ist. Die Einstufung trifft die
|
|
-- empfangende Seite, die den Flottenblick hat - deshalb heisst das Feld
|
|
-- severity_hint und nicht severity.
|
|
--
|
|
-- Siehe docs/SUPERVISOR_MCP_DESIGN.md, Abschnitte 1 und 2.
|
|
|
|
CREATE TABLE IF NOT EXISTS supervisor_findings (
|
|
id BIGINT AUTO_INCREMENT PRIMARY KEY,
|
|
project_slug VARCHAR(64) NOT NULL,
|
|
|
|
-- Welche Installation? Bei serverseitigen Detektoren die Quelle des
|
|
-- Monitors, bei clientseitigen die vom Beobachter gemeldete Kennung.
|
|
instance VARCHAR(100) NOT NULL DEFAULT 'default',
|
|
|
|
-- Name aus dem Katalog, Form "familie.sache". Wandert nie mehr; kommt etwas
|
|
-- dazu, bekommt es einen neuen Namen. Nur so bleiben Befunde aus
|
|
-- verschiedenen Projekten vergleichbar.
|
|
detector VARCHAR(64) NOT NULL,
|
|
|
|
-- Worauf bezieht sich der Befund - eine Metrik, ein Jobname, eine
|
|
-- Fehlersignatur, eine Zusicherung.
|
|
subject VARCHAR(190) NOT NULL,
|
|
|
|
-- Kam der Befund von einer Installation oder aus einem Detektorlauf hier?
|
|
-- Serverseitige Detektoren arbeiten auf Daten, die ohnehin hereinkommen,
|
|
-- und brauchen keinen neuen Client.
|
|
origin ENUM('client','server') NOT NULL DEFAULT 'client',
|
|
|
|
severity_hint ENUM('idea','wishlist','low','medium','high','critical') NULL,
|
|
|
|
-- Was wurde gemessen, und wogegen? Bewusst als JSON: jeder Detektor bringt
|
|
-- andere Groessen mit, und eine Spalte je Detektor waere nach dem dritten
|
|
-- unhaltbar.
|
|
observed_json JSON NULL,
|
|
baseline_json JSON NULL,
|
|
|
|
build VARCHAR(64) NULL,
|
|
commit_sha VARCHAR(64) NULL,
|
|
environment ENUM('production','development','staging','testing') NOT NULL DEFAULT 'production',
|
|
|
|
-- open - frisch, ungesichtet
|
|
-- acknowledged- angesehen, kein Handlungsbedarf im Moment
|
|
-- promoted - daraus wurde ein Bugtracker-Item (siehe bug_item_id)
|
|
-- resolved - Ursache behoben
|
|
-- ignored - dauerhaft uninteressant, zaehlt aber weiter hoch
|
|
status ENUM('open','acknowledged','promoted','resolved','ignored')
|
|
NOT NULL DEFAULT 'open',
|
|
bug_item_id BIGINT NULL,
|
|
|
|
occurrence_count INT NOT NULL DEFAULT 1,
|
|
|
|
-- Aus Detektor, Gegenstand und Fassung gebaut, nicht zufaellig: derselbe
|
|
-- Befund darf beliebig oft gemeldet werden, ohne ein Duplikat anzulegen.
|
|
-- Ein Beobachter, der minuetlich nachsieht, wuerde sonst 1.440 Eintraege am
|
|
-- Tag erzeugen.
|
|
client_ref VARCHAR(190) NOT NULL,
|
|
|
|
first_seen_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
|
last_seen_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
|
acknowledged_at DATETIME NULL,
|
|
acknowledged_by VARCHAR(100) NULL,
|
|
|
|
UNIQUE KEY ux_finding (project_slug, client_ref),
|
|
KEY ix_find_detector (detector, status),
|
|
KEY ix_find_project (project_slug, status, last_seen_at),
|
|
KEY ix_find_instance (instance, last_seen_at),
|
|
KEY ix_find_cleanup (last_seen_at)
|
|
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
|
|
|
|
-- ---------------------------------------------------------------------------
|
|
-- Zu welchem Projekt gehoert ein Monitor?
|
|
-- ---------------------------------------------------------------------------
|
|
-- Der Watchdog kannte bisher nur Quelle und Instanz. Fuer den Flottenvergleich
|
|
-- reicht das nicht: verglichen werden darf nur, was vergleichbar ist, und
|
|
-- "Fassung 1.0" zweier verschiedener Produkte hat nichts miteinander zu tun.
|
|
-- Die Kohorte ist deshalb (Projekt, app_version).
|
|
--
|
|
-- Bewusst NICHT vom Agenten gesetzt, sondern administrativ. Sonst braeuchte
|
|
-- diese Etappe einen Rollout neuer Agentenskripte auf jede Maschine - und der
|
|
-- ganze Punkt der serverseitigen Detektoren ist, dass sie auf Daten arbeiten,
|
|
-- die ohnehin schon hereinkommen.
|
|
--
|
|
-- Bleibt das Feld leer, laufen die monitorbezogenen Detektoren trotzdem; ihre
|
|
-- Befunde landen dann unter dem Projekt aus supervisor.default_project.
|
|
-- Flotten- und Regressionsvergleich setzen dagegen eine Zuordnung voraus und
|
|
-- ueberspringen nicht zugeordnete Monitore.
|
|
ALTER TABLE watchdog_monitors
|
|
ADD COLUMN project_slug VARCHAR(64) NULL AFTER group_key;
|
|
|
|
ALTER TABLE watchdog_monitors
|
|
ADD KEY ix_wd_project (project_slug, app_version);
|
|
|
|
-- Taktgeber fuer die serverseitigen Detektoren. Sie haengen im minuetlichen
|
|
-- Cron, sollen aber nicht minuetlich laufen - ein Flottenvergleich alle zehn
|
|
-- Minuten sagt dasselbe wie einer jede Minute und kostet ein Zehntel.
|
|
INSERT INTO watchdog_cron_jobs (name, interval_sec, enabled)
|
|
VALUES ('supervisor_detectors', 600, 1)
|
|
ON DUPLICATE KEY UPDATE interval_sec = VALUES(interval_sec);
|