History

fds2610-bot 55d5c34ca6 Ueberwachte Hosts ueber ein Zahnrad am System-Monitor pflegen (Issue #70 ) Wer einen Server aus der Ping-Ueberwachung nehmen wollte, musste sich bisher auf den Rechner mit check_fds.sh einloggen und die hosts.conf editieren - und die Kachel blieb danach trotzdem im System-Monitor stehen, weil ein einmal gemeldetes System nirgends wieder geloescht werden konnte. Die Liste steht jetzt in der Datenbank und ist ueber ein Zahnrad neben der Ueberschrift "Systeme" pflegbar, analog zum Zahnrad am PO-Platz (Issue #27). Jeder Host gehoert dem OPs-Agenten (Issue #66), der ihn anpingt: API und Ping-Check laufen nicht zwangslaeufig auf demselben Rechner, die API kann die hosts.conf also nicht selbst schreiben. check_fds.sh holt sie stattdessen bei jedem Lauf mit seinem Agenten-Key ab und schreibt daraus die lokale Datei; ist die API nicht erreichbar, pingt es unveraendert nach der zuletzt geschriebenen Liste weiter. Beim ersten Lauf laedt der Check seine bestehende hosts.conf hoch, damit die bereits ueberwachten Server nicht von Hand nachgetragen werden muessen. Dass die API das nur einmal annimmt (Marker in host_config_imports) und "noch nie konfiguriert" per 204 von "im Frontend geleert" per 200 unterscheidet, ist noetig, damit ein Ping-Rechner mit alter lokaler Datei die dort geloeschten Hosts nicht wieder anlegt. Loeschen raeumt mit auf: Ein entfernter Host nimmt seine Kachel mit - beide Ids, denn der status.txt-Import benennt ihn nach dem Hostnamen, die REST-Meldung nach dessen Slug. Kacheln ohne zugehoerigen Host (Selbstmelder oder Reste laengst entfernter Hosts) stehen im selben Dialog unter "Weitere Kacheln im System-Monitor" und sind dort einzeln loeschbar - dafuer gibt es neu DELETE /api/v1/systems/{id}. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015vNjbfr8M3HSfWMee92GTE		2026-09-01 13:14:11 +02:00
..
bin	Neue KPI: offene PRs ueber alle Projekte (Issue #59 )	2026-08-21 11:57:08 +02:00
docker	Hooks-KPI im KPI-Monitor ergaenzen (Issue #38 )	2026-08-04 13:18:05 +02:00
public	Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten	2026-07-27 19:38:52 +02:00
src	Ueberwachte Hosts ueber ein Zahnrad am System-Monitor pflegen (Issue #70 )	2026-09-01 13:14:11 +02:00
tests/Unit	Ueberwachte Hosts ueber ein Zahnrad am System-Monitor pflegen (Issue #70 )	2026-09-01 13:14:11 +02:00
.dockerignore	Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten	2026-07-27 19:38:52 +02:00
composer.json	Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten	2026-07-27 19:38:52 +02:00
composer.lock	composer.lock einchecken	2026-07-27 20:17:18 +02:00
phpunit.xml	Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten	2026-07-27 19:38:52 +02:00
README.md	Codeberg-Sync als Dauerlaeufer statt manuellem Aufruf	2026-07-28 23:29:40 +02:00

README.md

monitor REST-API (Phase 1)

Vanilla-PHP-REST-API (kein Framework, siehe Visualization.md Abschnitt 5) fuer Tickets, Events, Systeme, KPIs und Agenten. Persistenz in SQLite (api/data/monitor.sqlite).

Vollstaendige Endpunkt-Dokumentation: ../API.md.

Entwicklung nur mit Docker (kein lokales PHP/Composer noetig)

Aus dem Repo-Wurzelverzeichnis:

cp .env.example .env   # einmalig, MONITOR_ADMIN_API_KEY anpassen

docker compose up --build       # startet die API auf http://localhost:8080
docker compose run --rm api composer test   # PHPUnit inkl. Coverage
docker compose run --rm api php bin/sync-codeberg.php   # Backlog/Done einmalig ziehen (Debug)

Im laufenden Betrieb wird der Codeberg-Sync nicht manuell angestossen, sondern vom Compose-Service sync alle MONITOR_SYNC_INTERVAL Sekunden ausgefuehrt (siehe ../API.md, Abschnitt "Codeberg-Sync").

Composer-Abhaengigkeiten (nur PHPUnit als Dev-Dependency) werden beim ersten Start automatisch im Container installiert (docker/entrypoint.sh) - auf dem Host ist weder PHP noch Composer noch SQLite erforderlich.