Fehlerprotokoll

Die Seite Fehlerprotokoll liest das SQL Server-Fehlerprotokoll — und auf derselben Seite das SQL Server Agent-Protokoll — direkt von der überwachten Instanz. Es wird nichts in die Monitoring-Datenbank kopiert: SQL Server verwaltet und rotiert diese Dateien bereits selbst, eine zweite Kopie wäre nur eine zweite Sache, die abweichen kann.

Was die Stufen bedeuten

Jede Zeile wird beim Lesen eingestuft, damit Sie zum Wesentlichen springen können statt zu scrollen. Die Einstufung nutzt zwei Signale und nimmt jeweils das schwerwiegendere.

Der Schweregrad allein wäre irreführend: Eine fehlgeschlagene Sicherung wird mit Schweregrad 16 protokolliert, was die Schweregradtabelle als bloße Warnung einstuft. Daher wird auch der Meldungstext ausgewertet — und das schwerwiegendere der beiden Signale gilt.

Große Protokolle effizient lesen

Zeitraum und beide Suchfelder werden innerhalb von SQL Server angewendet, nicht im Browser. Eine engere Abfrage ist also tatsächlich günstiger und überträgt den Rest der Datei gar nicht erst. Die beiden Suchfelder werden UND-verknüpft: Login failed zusammen mit sa findet nur fehlgeschlagene Anmeldungen dieses Kontos.

Es werden höchstens die neuesten 2 000 passenden Zeilen angezeigt. Wird diese Grenze erreicht, sagt die Seite das ausdrücklich — ein stillschweigend abgeschnittenes Protokoll ist schlimmer als gar keines.

Zwei Ansichten, zwei Fragen

Die Auswahl Ansicht schaltet um:

• Live vom Server liest die Datei auf der Instanz. Sekundenaktuell, ungefiltert — und beim nächsten Dienstneustart weg.
• Archiviert (gesammelt) liest, was der Monitor aufbewahrt hat. Ein Hintergrunddienst kopiert alle paar Minuten jede Zeile ab der konfigurierten Stufe in die Monitoring-Datenbank. Diese Ansicht reicht damit über Dienstneustarts hinaus zurück und über so viele Protokolldateien, wie SQL Server seither rotiert hat.

Keine ersetzt die andere. Der Live-Ansicht vertrauen Sie bei etwas, das gerade passiert; die archivierte Ansicht ist die einzige, die „Was hat dieser Server vor drei Wochen gemeldet?" beantworten kann.

Das Abzeichen neben der Tabellenüberschrift sagt, ob das Sammeln überhaupt funktioniert — harvested 4 min ago, not harvested yet oder harvest failing samt Grund. Eine leere Tabelle unter einem roten Abzeichen bedeutet, dass niemand das Protokoll lesen konnte — eine völlig andere Aussage als ein ruhiger Server.

Alarme

Gesammelte Einträge ab der Alarmstufe (Standard Error) lösen einen Alarm über die normale Alarmierung aus: Severity-Routing, Benachrichtigungskanäle, Wartungsfenster und Quittierung verhalten sich wie bei jedem anderen Alarm.

Zwei bewusste Verhaltensweisen:

• Ein Alarm pro Stufe pro Schub, nicht einer pro Zeile. Ein Stack Dump sind ein Dutzend Zeilen in einer Sekunde; ein Dutzend Meldungen für einen Vorfall ist der schnellste Weg, eine Rufbereitschaft dazu zu bringen, das Produkt stummzuschalten. Der Alarm trägt die schwerwiegendste Zeile als Beispiel und die Anzahl der Vorkommen.
• Der erste Durchlauf pro Server speichert nichts. Er merkt sich nur den Stand. Monitoring einzuschalten darf nicht Wochen an Historie importieren und dann wegen eines Neustarts aus dem Juli jemanden alarmieren.

Pro Server werden automatisch zwei Regeln angelegt, Error log: Error und Error log: Critical — so lässt sich Critical an PagerDuty und Error an E-Mail routen, oder eines von beiden abschalten. Es sind gewöhnliche Regeln unter /settings/alerts.

