SQL Server Monitoring und sqmSQLTool-Konfiguration mit PowerShell

6 PowerShell-Funktionen fuer die Modul-Konfiguration von sqmSQLTool, SQL Server Agent Job History, Betriebsstatus-Monitoring laufender Operationen und die Integration mit Splunk Universal Forwarder fuer zentrales Log-Management.

6 Funktionen Modul-Konfiguration Splunk SCOM / Zabbix

Monitoring & Konfiguration - Funktionen im Ueberblick

Set-sqmConfig - sqmSQLTool Modulkonfiguration speichern PowerShell: LogPath, OutputPath, Sprache, Job-Namen

Was macht die Funktion?

Speichert die sqmSQLTool-Modulkonfiguration persistent in %APPDATA%\MSSQLTools\config.json. Konfigurierbare Parameter: LogPath, OutputPath, CentralPath, Ola-Job-Namen, TSM-Klassen, Sprache (DE/EN), SSRS-Installer-Pfad und weitere modulweite Einstellungen. Einmal gesetzt greifen alle sqmSQLTool-Funktionen automatisch auf diese Konfiguration zu.

Wann nutzt man sie?

Als allererstes nach der Modul-Installation um alle Pfade und Einstellungen einmalig zu konfigurieren. Bei Aenderungen der Unternehmensstandards (z.B. neuer Backup-Pfad oder neue Ola-Job-Namenskonvention). Bei der Einrichtung auf einem neuen Rechner oder nach dem Wechsel des Benutzerprofils.

Typische Probleme

  • Konfiguration nicht gesetzt - alle Funktionen verwenden Default-Werte die nicht passen
  • Pfade nicht existierend - Funktionen erzeugen Fehler beim Schreiben von Log-Dateien
  • Falsche Ola-Job-Namen - Test-sqmOlaInstallation findet Jobs nicht

Vorteile

  • Einmalige Konfiguration fuer alle Funktionen - kein Wiederholen von Pfad-Parametern
  • JSON-basiert: einfach zu lesen, zu bearbeiten und in Versionsverwaltung zu halten
  • Unternehmensweit konsistente Konfiguration durch zentrale Vorlage
# Grundkonfiguration nach der Modul-Installation
Set-sqmConfig -LogPath "D:\DBALogs" -OutputPath "D:\DBAReports" -Language "DE"

# Vollstaendige Konfiguration inkl. Ola-Job-Namen und TSM
Set-sqmConfig -LogPath "D:\DBALogs" -OutputPath "D:\DBAReports" -OlaFullJobName "DBA - FULL Backup" -SsrsInstallerPath "\\FileServer\SQL\SSRS"

Get-sqmConfig - sqmSQLTool Modulkonfiguration anzeigen PowerShell: config.json Inhalt ausgeben

Was macht die Funktion?

Liest die aktuelle sqmSQLTool-Konfiguration aus %APPDATA%\MSSQLTools\config.json und gibt sie strukturiert aus. Zeigt alle konfigurierten Parameter mit ihren aktuellen Werten. Nuetzlich um die aktive Konfiguration zu ueberpruefen bevor Funktionen ausgefuehrt werden.

Wann nutzt man sie?

Zur Verifikation dass die Konfiguration korrekt gesetzt ist nach einem Set-sqmConfig Aufruf. Bei der Fehlersuche wenn Funktionen unerwartete Pfade verwenden. Als erster Schritt bei der Uebergabe eines konfigurierten sqmSQLTool-Systems an einen anderen Administrator.

Typische Probleme

  • Konfigurationsdatei nicht gefunden weil Set-sqmConfig noch nicht ausgefuehrt wurde
  • Veraltete Konfiguration nach Umzug des DBA-Profils auf neuen Rechner
  • Falsch konfigurierter Pfad wird erst beim Aufruf einer Funktion als Fehler bemerkt

Vorteile

  • Schnelle Uebersicht der gesamten aktiven Konfiguration in einem Befehl
  • Strukturierte Ausgabe zeigt alle Parameter auf einen Blick
  • Pipeline-faehig: Konfiguration kann in Berichte oder Dokumentation integriert werden
