Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Auswahl eines SQL Server-Überwachungstools, das Ihren Anforderungen entspricht

Bevor Sie sich ein SQL-Server-Überwachungstool ansehen, denken Sie an Ihre spezifische Umgebung:

  • Wie viele Instanzen möchten Sie überwachen?
  • Sind diese an einem Ort oder verteilt?
  • Müssen Sie das Betriebssystem und/oder den Hypervisor überwachen?
  • Wie viel Verlauf benötigen Sie, um sich ein genaues Bild von den Betriebsgrenzen Ihrer Instanz zu machen?
  • Sind sie alle lokal oder befinden sich einige in der Cloud?
  • Sind Ihre Teams verteilt?
  • Kaufen Sie Software im Rahmen eines Investitions- oder Betriebsausgabenbudgets?
  • Können Sie es sich leisten, einen Pauschalbetrag im Voraus in Infrastruktur und Lizenz zu investieren, oder ziehen Sie es vor, Ihre Kosten über die Zeit zu verteilen?
  • Verfügen Sie über Infrastruktur- und Datenbankinstanzen, die Sie einem Überwachungstool zuweisen können?
  • Haben Sie Zeit, eine Überwachungsinfrastruktur aufzubauen?
  • Verfügen Sie in Ihrem Team über ein konstant hohes Fachwissen?
  • Nutzen Sie Junior-Ressourcen für die anfängliche Sichtung oder verlassen Sie sich bei allem auf Ihre Experten?
  • Haben Sie intern Zeit oder Ressourcen, um die Überwachungsinfrastruktur zu warten?

Soll ich selbst rollen?

Ich kann hier unsere Voreingenommenheit erklären. Quest Software entwickelt seit 20 Jahren Tools zur Leistungsüberwachung. Es gibt einen guten Grund, warum wir und viele andere so lange in diesem Segment geblieben sind und warum wir einen wachsenden Kundenstamm haben. Leistungsüberwachung gut gemacht ist nicht einfach!

Es gibt in der Tat einige großartige Möglichkeiten, Metriken von SQL Server mithilfe von PerfMon, Traces, DMVs und XEvents zu sammeln, um nur einige zu nennen. Dies auf einer einmaligen Basis für ein einzelnes Problem zu tun, ist schön und gut – wenn Sie die Zeit haben, in die Recherche zu investieren, wo und wie Sie die Daten für dieses Problem sammeln können. Sobald sich die Probleme häufen und die Anzahl der Instanzen zunimmt, wird dies schnell unskalierbar.

Es stehen mehrere hundert Metriken zur Verfügung, die es wert sind, verfolgt zu werden, um sich ein vollständiges Bild vom Leistungszustand Ihres SQL Servers zu machen. Darüber hinaus gibt es den SQL-Code, der ausgeführt wird, und die Abfragepläne, die mit jeder Ausführung desselben verknüpft sind. Einige Metriken sollten jede Sekunde erfasst werden, andere stündlich und einige basierend darauf, wann der Code ausgeführt wird. Einige Erfassungsmethoden können sich auf die überwachte Instanz auswirken und sollten vermieden werden.

Jede Metrik hat unterschiedliche Schwellenwerte, die ihren Status definieren würden. Bestimmte Instanzen können Niveaus haben, die nicht dem Standard entsprechen. Dann müssen Sie das alles speichern. Das Datenvolumen summiert sich SEHR schnell. Sie müssen eine Strategie entwickeln, um detaillierte Daten regelmäßig zu löschen und diese Daten dann, falls für Trendanalysen erforderlich, für die Berichterstellung zusammenzufassen.

Es ist eine Menge Arbeit … und natürlich haben Sie jedes Mal, wenn eine neue SQL Server-Version herauskommt, Regressionskopfschmerzen. Sofern Sie nicht wirklich ein Überwachungstool verkaufen möchten, würde ich dringend davon abraten, ein eigenes zu entwickeln, es sei denn, die Anzahl der Probleme ist gering und die Probleme, die Sie lösen müssen, sind sehr spezifisch.

Was ist mit kostenlosen Tools?

