Fehlerbehebung

Häufige Fehlerbilder und was dagegen hilft. Wenn Sie auf eines stoßen, das hier nicht steht, halten Sie die Ausgabe von /health/detailed sowie die letzten 200 Protokollzeilen fest und eröffnen ein Support-Ticket.

Die Anwendung startet nicht

`SqlException (53): A network-related or instance-specific error occurred…`

Die Anwendung erreicht den Überwachungs-SQL-Server nicht. Prüfen Sie:

ConnectionStrings:DefaultConnection ist korrekt.
Der SQL Server ist vom Rechner aus erreichbar (Test-NetConnection -ComputerName <db> -Port 1433).
TLS: Die Verbindungszeichenfolge enthält TrustServerCertificate=true oder Encrypt=false, falls die Datenbank kein vertrauenswürdiges Zertifikat besitzt.

`License: Missing — license.lic not found`

appsettings.json:Licensing:LicenseFilePath zeigt auf eine Datei, die nicht existiert. Siehe Lizenz. Die Anwendung startet weiterhin, jedoch im Nur-Lese-Modus.

Migrationsfehler beim Start

Microsoft.EntityFrameworkCore.DbUpdateException: ... INSERT statement conflicted with the FOREIGN KEY constraint

Sie aktualisieren über eine destruktive Migration hinweg ohne sauberen Ausgangsstand. Halten Sie die Anwendung an, spielen Sie die Datenbank vom Stand vor der Aktualisierung zurück und wenden Sie sich an den Support — nicht immer wieder neu starten in der Hoffnung, dass es sich von selbst löst.

Alle Server erscheinen als „Offline“ bzw. „Nicht erreichbar“

Nach einer Wiederherstellung aus der Sicherung

Höchstwahrscheinlich verwendet der wiederhergestellte Rechner nicht denselben Encryption:Key wie der, unter dem die Sicherung geschrieben wurde, sodass die Verbindungszeichenfolgen nicht entschlüsselt werden können. Prüfen Sie appsettings.json auf beiden Rechnern: Entweder setzen beide denselben Schlüssel, oder keiner setzt einen (dann greift der eingebaute Standard). Das Startprotokoll nennt jede Zeile, die sich nicht entschlüsseln ließ. Siehe Sicherung & Wiederherstellung.

Der Verlust des DataProtection-Schlüsselordners verursacht das nicht — er meldet lediglich die Benutzer ab.

Nachdem es zuvor funktioniert hat

Verbindung vom Anwendungsrechner aus testen:

Test-NetConnection -ComputerName <monitored-server> -Port 1433

Ist der Server erreichbar, melden Sie sich auf dem überwachten Server an und prüfen, ob das Überwachungskonto noch VIEW SERVER STATE besitzt. Berechtigungen werden bei Patches gelegentlich neu aufgebaut.

Index Health zeigt nichts, oder jede Zahl ist ein Strich

/performance/index-health liest gespeicherte Scan-Läufe. Eine leere Seite bedeutet also, dass der letzte Lauf nichts gefunden hat oder nicht nachsehen konnte. Das ist ein Unterschied, und die Seite macht ihn sichtbar: Ein Lauf, der keine einzige Datenbank lesen konnte, zeigt — in den Kennzahlenkacheln statt 0, dazu einen Hinweisbalken mit jeder übersprungenen Datenbank samt Grund. Sehen Sie zuerst dort nach, dann im Protokoll (Skipped DB … Cause: …).

Drei Ursachen decken nahezu alle Fälle ab:

Grund im Hinweisbalken	Was er bedeutet	Abhilfe
`SQL error 300: … VIEW SERVER PERFORMANCE STATE …`	SQL Server 2022+ hat `VIEW SERVER STATE` aufgeteilt; die Anmeldung besitzt nur die alte Berechtigung.	`GRANT VIEW SERVER PERFORMANCE STATE TO [login]` — siehe `deployment.md`.
`Permission denied` (nach wenigen Millisekunden)	Die Anmeldung hat keinen Benutzer in dieser Datenbank, `USE [db]` scheitert sofort.	`CREATE USER … FOR LOGIN …` in dieser Datenbank, dazu `VIEW DATABASE (PERFORMANCE) STATE`.
`Timeout` (~300 000 ms)	`dm_db_index_physical_stats` wurde nicht innerhalb des Fünf-Minuten-Budgets je Datenbank fertig. Bei sehr großen Datenbanken normal.	Diese Datenbank vom Scan ausnehmen oder in einem ruhigen Zeitfenster scannen.

Beachten Sie: 0 % Fragmentierung ist ein völlig normaler Wert — ein frisch neu erstellter oder reorganisierter Index meldet genau das. Eine Seite voller Striche bedeutet „nicht gescannt“; eine Seite voller 0,0 %-Zeilen bedeutet „gescannt und gesund“.

Die Fehlerprotokollseite meldet „Permission denied“

/error-log ruft sys.xp_readerrorlog und sys.xp_enumerrorlogs auf, und beide sind von VIEW SERVER STATE nicht abgedeckt. Sie liegen in master, die Anmeldung braucht dort also einen Benutzer, damit die Berechtigungen landen können — ein GRANT allein schlägt fehl, wenn dieser Benutzer nicht existiert:

USE master;
CREATE USER [monitoring_login] FOR LOGIN [monitoring_login];
GRANT EXECUTE ON sys.xp_readerrorlog  TO [monitoring_login];
GRANT EXECUTE ON sys.xp_enumerrorlogs TO [monitoring_login];

Lädt das Protokoll selbst, bietet die Datei-Auswahl aber nur „Aktuell“ an, fehlt die zweite Berechtigung.

