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>
25 lines
693 B
PHP
25 lines
693 B
PHP
<?php
|
|
|
|
namespace App\Console\Commands;
|
|
|
|
use App\Services\Monitoring\HealthProbe;
|
|
use Illuminate\Console\Command;
|
|
|
|
/**
|
|
* Minütlicher Herzschlag des Schedulers (Monitoring-Plan 1.4). Bleibt er aus,
|
|
* melden `/health` und der Systemstatus den Scheduler als ausgefallen —
|
|
* `onFailure` der einzelnen Tasks greift in diesem Fall nicht mehr.
|
|
*/
|
|
class MonitoringHeartbeat extends Command
|
|
{
|
|
protected $signature = 'monitoring:heartbeat';
|
|
|
|
protected $description = 'Schreibt den Herzschlag des Schedulers (Grundlage für /health und den Systemstatus).';
|
|
|
|
public function handle(HealthProbe $probe): int
|
|
{
|
|
$probe->recordHeartbeat();
|
|
|
|
return self::SUCCESS;
|
|
}
|
|
}
|