Health Alerts
Jede nicht gecachte Anfrage an Entra ID oder Dataverse meldet ihr Ergebnis an einen kleinen Health-Monitor. Der erste Fehler einer Störungsepisode löst sofort eine E-Mail aus, Wiederholungen hält ein Cooldown zurück, und der erste Erfolg danach sendet eine Wiederherstellungsmeldung. Eine geplante Prüfung zweimal täglich erkennt Probleme, die sonst auf den nächsten Besucher warten würden, allen voran ein abgelaufenes Client Secret.
Was einen Alert auslöst
Fehler werden in vier Klassen eingeteilt. Jede Klasse hat in der E-Mail ihre eigene Erklärung.
| Klasse | Wird erfasst, wenn | Typische Ursache |
|---|---|---|
| auth | Der Token-Endpunkt die Anfrage ablehnt | Abgelaufenes oder rotiertes Client Secret, falsche Client- oder Tenant-ID, gelöschte App-Registrierung |
| network | Der Token-Endpunkt oder die Umgebungs-URL nicht erreichbar ist | DNS oder Firewall auf dem Host, ein Ausfall bei Microsoft, eine falsch geschriebene Umgebungs-URL |
| api | Ein Lesezugriff 401, 403, 408, 429 oder einen 5xx-Status liefert | Anwendungsbenutzer ohne Rolle, entzogene Berechtigungen, Drosselung, ein Dataverse-Vorfall |
| form | Ein Schreibzugriff eines Formulars fehlschlägt, unabhängig vom Statuscode | Fehlende Create- oder Write-Berechtigung, eine Pflichtspalte, die das Formular nicht füllt, ein falsches Entity Set |
Ein 404 beim Aufruf eines Datensatzes ist eine Inhaltsfrage, kein Ausfall, und zählt nicht. Auch Metadaten-Lesezugriffe berühren den Health-Status nie: Sie sind optional und fallen auf Heuristiken zurück. Ein fehlerhafter Metadaten-Endpunkt neben funktionierenden Datenzugriffen kann also nicht abwechselnd Alerts auslösen und wieder aufheben.
Eine E-Mail geht beim ersten Fehler einer Episode hinaus, erneut, wenn sich die Fehlerklasse ändert (zum Beispiel wenn aus einem Netzwerkproblem ein Auth-Problem wird), und erneut nach Ablauf des Cooldowns, solange die Episode andauert. Fehlgeschlagene Formulareinsendungen gelten immer als alertwürdig, weil ein Besucher eine Einsendung verloren hat.
Cooldown
Wiederholte Alerts für eine laufende Episode werden sechs Stunden lang zurückgehalten. Ändern Sie das mit dem Filter wbs_dataverse_connect_alert_cooldown, der Sekunden erhält und zurückgibt:
add_filter('wbs_dataverse_connect_alert_cooldown', function () {
return 2 * HOUR_IN_SECONDS;
});Wiederherstellung
Die erste erfolgreiche Anfrage nach einer Störungsepisode setzt den Status zurück und sendet eine Wiederherstellungs-E-Mail mit dem Beginn der Episode und dem zuletzt erfassten Fehler. Nur Episoden, die gemeldet wurden, erhalten eine Wiederherstellungsmeldung. Ein einzelner Aussetzer unterhalb der Alert-Schwelle bleibt also in beide Richtungen still.
Die geplante Prüfung
Ein WP-Cron-Ereignis läuft zweimal täglich (der erste Lauf eine Stunde nach der Aktivierung). Es verwirft den gecachten Token, fordert mit den gespeicherten Zugangsdaten einen neuen an und ruft WhoAmI auf. Das Ergebnis durchläuft dieselbe Meldekette wie Anfragen von Besuchern. Eine unterbrochene Verbindung meldet sich also innerhalb von Stunden, auch wenn niemand die Seite besucht. Das ist die Antwort auf den klassischen stillen Fehler: ein Client Secret, das auf einer wenig besuchten Seite abgelaufen ist und Wochen später als Formular auffällt, das "nicht funktioniert". Die Prüfung setzt voraus, dass WP-Cron läuft; auf Hosts, die es deaktivieren, rufen Sie wp-cron.php über einen System-Cron auf.
Der Tab "Connection" zeigt den aktuellen Status (OK oder Failing seit wann, mit dem letzten Fehler) und den Zeitpunkt der letzten Prüfung. "Test connection" auf demselben Tab führt denselben Roundtrip bei Bedarf aus.
Empfänger und Einstellungen
Unter Health alerts auf dem Tab "Connection":
- Send alerts: standardmäßig aktiv.
- Alert email: leer bedeutet die Admin-E-Mail-Adresse der Seite.
- Also alert: eine zweite Adresse, zum Beispiel der Partner, der die Integration betreut.
Für alles darüber hinaus ändert der Filter wbs_dataverse_connect_alert_recipients die Liste. Der Versand läuft über wp_mail, daher greift das SMTP-Plugin, das die Seite ohnehin verwendet. Der Betreff lautet [Site name] Dataverse connection problem oder [Site name] Dataverse connection restored.
Die Action health_event
wbs_dataverse_connect_health_event wird bei jedem erfassten Fehler (gemeldet oder nicht) und bei jeder Wiederherstellung ausgelöst, mit der Art und dem gespeicherten Status:
add_action('wbs_dataverse_connect_health_event', function ($kind, $state) {
// $kind: 'failure' or 'recovery'
// $state: state, class, detail, context, since, last_seen, alerted_at, checked_at
if ($kind === 'failure' && $state['class'] === 'auth') {
// open a ticket, page someone, ...
}
}, 10, 2);Das Webhook-Modul hört auf diese Action und macht aus gemeldeten Fehlern health.failure-Nachrichten und aus Wiederherstellungen health.recovery; siehe Webhooks. Der Status wird in der Option wbsdvc_health gespeichert und bei der Deinstallation entfernt.