Self-Repairing-Monitoring Solution oder was einem noch so versprochen wird

Ausgehend von einem Beitrag auf Kitchensoap.com zum Thema Monitoring Solutions und einer Frage zu meinem Kommentar von Martin Goodwell (t) fühlte ich mich inspiriert zumindest kurz etwas dazu zu schreiben, denn auch ich kenne diese Monitoring Lösungen, wo einem die Hersteller das gelbe vom Ei versprechen und dann muss man sich doch um viele Dinge selber kümmern.

Martin schrieb mir über Twitter: “ … Würde gerne mehr über „the DBA team has to write all the rules“ erfahren“.

In meiner täglichen Arbeit als SQL Server DBA komme ich mit verschiedenen Kunden-Umgebungen in Kontakt und lerne dadurch auch unterschiedliche Monitoring-Lösungen und den Umgang damit kennen. Es gibt Lösungen, die mag man auf Anhieb und manche Tools, die versteht man selbst nach Jahren nicht. Also verstehen im Sinne von : „Was haben die sich bloß dabei gedacht???“
Es mag auch an den unterschiedlichen Teams, die diese Monitoring Systeme betreuen liegen oder an der Historie der Kunden-Umfelder, aber doch (zumindest aus meiner Sicht) sehr an den Tools selber.

Welche Monitoring Tools werden eingesetzt?

Nagios
Ist aus meiner Sicht eines der idealsten und flexibelsten Monitoring-Tools, die es aktuell gibt. Soweit meine Kenntnis reicht, kann man hiermit sehr vieles umsetzen, wenn man einen fähigen Entwickler an die Checks lässt.

ITM 6
Ich kenne eigentlich nur die komische Web-Oberfläche um Benachrichtigungen und Mail-Templates anzupassen, aber hier frage ich mich immer wieder, ob die Entwickler sich mal Gedanken zur Usability gemacht haben…

SCOM
Das hauseigene Microsoft Produkt, kann zumindest alle Microsoft-Produkte überwachen, mit einer komplexen aber leicht verständlichen Oberfläche.

BMC Patrol
Kenne ich nur aus einem Kunden-Umfeld und eigentlich (zumindest bisher) auch nur von den Benachrichtigungen…

Aber ich bin kein Monitoring Experte und wollte ja eigentlich auch nur was zu der Anfrage von Martin schreiben 😉

„the DBA team has to write all the rules“

Was John Allspaw (b|t) in seinem Beitrag beschrieb, klingt wie „unser Monitoring System findet alle Fehler und behebt sie von alleine“.
Klingt erstmal toll und für einen kaufmännischen Entscheidungsträger sicherlich auch sehr verlockend (Monitoring System macht alles alleine, ich kann Personal einsparen). Aber wenn man dann genauer hinterfragt, was diese Systeme denn leisten, stellt man meist fest (ich lasse mich gerne eines besseren belehren), dass man eher zwei Leute einstellen muss und das die initiale Inbetriebsetzung eines solchen Systemes Zeit und Ressourcen verschlingt.

Meine Aussage rührt daher, dass ich genau diese Erfahrung mit gemacht habe.
Es sollte ein neues Monitoring System für eine Vielzahl von Servern (nicht nur SQL Server, komplettes Kunden-Umfeld) überwacht werden, die Aufnahme der zu überwachenden Server und Zuordnung der einzelnen Checks ließ sich noch recht einfach und zügig realisieren, ABER dann…

Es wurden Fachkräfte/Experten gesucht, die sich mit den jeweilgen Systemen auskannten (z.B. Exchange, Lync, Oracle, SQL Server…) um zu definieren, was in welchem Fehlerfall zu tun wäre.
Was soll also passieren, wenn zum Beispiel auf dem SQL Server das Backup nachts nicht mehr läuft/nicht gelaufen ist?