Gerade für kleinere Teams mit weniger kritischen Instanzen sind kostenlose Tools oft eine Überlegung wert. Betrachten Sie es als den nächsten Schritt auf der Leiter der Skalierbarkeit nach „Roll your own“. Viele der kommerziellen SQL-Server-Überwachungstools der Einstiegsklasse sollten ähnliche Überlegungen anstellen. Beachten Sie Folgendes:

  • Deckt das Tool eine ausreichende Bandbreite an Metriken ab, um Ihnen eine angemessene Abdeckung aller Anwendungsfälle in Ihren überwachten Instanzen zu bieten? Viele kostenlose Tools bieten eine Art „Anpassung“, um Ihre eigenen Metriken hinzuzufügen. Wenn „Anpassung“ verwendet wird, um Funktionslücken zu schließen, werden Sie schnell feststellen, dass Ihr Team mit der erforderlichen Ablenkung und Wartungsproblemen „sich selbst einstellt“.
  • Unterstützt das Tool Benachrichtigungen? Ist es vorkonfiguriert? Das Konfigurieren von Warnmeldungen kann sehr zeitaufwändig sein. Out-of-Box-Alarmierung ist ein Muss, um zu verhindern, dass viele Arbeitsstunden durch die Konfiguration des Tools eines anderen verloren gehen. Es sollte auch die Anpassung von Warnungen für Grenzfälle erleichtern, die nicht den Standardeinstellungen entsprechen.
  • Wie und wo werden die Daten gespeichert? Die meisten kostenlosen Tools überlassen es Ihnen, die Speicherung von Leistungsdaten zu verwalten. Seien Sie vorsichtig bei der „kostenlosen“ Überwachung von Cloud-Anbietern. Sie berechnen die Speicherung, und das kann schnell groß und teuer werden!

Nutzen Sie also auf jeden Fall die kostenlosen Tools, die es gibt. Seien Sie sich nur ihrer Grenzen bewusst und halten Sie Ausschau nach den klassischen Anti-Patterns in Ihrem Team, wie zum Beispiel:

  • Mehr Zeitaufwand für die Reparatur oder Wartung des Tools als für die Behebung von Problemen
  • Höhere Ausgaben für Infrastruktur und Speicher
  • Viele Daten, aber keine Erkenntnisse
  • Die Diagnose reicht nicht aus, um Probleme zu lösen
  • Nicht skalierbar genug, um Ihren Anforderungen gerecht zu werden

Wenn Sie einen der oben genannten Punkte bemerken, sollte dies auf die Notwendigkeit eines Upgrades auf eine robustere Lösung hindeuten.

Typische Architektur eines SQL Server-Überwachungssystems

Bei der Überlegung, ob Sie sich für eine herkömmliche lokale Lösung oder eine gehostete Software-as-a-Service-Lösung (SaaS) entscheiden sollten, ist es hilfreich, die Überwachungsanwendungsarchitektur zu berücksichtigen. Hier ist eine Zusammenfassung der wichtigsten Architekturkomponenten.

Der Hauptunterschied zwischen SaaS und On-Premises bezieht sich darauf, wo die Leistungsdaten gespeichert werden und wer dieses Repository verwaltet. Bei einer lokalen Lösung liegt dies in der Verantwortung des Endbenutzers. Diese Repositories können schnell groß werden, daher müssen sie sorgfältig verwaltet werden. Die Infrastruktur muss geplant und budgetiert werden (mehr unten).

In einer SaaS-Lösung für die SQL-Serverüberwachung werden diese wichtigen Infrastrukturkomponenten für Sie gehostet und verwaltet.

Traditionelle lokale Lösung SaaS-Lösung
  • Datenerhebungsprozess
  • Kurzfristiges Performance [Diagnose] Repository
  • Langfristiges Analyse-/Berichts-Repository
  • Windows- oder Browser-Client
  • Jede Failover-Infrastruktur, die für die Überwachungsinfrastruktur erforderlich ist
  • Datenerfassungsprozess (für lokale Ziele)
  • Browser-Client
  • Mobile App
  • Der SaaS-Anbieter verwaltet die Anwendungs- und Backend-Datenspeicherung.

Weitere Einzelheiten finden Sie in unserem Blog Database Monitoring System Architecture.