2 Commits

Include renames

Author	SHA1	Message	Date
bobbanandClaude Sonnet 5	bf7f73f6b6	Import maintenance windows from Uptime Kuma ... New "Import from Uptime Kuma" action on the Maintenance page (operator): pick an Uptime Kuma integration and a duration, and it starts (or extends) a maintenance window here for every server whose address matches a monitor Uptime Kuma currently reports as being in maintenance, reusing the existing monitor-to-server matching from the Uptime Kuma integration itself. Uptime Kuma's metrics endpoint only exposes a monitor's *current* status, not its scheduled start/end time (there's no API for that), so this deliberately doesn't try to mirror Uptime Kuma's own schedule -- it starts a window for the duration you choose, the same bounded/required-end window this feature has always used. Running it again while Kuma is still in maintenance extends the same window rather than stacking a second one; when Kuma later shows nothing in maintenance, already-active windows are left alone rather than force-ended, since ending them isn't something only Uptime Kuma's state should decide. Two Kuma monitors that match the same server are deduped to one window. Monitors with no matching server are reported back by name so nothing is silently missed, and monitors that aren't in maintenance are ignored entirely. The manual "Start maintenance" endpoint's start-or-extend logic (dedupe, pruning old rows, the response shape) is now a shared services/maintenance.ts function instead of living only in that route handler, so the import path can't drift from how a manual window behaves. Likewise the server-matching helper gained a small toMatchableServers() so the existing Uptime Kuma monitors route and this new one build the same match input the same way instead of each parsing server rows on their own. No schema change -- imported windows are ordinary maintenance windows; their Uptime-Kuma origin is only in the reason text ("Imported from Uptime Kuma (<integration>): <monitor>"), visible in the Active table and the audit log like any other window. Verified with 28 backend checks (the refactored manual start/extend flow as a regression check; roles; unknown/wrong-type/disabled integration; validation; nothing-in-maintenance; matching including same-server dedup and unmatched monitors; re-running extends rather than duplicating; windows left alone once Kuma exits maintenance; upstream failure; audit entries) and by driving the real Maintenance page against the real routers in a browser: import, re-import (extends), the nothing-in-maintenance state, and the viewer view (no edit card, active windows still visible). Real dev database mtime untouched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-29 19:11:35 +02:00
bobbanandClaude Sonnet 5	1a2dd19736	Add an Uptime Kuma integration: monitor status and which server each one watches ... New integration, following the existing pattern: config in-app (URL + API key, credentials encrypted at rest), its own Uptime Kuma page, an Integrations list entry, a Dashboard widget, and diagnostic-log/ integration-down-alert coverage for free via the shared withDiagLogging wrapper. Read-only -- no start/stop equivalent exists for a monitor. Uptime Kuma has no conventional REST API (the dashboard talks to it over Socket.IO); researched before writing any code, since guessing wrong here would have cost real time. The one machine-readable, authenticated endpoint that lists every monitor is its Prometheus exporter at GET /metrics, gated by HTTP Basic auth -- an API key as the password with the username left blank on current installs, or the real dashboard login on installs from before the API-key feature existed. This adapter authenticates the same way and parses that endpoint's text-exposition format itself (metrics: monitor_status, monitor_response_time, monitor_cert_days_remaining, monitor_uptime_ratio; labels: monitor_id, monitor_name, monitor_type, monitor_url, monitor_hostname, monitor_port), verified against the documented metric/label set and the actual upstream source (server/prometheus.js). A malformed line is skipped rather than failing the whole scrape. "What server is being monitored for what": each monitor's target (an IP for TCP checks, or the hostname out of the URL for HTTP/keyword checks) is matched against your servers' own IPs and hostnames -- reusing the same kind of match already used in the consistency report -- and linked to that server's page. Monitors with no single network target (groups, push monitors, DNS/keyword checks with a complex URL) are left unmatched rather than guessed at. Uptime Kuma's tags aren't read, since the Prometheus endpoint doesn't reliably distinguish a tag label from any other label it might add later. The username field is the first genuinely optional integration config field this app has had; IntegrationField gained an `optional` flag (server validation and both the add/edit web forms honor it) rather than special-casing Uptime Kuma. Verified with 48 backend checks (Prometheus text parsing including escaped quotes, decimals, negative numbers, and malformed lines; TCP vs. HTTP target/port extraction; every documented status code; server matching by IP, hostname, and short name, including no-match cases; the route's real HTTP round trip against a fake Uptime Kuma server, wrong credentials, upstream failures, roles, wrong/disabled/missing integration, diagnostic-log entries; the optional-field validation rule) and by driving the real page and the real Dashboard widget in a browser against the real routers, including CSV export and column sorting. Real dev database mtime untouched. Not verified: a real Uptime Kuma instance. Everything here was checked against Uptime Kuma's documented metric format, its actual upstream source, and a fake server built to match both -- not against a live installation. If your instance's /metrics output differs from what's documented (older version, unusual monitor types), the parser should degrade to an empty or partial monitor list rather than error, but that degradation itself hasn't been observed against the real thing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-29 18:50:27 +02:00