1. Retry des Backups mit Mail-Benachrichtigung der SQL-Gruppe
   1. Connect zum SQL-Server
   2. Job-Status ermitteln
      1. wenn Running, dann abbrechen
      2. wenn Failed, dann neustarten
      3. wenn Canceled, dann weiter mit Step 5
   3. Job ggfs abbrechen
   4. Job per SQL Agent neustarten
   5. Mail an DBA versenden
   6. Disconnect
   7. Status im Monitoring Tool zurücksetzen
2. wieder fehlgeschlagen, dann Ticket erstellen
   1. Connect zum SQL-Server
   2. Job-Status ermitteln
   3. Job ggfs abbrechen
   4. Job per SQL Agent neustarten
   5. Mail an DBA versenden
   6. Mail an Leitstand mit Work-Instruction, die Rufbereitschaft zu alarmieren

Aus dieser Erfahrung heraus und den Erfahrungen mit anderen Monitoring Tools, diese Systeme sind nur so gut wie die Experten, die diese Tools mit Leben füllen. Ich habe zum Beispiel einen Nagios-Experten, dem erzähle ich meine Wünsche/Sorgen/Anforderungen und der setzt diese bestmöglich und gewissenhaft um. Bei dem kann ich mir sicher sein, dass mein System auch ausreichend und durchgängig überwacht wird bzw ich über jedes Problem auf diesem System Kenntnis erlange. Bei anderen Kollegen bzw Monitoring Tools habe ich da so meine Bedenken… was nützt mir eine Überwachung, die vielleicht sogar Alarm schlägt, aber dann nicht weiß wie sie mit dem Fehler umgehen soll.

Was nützt es, wenn die Überwachung feststellt „Service ‚SQL Full-text Filter Daemon Launcher (MSSQLSERVER)‘ is not started. Current state is stopped.„, dann aber nicht weiß, was es jetzt mit dem System/dem Fehler/dem Service machen soll. In diesem Fall kommt die Fehlermeldung von einem Cluster, dass gerade geschwenkt hat und dann ist klar, dass der Dienst auf einem Knoten nicht mehr läuft sondern jetzt auf dem anderen Cluster-Knoten.
Es gibt also zumindest eine Überwachung der Services, aber das Handling dahinter (die Rules und Instructions) muss auch auf alle eventuell auftretenden Situationen vorbereitet sein.

• Läuft der Service auf einem Standalone-Server oder handelt es sich um einen Cluster?
• Wie muss der Service im Fehlerfall ggfs neu gestartet werden?
• Darf der Service überhaupt ohne vorherige Kontrolle/Eingriff wieder gestartet werden?
• Kann man den Service überhaupt neustarten? (Abhängigkeiten)
• Wie oft darf der Service neu gestartet werden?

Es kann mir keine Firma erzählen, dass sie all diese komplexen Fehler, Zusammenhänge und Herangehensweisen in einer Self-Repairing-Monitoring-Solution vereint haben, und dann wirklich keiner mehr nach der Installation mehr Hand anlegen muss, um die oben genannten Variationen einwandfrei und fehlerfrei abzuarbeiten.

Solche Versprechungen wie

• “our product will tell you when things are going wrong” and/or
• “our product will automatically fix things when it finds something is wrong”

kann ich nicht glauben, denn sowas gibt es aus meiner Sicht bisher nicht auf dem Markt.
Für einfache Applikationen wie DNS, Printer-Spooler kann ich mir noch vorstellen, dass man bei diesen Services/Applikationen „einfach“ nur restarten muss, aber in komplexen Applikations-Landschaften fällt dies sicher schwer(er).

Mein Fazit:

Nur wenn man solche Monitoring Systeme durchgängig und voll umfänglich nutzt (dazu muss man die Regeln, Anforderungen und Lösungen aber erst einmal definieren), dann können sie sehr hilfreich sein und einem die Arbeit erleichtern.

@Martin: Ich hoffe ich habe deine Frage bzw deine Anmerkung beantwortet, wenn nicht … frag nochmal 😉

Nun auch nochmal als Teilnehmer am T-SQL Tuesday #66