Kevin Adametz
d884eb7482
- GlitchTip über die Sentry-SDKs; Datenschutzfilter (nur User-ID, keine
Request-Bodys, Tokens aus URL/Query/Referer, E-Mails aus Meldungen).
Browser-SDK erst beim ersten Fehler nachgeladen.
- ReportErrorSignals: tote interne Links (404 mit eigenem Referrer), 403/429
für Angemeldete, 419 als gedrosselte Warnung.
- /health (Bearer-Token): DB, Cache, Queue-Rückstau, Scheduler-Herzschlag,
Plattenplatz → 200/503; Scheduler und Plattenplatz auch im Systemstatus.
- OperationalAlert zusätzlich per ntfy (JSON-POST), unabhängig von der Mail.
- Verlauf: login_failed (Grund unbekannt/kein Passwort/falsch),
login_lockout, two_factor_failed; IP nur als gekürzter HMAC.
- Umami: Kundenbereich mit eigenem Schalter und identify('user-<id>'),
nie im Admin/bei Impersonation; Query-Filter auch auf den Webseiten
(signierte Links gingen bisher an Umami).
- queue:prune-failed nach 30 Tagen.
- Versionsnummer: config('app.version') aus APP_VERSION oder Datei RELEASE
(git describe --tags), in GlitchTip, /health, Systemstatus, artisan about.
Plan: dev/betrieb/monitoring-plan.md (Entscheidungen M1–M9).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
74 lines
2.8 KiB
PHP
74 lines
2.8 KiB
PHP
<?php
|
||
|
||
return [
|
||
|
||
/*
|
||
|--------------------------------------------------------------------------
|
||
| Betriebs-Alerts (R5.3)
|
||
|--------------------------------------------------------------------------
|
||
|
|
||
| Fehlgeschlagene Scheduler-Tasks und Queue-Jobs werden immer als
|
||
| `critical` ins Log geschrieben (rotierter `daily`-Channel) und – wenn
|
||
| aktiviert und eine Adresse gesetzt ist – zusätzlich per Best-Effort-Mail
|
||
| gemeldet. Die Mail ist bewusst nur die zweite Ebene: schlägt der Versand
|
||
| fehl, bleibt der Log-Eintrag als verlässliche Spur bestehen.
|
||
|
|
||
*/
|
||
|
||
'alerts' => [
|
||
'enabled' => (bool) env('MONITORING_ALERTS_ENABLED', true),
|
||
|
||
// Ops-Postfach. Fällt auf die zentrale Rechts-/Betreiber-Adresse
|
||
// zurück, solange kein dediziertes Monitoring-Postfach gesetzt ist.
|
||
'mail_to' => env('MONITORING_ALERT_EMAIL', env('LEGAL_CONTACT_EMAIL', 'info@pressekonto.com')),
|
||
|
||
// Zweiter Alarmweg (Monitoring-Plan M3): Push über ntfy, JSON-POST
|
||
// an die Basis-URL. Ohne URL oder Topic aus.
|
||
'ntfy' => [
|
||
'url' => env('MONITORING_NTFY_URL'),
|
||
'topic' => env('MONITORING_NTFY_TOPIC'),
|
||
'token' => env('MONITORING_NTFY_TOKEN'),
|
||
'priority' => (int) env('MONITORING_NTFY_PRIORITY', 4),
|
||
],
|
||
],
|
||
|
||
/*
|
||
|--------------------------------------------------------------------------
|
||
| Browserfehler (Monitoring-Plan 1.2)
|
||
|--------------------------------------------------------------------------
|
||
|
|
||
| Eigenes GlitchTip-Projekt für JavaScript-Fehler. Die DSN ist öffentlich
|
||
| (steht im HTML), sie erlaubt nur das Einliefern von Ereignissen. Ohne
|
||
| DSN wird kein Skript eingebunden.
|
||
|
|
||
*/
|
||
|
||
'browser' => [
|
||
'dsn' => env('SENTRY_BROWSER_DSN'),
|
||
'sample_rate' => (float) env('SENTRY_BROWSER_SAMPLE_RATE', 1.0),
|
||
],
|
||
|
||
/*
|
||
|--------------------------------------------------------------------------
|
||
| Health-Endpunkt und Scheduler-Herzschlag (Monitoring-Plan 1.4, 1.5)
|
||
|--------------------------------------------------------------------------
|
||
|
|
||
| `/health` antwortet nur mit gültigem Token (Bearer-Header oder
|
||
| `?token=`); ohne konfiguriertes Token gibt es den Endpunkt nicht (404).
|
||
| Der Scheduler schreibt jede Minute einen Herzschlag; bleibt er aus, ist
|
||
| der Cron-Eintrag weg oder der Server hängt.
|
||
|
|
||
*/
|
||
|
||
'health' => [
|
||
'token' => env('MONITORING_HEALTH_TOKEN'),
|
||
'queue_backlog_critical_seconds' => (int) env('MONITORING_QUEUE_BACKLOG_SECONDS', 300),
|
||
'disk_min_free_percent' => (float) env('MONITORING_DISK_MIN_FREE_PERCENT', 10),
|
||
],
|
||
|
||
'scheduler' => [
|
||
'heartbeat_warn_minutes' => 3,
|
||
'heartbeat_critical_minutes' => 10,
|
||
],
|
||
|
||
];
|