Greifen Sie nicht zu ALTER SERVER ROLE securityadmin ADD MEMBER, sofern Sie dem Konto nicht zugestehen wollen, Anmeldungen anzulegen und Kennwörter zurückzusetzen. Dieser Rat kursiert, weil die Hülle sp_readerrorlog die Rolle benötigt; der Monitor ruft genau deshalb die darunterliegende erweiterte Prozedur auf.

Bei Azure SQL Database meldet die Seite, dass es kein Protokoll auf Instanzebene gibt, statt einen Fehler anzuzeigen — diese Plattform hat tatsächlich keines. Managed Instance funktioniert normal.

Ist die Seite eher langsam als leer, grenzen Sie den Zeitraum ein oder ergänzen einen Suchbegriff: Beides wird innerhalb von SQL Server angewendet, eine engere Abfrage leistet also tatsächlich weniger Arbeit. Ein Standard-Fehlerprotokoll auf einer ausgelasteten Instanz ist schnell zweistellig megabytegroß.

Benachrichtigungen werden nicht ausgelöst

Der Alarm ist im Dashboard „aktiv“, aber es kam keine E-Mail

Der Reihe nach prüfen:

Sind Kanäle an der Regel hinterlegt? /Settings/Alerts → Regel bearbeiten → „Benachrichtigungskanäle“ — ist das Feld leer, greift die globale Zuordnung nach Schweregrad. Unter /Settings/Notifications → Schweregrad-Zuordnung prüfen, ob für diesen Schweregrad mindestens ein Kanal angehakt ist.
Ist der Kanal tatsächlich eingerichtet? /Settings/Notifications → für jeden Kanal, auf den die Regel verweist, „Test senden“ anklicken. Der Test muss erfolgreich sein, bevor echte Alarme funktionieren.
Ist eine Stummschaltung aktiv? /settings/silences — trifft eine Stummschaltung zu (Server × Regel), wird die Auslösung stillschweigend unterdrückt. Achten Sie auf den Protokolleintrag der Stufe Info „Alert suppressed by maintenance window“.

Die Test-E-Mail scheitert mit „Authentication required“

In Office-365-Mandanten ist SMTP AUTH zunehmend abgeschaltet. Aktivieren Sie SMTP AUTH für das Überwachungspostfach wieder, oder wechseln Sie auf den Weg über die Graph-API: /Settings/Notifications → E-Mail → Anbieter = „Office 365 / Graph API“ → Mandanten-ID, Client-ID, Clientgeheimnis und Absenderpostfach eintragen.

PagerDuty verwirft Ereignisse stillschweigend

Prüfen Sie, ob der Routing-Key zu Ihrer Events-API-v2-Integration passt. Falls Sie vermuten, dass der Aufruf den Rechner gar nicht verlässt: Sehen Sie im Protokoll rund um die Alarmauslösung nach. Ein erfolgreicher Aufruf protokolliert PagerDuty event accepted for dedup_key {key}. Fehler protokollieren den HTTP-Status und den Antwortkörper.

Zwei-Faktor-Anmeldung: Benutzer ausgesperrt

Ein Benutzer hat seine Authenticator-App verloren. In der aktuellen Oberfläche gibt es dafür keine Selbstbedienung — ein Administrator muss die Zwei-Faktor-Anmeldung für dieses Konto zurücksetzen.

Behelf, solange es keine Oberfläche dafür gibt: die Zwei-Faktor-Anmeldung direkt am Benutzerdatensatz in der Datenbank abschalten und den Benutzer bei der nächsten Anmeldung neu einrichten lassen.

UPDATE AspNetUsers SET TwoFactorEnabled = 0 WHERE UserName = 'alice';

Halten Sie das von Hand im Prüfprotokoll fest (der Eingriff umgeht die Protokollierung der Anwendung).

Das Dashboard ist langsam oder träge

Die Spalte „Disk“ in der Zustandsmatrix zeigt `—`

Der überwachte Server stellt sys.dm_os_volume_stats nicht bereit (Verhalten von Azure SQL Database, oder es fehlt VIEW SERVER STATE). Angaben zum freien Speicherplatz sind nicht verfügbar; der Rest der Matrix ist davon unberührt.

Das gesamte Dashboard braucht Sekunden zum Aufbau

Vermutlich holt der InfrastructureSnapshotService Daten von einem langsamen oder nicht erreichbaren überwachten Server, und der Zyklus läuft in ein Zeitlimit. Suchen Sie im Protokoll nach Einträgen Snapshot pipeline failed: …, die einen bestimmten Server nennen. Deaktivieren Sie diesen Server vorübergehend unter /Servers.

Auf jeder Serverkarte steht „Veraltet“

Der Hintergrunddienst DashboardRefreshService bringt keine Zyklen zu Ende. Suchen Sie im Protokoll nach Ausnahmen aus ProbeServerAsync. Häufige Ursache: Alle überwachten Server verwenden dieselben Zugangsdaten, und diese sind abgelaufen.

Das Protokoll ist zu gesprächig

Die Standardstufe ist Information. Zum Beruhigen:

// appsettings.json
{
  "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "SqlServerHealthMonitor": "Information"
    }
  }
}

Damit bleibt unser Code auf Stufe Info, während das Geplauder des Frameworks unterdrückt wird. Um in ein bestimmtes Teilsystem tiefer hineinzusehen, heben Sie dessen Namensraum auf Debug an (etwa "SqlServerHealthMonitor.Services.AlertingService": "Debug").

Endpunkte für Zustandsprüfungen

/health — ein einzelnes Wort, Healthy oder Unhealthy, für Lastverteiler-Prüfungen
/health/detailed — JSON mit dem Status je Prüfung, nützlich für Support-Tickets

Beide Endpunkte erfordern keine Anmeldung.