Kevin Adametz
05535aac37
Auf Live kamen seit dem 05.10. rund 250 Versuche am Tag aus über 50 Quellen, alle mit unbekannter Adresse — verteiltes Durchprobieren fremder Zugangsdaten, das im Verlauf die relevanten Einträge verdeckte. Neue Tabelle failed_login_tallies (Tag × Einstieg × IP-Hash), model:prune täglich 04:05. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
90 lines
3.4 KiB
PHP
90 lines
3.4 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),
|
||
],
|
||
|
||
/*
|
||
|--------------------------------------------------------------------------
|
||
| Fehlgeschlagene Anmeldungen mit unbekannter Adresse (Nachtrag 1.7)
|
||
|--------------------------------------------------------------------------
|
||
|
|
||
| Werden nicht einzeln im Aktivitäts-Verlauf protokolliert, sondern je Tag,
|
||
| Einstieg und Quelle gezählt (failed_login_tallies). Der Systemstatus
|
||
| warnt ab `warn_per_day` Versuchen am Tag.
|
||
|
|
||
*/
|
||
|
||
'failed_logins' => [
|
||
'retention_days' => (int) env('MONITORING_FAILED_LOGIN_RETENTION_DAYS', 90),
|
||
'warn_per_day' => (int) env('MONITORING_FAILED_LOGIN_WARN_PER_DAY', 1000),
|
||
],
|
||
|
||
'scheduler' => [
|
||
'heartbeat_warn_minutes' => 3,
|
||
'heartbeat_critical_minutes' => 10,
|
||
],
|
||
|
||
];
|