# Aktuelle Konfiguration anzeigen
Get-sqmConfig

# Konfiguration als JSON-Ausgabe
Get-sqmConfig | ConvertTo-Json

Get-sqmAgentJobHistory - SQL Server Agent Job Ausfuehrungshistorie PowerShell: Status, Dauer, Fehler filtern

Was macht die Funktion?

Liest die SQL Server Agent Job Ausfuehrungshistorie aus msdb und gibt sie strukturiert zurueck: Job-Name, Ausfuehrungsstatus (Success/Failure), Startzeit, Dauer, letzte Fehlermeldung und Ausfuehrungsschritte. Filterbar nach Job-Name, Zeitraum, Status und Dauer. Besonders nuetzlich fuer automatisierte Backup-Job-Ueberwachung.

Wann nutzt man sie?

Im morgendlichen DBA-Routine-Check um fehlgeschlagene Jobs der letzten Nacht zu identifizieren. Als Basis fuer einen taeglichen E-Mail-Report der Job-Ausfuehrungsergebnisse. Bei der Fehleranalyse wenn ein Job fehlgeschlagen ist und die detaillierte Fehlermeldung benoetigt wird.

Typische Probleme

  • Fehlgeschlagene Backup-Jobs werden erst beim Restore-Notfall bemerkt
  • Job-History in SSMS zeigt nur begrenzte Eintraege - aeltere Fehler nicht mehr sichtbar
  • Lange Job-Dauer als Fruehwarnung fuer Performance-Probleme wird nicht beobachtet

Vorteile

  • Filterung nach Fehlerstatus zeigt sofort alle Probleme der letzten Nacht
  • Dauer-Analyse identifiziert Jobs die ungewoehnlich lange laufen
  • Pipeline-faehig fuer E-Mail-Reports und Monitoring-System-Integration
# Alle fehlgeschlagenen Jobs der letzten 24 Stunden
Get-sqmAgentJobHistory -SqlInstance "SQL01" -Status "Failed" -HoursBack 24

# History fuer spezifischen Backup-Job der letzten 7 Tage
Get-sqmAgentJobHistory -SqlInstance "SQL01" -JobName "DBA - FULL Backup" -DaysBack 7

Get-sqmOperationStatus - SQL Server Backup Restore AutoSeed Fortschritt und ETA PowerShell anzeigen

Was macht die Funktion?

Zeigt den Fortschritt und die ETA (Estimated Time of Arrival) fuer laufende SQL Server Operationen: Backup, Restore, DBCC CHECKDB, AutoSeed (AlwaysOn) und Index-Rebuild. Liest die Fortschrittsinformationen aus sys.dm_exec_requests und relevanten DMVs und berechnet die verbleibende Zeit.

Wann nutzt man sie?

Waehrend langer Backup- oder Restore-Operationen um die verbleibende Zeit einzuschaetzen. Beim AutoSeed grossen Datenbanken zu AlwaysOn um den Fortschritt zu verfolgen. Bei DBCC CHECKDB um zu sehen ob die Pruefung in der verfuegbaren Wartungsfensterzeit abgeschlossen wird.

Typische Probleme

  • Keine Fortschrittsanzeige bei langen Operationen - unbekannte Restdauer
  • Backup/Restore wird abgebrochen weil Wartungsfenster endet - keine ETA-Information vorhanden
  • AutoSeed haengt ohne erkennbaren Fortschritt - Unterschied zu echtem Fehler nicht klar

Vorteile

  • ETA-Berechnung ermoeglicht Planung ob Operation im Wartungsfenster abgeschlossen wird
  • Erkennt fehlende Fortschritte (haengende Operationen) und warnt entsprechend
  • Ueberwacht mehrere gleichzeitige Operationen auf derselben Instanz
# Alle laufenden Operationen mit Fortschritt und ETA anzeigen
Get-sqmOperationStatus -SqlInstance "SQL01"

# Nur Restore-Operationen ueberwachen (alle 10 Sekunden aktualisieren)
Get-sqmOperationStatus -SqlInstance "SQL01" -OperationType "Restore" -RefreshSeconds 10

Invoke-sqmMonitoringKey - SQL Server Monitoring-Key setzen PowerShell: SCOM, Nagios, Zabbix Integration