Fehlerprotokoll-Alarme beschreiben einen Zeitpunkt, keinen Zustand, und lösen sich daher nicht von selbst auf. Quittieren Sie sie, sobald Sie sich darum gekümmert haben.

Was ein kritisches Ereignis mitbringt

Ein Klick auf eine gesammelte Zeile öffnet die Detailansicht. Bei kritischen Einträgen enthält sie zwei Dinge, die die Tabelle nicht zeigen kann.

Die umliegenden Protokollzeilen. Derselbe Stufenfilter, der die Tabelle lesbar hält, verwirft die Zeilen, die ein kritisches Ereignis erklären — ein Stack Dump behält seine Kopfzeile Stack Dump being sent to ... und verliert Input Buffer 255 bytes - SELECT ..., also die Anweisung, die ihn ausgelöst hat. Bei einem Critical liest der Monitor deshalb ein paar Minuten davor und danach ungefiltert nach und speichert diesen Block am Ereignis. Die Zeile des Ereignisses ist darin hervorgehoben.

Ist die Instanz zwischendurch neu gestartet, hat das Protokoll bereits rotiert und der Block ist nicht mehr zu retten. Die Ansicht sagt das, statt ein leeres Feld zu zeigen — und sie unterscheidet diesen Fall von einem Lesefehler wegen fehlender Rechte, denn das eine liegt am Server und das andere an uns.

Was sonst noch los war. Eine Zeitleiste alles bereits Erfassten im Umkreis von ±15 Minuten: Konfigurations- und DDL-Änderungen, Deadlocks, Blocking-Ketten, andere Alarme, dazu CPU, Speicher und Verbindungen aus der nächstgelegenen Messung. Jeder Eintrag ist relativ zum Ereignis angegeben — −3 min davor, +40 s danach —, denn genau danach wird gefragt. Dafür geht keine einzige zusätzliche Abfrage an den überwachten Server: Es sind Daten, die das Produkt längst aufgeschrieben hatte, nur nie neben das Ereignis gestellt hat.

Archivierte Protokolle

SQL Server beginnt bei jedem Dienstneustart und bei jedem sp_cycle_errorlog eine neue Protokolldatei und behält standardmäßig sechs Archive. Die Auswahl Datei zeigt, was aktuell auf der Platte liegt. Für mehr Historie erhöhen Sie die Anzahl der aufbewahrten Protokolle im SQL Server Management Studio (Verwaltung → SQL Server-Protokolle → Konfigurieren).

Berechtigungen

Das Lesen des Protokolls erfordert zwei Berechtigungen, die in den üblichen Monitoring-Rechten nicht enthalten sind. Beide Prozeduren liegen in master, der Login braucht dort also auch einen Benutzer — dieser Schritt wird am häufigsten übersehen:

-- Auf jeder überwachten Instanz, als sysadmin:
USE master;
CREATE USER [monitoring_login] FOR LOGIN [monitoring_login];   -- nötig: die Prozeduren liegen in master
GRANT EXECUTE ON sys.xp_readerrorlog  TO [monitoring_login];   -- Protokoll lesen
GRANT EXECUTE ON sys.xp_enumerrorlogs TO [monitoring_login];   -- Archive auflisten

Mitgliedschaft in securityadmin funktioniert ebenfalls, gewährt aber weit mehr als nötig — damit lassen sich Logins anlegen und Kennwörter zurücksetzen. Nehmen Sie die zwei Grants.

Die Wrapper sp_readerrorlog und sp_enumerrorlogs funktionieren mit den schmalen Grants nicht: Sie enthalten eine interne securityadmin-Prüfung. Der Monitor ruft deshalb direkt die zugrunde liegenden erweiterten Prozeduren auf.

Fehlt die Berechtigung, nennt die Seite genau die nötigen Grants, statt ein leeres Protokoll zu zeigen — ein leeres und ein unlesbares Protokoll sind sehr verschiedene Aussagen über einen Server.

Azure SQL-Datenbank

Dort gibt es kein Fehlerprotokoll auf Instanzebene. Die Seite sagt das, statt mit einem Fehler abzubrechen. Managed Instance und lokale Instanzen funktionieren normal.