Es gibt eine wachsende Zahl großartiger Systeme zur Überwachung der Datenbankleistung. Vor kurzem wurden die traditionelleren On-Premises-Lösungen durch Software-as-a-Service-Lösungen (SaaS) ergänzt.
Dieser Blog stellt die typische Architektur einer On-Premises-Lösung der einer SaaS-Lösung gegenüber. Natürlich unterscheiden sich Komponenten in Namen und Struktur von einem Anbieter zum anderen, aber die hier besprochenen Schlüsselkonzepte werden in der einen oder anderen Form dargestellt.
Unterschiede zwischen lokalen und SaaS-Lösungen
Insgesamt sind hier einige der Schlüsselkomponenten jeder Lösung aufgeführt:
Traditionelle lokale Lösung
- Datenerhebungsprozess.
- Speicher für kurzfristige Leistung [Diagnose].
- Langfristiges Analyse-/Berichts-Repository.
- Windows- oder Browser-Client.
- Jede Failover-Infrastruktur, die für die Überwachungsinfrastruktur erforderlich ist.
SaaS-Lösung
- Datenerfassungsprozess (für lokale Ziele).
- Browser-Client.
- Mobile App.
- Der SaaS-Anbieter verwaltet die Anwendungs- und Backend-Datenspeicherung.
Beachten Sie, dass die Namen der verschiedenen Komponenten von einer Lösung zur anderen variieren. In einigen Fällen kann die Funktionalität auf mehrere Dienste oder Datenquellen aufgeteilt sein.
Lokale Lösungen
Datenerhebungsprozess
Der Datensammler ist in der Regel ein lokaler, agentenloser Dienst, der Daten von jedem überwachten Endpunkt vor Ort sammelt. Dieser Prozess orchestriert, wie und wann Daten erfasst werden. Es sollte in der Lage sein, Daten mit unterschiedlichen Frequenzen zu sammeln, um den Bedarf an mehr Details mit den Auswirkungen auf die überwachte Arbeitsbelastung auszugleichen. Erfassungshäufigkeiten und Warnungsschwellenwerte sollten für jede Metrik vorkonfiguriert sein.
Jeder wird eine „verrauschte“ Instanz haben, die nicht den Standardschwellenwerten entspricht. Dies kann zu vielen Fehlalarmen führen. Um damit fertig zu werden, sollte das System in der Lage sein, Regeln auf Instanzebene zu erstellen, um mit außergewöhnlichen Umständen fertig zu werden. Dies vermeidet „Alarmmüdigkeit“ durch Fehlalarme.
In einigen Fällen orchestriert dieser Dienst auch Warnungen und Benachrichtigungen. In großen Organisationen mit Hunderten von überwachten Instanzen kann es erforderlich sein, die Last auszugleichen, indem mehrere Datensammler „verbunden“ werden. Federation synchronisiert Sammlungen und Konfigurationen in einem verteilten System.
Speicher für kurzfristige Diagnosen
Hier werden Detaildaten gespeichert. Dazu gehören Daten aus DMVs, Protokolldateien, XEvents und anderen SQL Server-Datenquellen. Quellen, die Druck auf die überwachten Instanzen ausüben könnten, sollten vermieden werden, z. B. sind die meisten Spuren für eine Echtzeitüberwachung ungeeignet.
Da die Erfassungshäufigkeit bis zu jede Sekunde betragen kann und größere Datenblöcke wie TSQL und Pläne erfasst werden, kann dieses Repository schnell groß werden. Infolgedessen begrenzen die meisten Systeme den Verlauf normalerweise auf zwischen einer Woche und einem Monat (diese Einschränkungen gelten nicht für eine SaaS-Lösung). Dieses Repository ist von Natur aus in hohem Maße transaktional.
Langfristiges Reporting/Analytics Repository
Am Ende einer vordefinierten Zeit werden diese detaillierten Daten aggregiert und in einem Berichtsspeicher für allgemeine Analysen und Trends gespeichert. Die Menge der aufbewahrten Details hat einen erheblichen Einfluss auf die letztendliche Größe dieses Repositorys und die Rechenkapazität, die vernünftigerweise erwartet werden kann, dass ein Benutzer sie zur Verfügung stellt, um sie zu analysieren. Dies variiert in der Regel erheblich von einer Lösung zur nächsten. Lösungen, die tiefere Analysen unterstützen, verfügen über unterstützende Architekturen und können OLAP-Architekturen verwenden, um die multidimensionale Analyse zu erleichtern.
Skalieren einer lokalen Überwachungslösung
Anspruchsvollere Lösungen werden entwickelt, um eine verteilte Architektur der Schlüsselkomponenten zur Unterstützung der Skalierung zu ermöglichen. Der Datenerfassungsdienst verfügt über eine obere Anzahl von überwachten Verbindungen, die er unterstützen kann. Sobald diese Grenze erreicht ist, sollte ein zusätzlicher Datensammler „föderiert“ werden, um die Datenerfassung zu koordinieren und die Speicherung der Daten zu orchestrieren.
Die Leistungsdaten-Repositories selbst können sich eine Instanz teilen oder auf mehrere Instanzen verteilt sein, um die Skalierung zu unterstützen. Der Speicherplatz, den sie benötigen, ist direkt proportional zur Anzahl der überwachten Verbindungen und der gespeicherten Datenmenge. Die Struktur und Architektur des Analytics-Repositorys wirken sich ebenfalls auf die Gesamtkapazität aus.
Benutzererfahrung
Die meisten lokalen Tools verfügen über ein Windows-Frontend. Einige haben Browser-Frontends, die auf einer lokal gehosteten Bereitstellung basieren. Der Fernzugriff auf diese kann kompliziert sein und erfordert normalerweise ein VPN. Sie unterstützen selten mobile Apps.
Hohe Verfügbarkeit
Überwachungssoftware, die unternehmenskritische Workloads überwacht, muss von sich aus widerstandsfähig sein. Es sollten Vorkehrungen getroffen werden, um Katastrophensituationen zu bewältigen, die die Überwachungsstruktur möglicherweise offline schalten. Dies sollte auch aus Architektur- und Kostensicht betrachtet werden.
SaaS-Lösungen
Datenerhebungsprozess
Obwohl ein SaaS-Angebot hauptsächlich gehostet wird, wird es häufig einen lokalen Datensammler für lokale Workloads unterhalten. Dies trägt dazu bei, Leistungs- und Sicherheitseinschränkungen zu beheben. Auf diese Weise werden alle Verbindungen auf Instanzebene über den lokalen Kollektor hergestellt, der dann die überwachten Datenbankleistungsdaten an den Cloud-Eingangsdienst weiterleitet. Alle Daten sollten während der Übertragung verschlüsselt werden.
Diagnose- und Berichts-/Analytics-Repositories
Die gute Nachricht hier ist, dass der SaaS-Anbieter Ihren gesamten Datenspeicher verwaltet. Sie müssen sich keine Gedanken über das Einrichten von Instanzen für die Diagnose-Repositorys, das Melden von Repositorys, das Leeren des Diagnose-Repositorys oder viele andere Probleme machen, die mit einer lokalen Bereitstellung verbunden sind.
Gehostete Lösungen werden im Back-End auf verschiedene Speicherstrategien zurückgreifen, um gegebenenfalls eine Mischung aus Transaktions- und Analyseaktivitäten zu ermöglichen. Sie können auf Cloud-Ressourcen zurückgreifen, um größere Datenmengen und die für Analysen erforderliche Verarbeitung zu bewältigen; B. speichert Spotlight Cloud detaillierte Daten für ein Jahr. So können Sie nicht nur ein Jahr zurückmelden, sondern auch Ihre Arbeitsbelastung bis zu einem Jahr in die Vergangenheit zurückspielen. Dies ist eine wirklich mächtige Fähigkeit.
Eine SaaS-Lösung für die Überwachung der Datenbankleistung kann eine Vielzahl von Back-End-Speicherstrategien verwenden, um nicht nur der eher transaktionalen Art der Diagnose und Überwachung gerecht zu werden, sondern auch um die hochintensive Zahlenverarbeitung zu erleichtern, die mit langfristigen Analysen verbunden ist. Der SaaS-Anbieter kann erhebliche Skaleneffekte nutzen, um eine weitaus leistungsfähigere Infrastruktur zu nutzen, die einzelnen Organisationen zur Verfügung stünde.
So skalieren Sie eine SaaS-Lösung
Die Skalierung einer SaaS-Lösung liegt in der Verantwortung des Anbieters und nicht des Benutzers. Jede SaaS-Lösung für die Überwachung der Datenbankleistung muss vom ersten Tag an skalierbar sein und kommt daher in der Regel problemlos mit der Skalierung zurecht.
Benutzererfahrung
SaaS-Anwendungen verwenden standardmäßig eine Browser-Ux und viele werden auch umfassende mobile Apps haben. Dies erleichtert verteilte und entfernte Teams.
Sicherheit und Compliance
Die meisten SaaS-Lösungen werden auf einer der führenden Cloud-Infrastrukturen wie Azure oder Amazon aufbauen. Viele der führenden Anbieter verfügen über ausgeklügelte Sicherheitsinfrastrukturen. Sie investieren stark in die Unterstützung der Compliance-Anforderungen ihrer Kunden.
Hohe Verfügbarkeit
Die gute Nachricht ist auch hier, dass dies in der Verantwortung des Anbieters liegt. Es lohnt sich, bei Ihrem Anbieter nachzufragen, welche Vorkehrungen er in Bezug auf Failover und Hochverfügbarkeit getroffen hat. SaaS-Anwendungen sollten so konzipiert sein, dass sie sehr widerstandsfähig sind. Die verschiedenen Dienste, aus denen eine SaaS-Anwendung besteht, sind in der Regel so konzipiert, dass sie individuell belastbar sind. Es können auch Vorkehrungen für Rechenzentrumsausfälle getroffen werden, bei denen die Anwendung im Falle eines Rechenzentrumsausfalls von einem Rechenzentrum auf ein anderes übergehen würde.