Was macht die Funktion?

Setzt einen Monitoring-Key in der SQL Server Konfiguration oder einer dedizierten Monitoring-Tabelle, der von externen Monitoring-Systemen (SCOM, Nagios, Zabbix) abgefragt wird. Der Key signalisiert dem Monitoring-System ob der SQL Server betriebsbereit ist und korrekt antwortet. Konfigurierbar mit Ablaufzeit und Health-Status.

Wann nutzt man sie?

Bei der Integration eines neuen SQL Servers in ein bestehendes Monitoring-System. Nach Wartungsfenstern um das Monitoring-System ueber das Ende der Wartung zu informieren. Als Liveness-Probe fuer Container-basierte SQL Server Instanzen.

Typische Probleme

  • Monitoring-System erkennt SQL Server nicht als ueberwacht - fehlender Monitoring-Key
  • Abgelaufener Monitoring-Key erzeugt False-Positive-Alert waehrend des Wartungsfensters
  • Inkonsistente Monitoring-Key-Implementierung auf verschiedenen Instanzen

Vorteile

  • Standardisierte Monitoring-Integration fuer alle Monitoring-Systeme
  • Ablaufzeit verhindert dass verwaiste Keys als "gesund" signalisiert werden
  • Pipeline-faehig fuer Farm-weite Monitoring-Aktivierung nach Wartung
# Monitoring-Key setzen (gueltig fuer 24 Stunden)
Invoke-sqmMonitoringKey -SqlInstance "SQL01" -ValidHours 24

# Monitoring-Key fuer alle Instanzen nach Wartung setzen
@("SQL01","SQL02","SQL03") | Invoke-sqmMonitoringKey -ValidHours 24

Invoke-sqmSplunkConfiguration - Splunk Universal Forwarder PowerShell konfigurieren: lokal, Remote via AD-OU, WhatIf-Modus

Was macht die Funktion?

Konfiguriert den Splunk Universal Forwarder auf SQL Server Systemen: Ziel-Splunk-Indexer konfigurieren, SQL Server relevante Log-Quellen (Windows Event Log, SQL Server Error Log, SQL Agent Log) als Monitore einrichten und Forwarder-Neustart. Unterstuetzt lokale Konfiguration, Remote-Ausrollug per AD-OU und WhatIf-Modus fuer Dry-Run.

Wann nutzt man sie?

Beim Farm-weiten Rollout von Splunk Universal Forwarder auf allen SQL Server Systemen. Wenn neue SQL Server Instanzen automatisch in das zentrale Splunk-Log-Management aufgenommen werden sollen. Bei der Aktualisierung der Splunk-Konfiguration nach Aenderungen am Indexer oder an Log-Quellen.

Typische Probleme

  • SQL Server Error Log nicht als Splunk-Monitor konfiguriert - Fehler nicht in Splunk sichtbar
  • Splunk Forwarder konfiguriert aber SQL Agent Log-Pfad falsch - Agent-Fehler nicht erfasst
  • Massenausrollung ohne WhatIf-Pruefung aendert unerwartete Konfiguration auf Produktionssystemen

Vorteile

  • WhatIf-Modus zeigt alle geplanten Aenderungen vor der Ausfuehrung - kein Produktionsrisiko
  • AD-OU-basierter Rollout auf Hunderte von SQL Servern ohne manuelle Einzelkonfiguration
  • Vordefinierte SQL Server Log-Quellen als Templates fuer konsistente Splunk-Konfiguration
# Splunk Universal Forwarder auf SQL01 konfigurieren
Invoke-sqmSplunkConfiguration -ComputerName "SQL01" -SplunkIndexer "splunk01:9997"

# Farm-weiter Rollout per AD-OU mit WhatIf-Dry-Run zuerst
Invoke-sqmSplunkConfiguration -OU "OU=SQLServer,DC=firma,DC=de" -SplunkIndexer "splunk01:9997" -WhatIf
Invoke-sqmSplunkConfiguration -OU "OU=SQLServer,DC=firma,DC=de" -SplunkIndexer "splunk01:9997"
Zurueck zum Index