Erstellen und Konfigurieren eines Datenbankwatchers (Vorschau)

Gilt für: Azure SQL-Datenbank Azure SQL Managed Instance

Dieser Artikel enthält detaillierte Schritte zum Erstellen, Konfigurieren und Starten eines Datenbank-Watchers im Azure-Portal für Azure SQL-Datenbank und Azure SQL Managed Instance.

Für den Datenbankwatcher müssen Sie keine Überwachungs-Agents oder andere Überwachungsinfrastrukturen bereitstellen und unterhalten. Sie können die detaillierte Datenbanküberwachung Ihrer Azure SQL-Ressourcen in wenigen Minuten aktivieren.

Ein vereinfachtes Schritt-für-Schritt-Beispiel zum Erstellen und Konfigurieren eines Datenbank-Watchers finden Sie unter Schnellstart: Erstellen eines Datenbank-Watchers zum Überwachen von Azure SQL.

Informationen zum Erstellen und Konfigurieren eines Datenbank-Watchers mit Bicep oder einer ARM-Vorlage finden Sie im Codebeispiel unter Erstellen eines Datenbank-Watchers.

Informationen zum programmgesteuerten Verwalten von Datenbank-Watchern finden Sie in der Dokumentation zur Datenbanküberwachungs-REST-API.

Voraussetzungen

Für den Einsatz des Datenbankwatchers müssen die folgenden Voraussetzungen erfüllt sein.

• Sie brauchen ein aktives Azure-Abonnement. Falls Sie nicht über ein Abonnement verfügen, können Sie ein kostenloses Konto erstellen. Sie müssen Mitglied der Rolle Mitwirkender oder Besitzer sein, damit das Abonnement oder eine Ressourcengruppe Ressourcen erstellen kann.

• Zum Konfigurieren und Starten eines Datenbank-Watchers benötigen Sie ein vorhandenes SQL-Ziel: eine Azure SQL-Datenbank, einen Pool für elastische Datenbanken oder eine verwaltete SQL-Instanz.

  • Wenn Sie noch keine Azure SQL-Datenbank erstellt haben, rufen Sie Schnellstart: Erstellen einer einzelnen Datenbank auf. Suchen Sie nach der Option, ihr Angebot zu verwenden, um Azure SQL-Datenbank (Vorschau) kostenlos zu testen.
  • Gehen Sie alternativ zu Azure SQL Managed Instance kostenlos testen (Vorschau).

• Die Ressourcenanbieter Microsoft.DatabaseWatcher, Microsoft.Kusto und Microsoft.Network müssen für Ihr Azure-Abonnement registriert sein.

  • Zum Verwenden der SQL-Authentifizierung für Verbindungen mit Ihren Azure SQL-Ressourcen muss auch der Ressourcenanbieter Microsoft.KeyVault registriert sein. Siehe Zusätzliche Konfiguration zur Verwendung der SQL-Authentifizierung.

  Der Ressourcenanbieter wird automatisch registriert, wenn der Besitzer oder Mitwirkende auf Abonnentebene Mitglieder der RBAC-Rolle sind. Andernfalls muss ein Benutzer mit einer dieser Rollen die Ressourcenanbieter registrieren, bevor Sie einen Watcher erstellen und konfigurieren können. Weitere Informationen finden Sie unter Registrieren des Ressourcenanbieters.

• Der Benutzer, der den Watcher erstellt und konfiguriert, und die Azure Data Explorer-Clusterressourcen müssen Mitglied der RBAC-Rolle Besitzer oder Mitwirkender für die Ressourcengruppe oder das Abonnement sein, wo diese Ressourcen erstellt werden.

  Darüber hinaus muss der Benutzer bei Verwendung der SQL-Authentifizierung entweder Mitglied der Rolle Besitzer für die Ressourcengruppe sein oder Mitglied der Rolle Besitzer oder Benutzerzugriffsadministrator für den Schlüsseltresor, in dem die Anmeldedaten für die SQL-Authentifizierung gespeichert werden.

• Der Benutzer, der die Überwachung konfiguriert, muss über Administratorzugriff auf die Azure SQL-Ziele verfügen. Ein Administrator erteilt dem Watcher eingeschränkten, spezifischen Zugriff auf die SQL-Überwachungsziele. Weitere Informationen finden Sie unter Gewähren des Zugriffs auf Ziele.

• Um einem Watcher Zugriff auf ein SQL-Ziel zu erteilen, muss ein Administrator T-SQL-Skripts mit SQL Server Management Studio (SSMS), Azure Data Studio oder Visual Studio Code mit der Erweiterung SQL Server mssql ausführen.

• Zur Verwendung von Azure Private Link für private Verbindungen mit Azure-Ressourcen muss der Benutzer, der den privaten Endpunkt genehmigt, Mitglied der RBAC-Rolle Besitzer sein oder über die erforderlichen RBAC-Berechtigungen verfügen. Weitere Informationen finden Sie unter Rollenbasierte Zugriffssteuerung (RBAC) für private Endpunkte genehmigen.

Erstellen eines Watchers

1. Wählen Sie im Azure-Portal im Navigationsmenü Alle Dienste aus. Wählen Sie Überwachen als Kategorie und wählen Sie unter Überwachungstools die Option Datenbankwatcher aus. Alternativ können Sie Datenbankwatcher in das Suchfeld oben auf der Portalseite eingeben und Datenbankwatcher auswählen.

   Wenn sich die Ansicht Datenbankwatcher öffnet, wählen Sie Erstellen aus.

2. Wählen Sie in der Registerkarte Allgemeine Informationen das Abonnement und die Ressourcengruppe für den Watcher aus, geben Sie den Namen des Watchers ein und wählen Sie eine Azure-Region aus.

   Tipp

   Wenn der Datenbankwatcher während der Vorschau in Ihrer Region noch nicht verfügbar ist, können Sie ihn in einer anderen Region erstellen. Weitere Informationen finden Sie unter Regionale Verfügbarkeit.

3. Auf der Registerkarte Identität wird die systemseitig zugewiesene verwaltete Identität der Überwachung standardmäßig aktiviert. Wenn die Überwachung stattdessen eine benutzerseitig zugewiesene verwaltete Identität verwenden soll, wählen Sie die Schaltfläche Hinzufügen aus, suchen Sie die gewünschte Identität, und wählen Sie die Schaltfläche Hinzufügen aus. Deaktivieren Sie die systemseitig zugewiesene verwaltete Identität, damit die benutzerseitig zugewiesene Identität für die Überwachung wirksam wird.

   Weitere Informationen zu verwalteten Identitäten für die Datenbanküberwachung finden Sie unter Ändern der Überwachungsidentität.

4. Wählen Sie einen Datenspeicher für den Watcher aus.

   Standardmäßig wird beim Erstellen eines Watchers auch ein Azure Data Explorer-Cluster erstellt und eine Datenbank als Datenspeicher für die erfassten Überwachungsdaten zu diesem Cluster hinzugefügt.

   • Standardmäßig verwendet der neue Azure Data Explorer-Cluster die SKU Sehr klein, für Compute optimiert. Dies ist die kostengünstigste SKU, die dennoch über ein Service Level Agreement (SLA) verfügt. Sie können diesen Cluster später nach Bedarf skalieren.

   • Sie können eine Datenbank auch in einem vorhandenen Azure Data Explorer-Cluster, in einem kostenlosen Azure Data Explorer-Cluster oder in der Echtzeitanalyse verwenden.

     1. Wählen Sie in der Registerkarte Datenspeicher die Option Datenspeicher auswählen und dann Hinzufügen aus.
     2. Wählen Sie eine Echtzeitanalyse-Datenbank oder einen Azure Data Explorer-Cluster aus.
     3. Wenn Sie über einen vorhandenen Azure Data Explorer-Cluster verfügen, müssen Sie die Streamingerfassung aktivieren.
     4. Erstellen Sie eine neue Datenbank oder verwenden Sie eine vorhandene Datenbank.

     Hinweis

     Eine von Ihnen ausgewählte vorhandene Datenbank muss leer sein oder muss eine bereits zuvor als Datenbankwatcher-Datenspeicher verwendete Datenbank sein. Das Auswählen einer Datenbank, die nicht vom Datenbankwatcher erstellte Objekte enthält, wird nicht unterstützt.

   • Alternativ können Sie das Hinzufügen eines Datenspeichers zu diesem Zeitpunkt überspringen und ihn später hinzufügen. Zum Starten des Watchers ist ein Datenspeicher erforderlich.

5. Fügen Sie in der Registerkarte SQL-Ziele eine oder mehrere zu überwachende Azure SQL-Ressourcen hinzu. Sie können das Hinzufügen von SQL-Zielen beim Erstellen des Watchers überspringen und sie später hinzufügen. Sie müssen mindestens ein Ziel hinzufügen, bevor Sie den Watcher starten.

6. Überprüfen Sie sich in der Registerkarte Überprüfen und erstellen die Konfiguration des Watchers und wählen Sie Erstellen aus. Wenn Sie die Standardoption zum Erstellen eines neuen Azure Data Explorer-Clusters auswählen, dauert die Bereitstellung in der Regel 15-20 Minuten. Wenn Sie eine Datenbank in einem vorhandenen Azure Data Explorer-Cluster, in einem kostenlosen Azure Data Explorer-Cluster oder in der Echtzeitanalyse auswählen, dauert die Bereitstellung in der Regel bis zu fünf Minuten.

7. Wenn die Bereitstellung abgeschlossen ist, müssen Sie dem Watcher Zugriff auf SQL-Ziele gewähren.

8. Möglicherweise müssen Sie der Überwachung auch Zugriff auf den Datenspeicher gewähren.

   • Der Zugriff auf eine Datenbank in einem neuen oder vorhandenen Azure Data Explorer-Cluster wird beim Erstellen des Watchers automatisch gewährt, wenn der Benutzer, der den Watcher erstellt, Mitglied der RBAC-Rolle Besitzer für den Cluster ist.
   • Sie müssen jedoch den Zugriff auf den Datenspeicher mit einem KQL-Befehl gewähren, wenn Sie eine Datenbank auswählen in:
     • Echtzeitanalysen in Microsoft Fabric
     • Ein kostenloser Azure Data Explorer-Cluster

9. Erstellen und genehmigen Sie verwaltete private Endpunkte, wenn Sie private Konnektivität verwenden möchten.

   • Wenn der öffentliche Zugriff auf Ihre SQL-Ziele, der Datenspeicher und der Schlüsseltresor aktiviert sind und Sie öffentliche Konnektivität verwenden möchten, stellen Sie sicher, dass alle Voraussetzungen für die öffentliche Konnektivität erfüllt sind.

Starten und Beenden eines Watchers

Wenn ein Watcher erstellt wird, wird er nicht automatisch gestartet, da gegebenenfalls eine zusätzliche Konfiguration erforderlich ist.

Zum Starten eines Watchers braucht er Folgendes:

• Einen Datenspeicher.
• Mindestens ein Ziel.
• Zugriff auf den Datenspeicher und die Ziele.
  • Zugriff auf einen Schlüsseltresor ist ebenfalls erforderlich, wenn die SQL-Authentifizierung für ein Ziel ausgewählt wurde.
• Entweder private oder öffentliche Konnektivität zu Zielen, zum Schlüsseltresor (bei Verwendung der SQL-Authentifizierung) und zum Datenspeicher.
  • Für private Verbindungen müssen Sie private Endpunkte erstellen.

Sobald ein Watcher vollständig konfiguriert ist, können Sie in der Übersicht über die Schaltfläche Start die Datensammlung starten. Innerhalb weniger Minuten erscheinen neue Überwachungsdaten im Datenspeicher und in Dashboards. Wenn innerhalb von fünf Minuten keine neuen Daten angezeigt werden, lesen Sie die Problembehandlung.

Sie können den Watcher über die Schaltfläche Beenden beenden, wenn Sie Ihre Azure SQL-Ressourcen einige Zeit nicht überwachen müssen.

Für den Neustart eines Watchers müssen Sie ihn beenden und dann erneut starten.

Ändern eines Watchers

Im Azure-Portal können Sie Ziele hinzufügen oder entfernen, private Endpunkte erstellen oder löschen, einen anderen Datenspeicher für eine vorhandene Überwachung verwenden oder die verwaltete Identität für die Überwachung ändern.

Hinzufügen von SQL-Zielen zu einem Watcher

Um die Überwachung durch den Datenbankwatcher für eine Azure SQL-Datenbank, einen Pool für elastische Datenbanken oder eine SQL Managed Instance zu aktivieren, müssen Sie diese Ressource als SQL-Ziel hinzufügen.

1. Wählen Sie zum Hinzufügen eines Ziels auf der Seite SQL-Ziele Hinzufügen aus.
2. Suchen Sie die Azure SQL-Ressource, die Sie überwachen möchten. Wählen Sie den Ressourcentyp und das Abonnement aus, und wählen Sie dann das SQL-Ziel aus der Liste der Ressourcen aus. Das SQL-Ziel kann sich in jedem Abonnement innerhalb desselben Microsoft Entra ID-Mandanten wie der Watcher befinden.
3. Um das primäre Replikat und ein sekundäres Replikat mit Hochverfügbarkeit einer Datenbank, einen Pool für elastische Datenbanken oder eine Instanz von SQL Managed Instance zu überwachen, fügen Sie zwei separate SQL-Ziele für dieselbe Ressource hinzu, und aktivieren Sie das Kontrollkästchen Leseabsicht für eine davon. Erstellen Sie auf ähnliche Weise zwei separate SQL-Ziele für ein Georeplikat und das sekundäre Replikat mit Hochverfügbarkeit (sofern vorhanden).
   • Durch Aktivieren des Kontrollkästchens Leseabsicht wird das SQL-Ziel ausschließlich für das hochverfügbare sekundäre Replikat konfiguriert.
   • Aktivieren Sie nicht das Kontrollkästchen Leseabsicht, wenn Sie nur das primäre Replikat oder nur das Georeplikat überwachen möchten, wenn für diese Ressource kein sekundäres Replikat mit Hochverfügbarkeit vorhanden ist oder wenn das Feature für horizontale Leseskalierung deaktiviert ist.

Zum Herstellen einer Verbindung mit SQL-Datenbank verwendet der Datenbankwatcher standardmäßig die Microsoft Entra-Authentifizierung. Wenn der Watcher die SQL-Authentifizierung verwenden soll, müssen Sie das Kontrollkästchen SQL-Authentifizierung verwenden aktivieren und die erforderlichen Details eingeben. Weitere Informationen finden Sie unter Zusätzliche Konfiguration zur Verwendung der SQL-Authentifizierung.

Entfernen von SQL-Zielen aus einem Watcher

Öffnen Sie zum Entfernen eines oder mehrerer Ziel die Seite SQL-Ziele, wählen Sie die zu entfernenden Ziele in der Liste und dann Löschen aus.

Durch das Entfernen eines Ziels wird die Überwachung für eine Azure SQL-Ressource beendet, nachdem der Watcher neu gestartet wurde, die eigentliche Ressource wird aber nicht gelöscht.

Wenn Sie eine vom Datenbankwatcher überwachte Azure SQL-Ressource löschen sollten Sie auch das entsprechende Ziel entfernen. Da die Anzahl der für einen Watcher möglichen SQL-Ziele begrenzt ist, können veraltete Ziele das Hinzufügen neuer Ziele blockieren.

Erstellen eines verwalteten privaten Endpunkts

Sie müssen verwaltete private Endpunkte erstellen, wenn Sie private Konnektivität für die Datensammlung aus SQL-Zielen, für die Aufnahme in den Datenspeicher und zum Herstellen einer Verbindung mit Schlüsseltresoren verwenden möchten. Wenn Sie keine privaten Endpunkte erstellen, verwendet der Datenbankwatcher standardmäßig öffentliche Verbindungen.

So erstellen Sie einen verwalteten privaten Endpunkt für einen Watcher:

1. Wenn eine schreibgeschützte Sperre für die Ressource, die Ressourcengruppe oder die Subscription der Ressource besteht, für die Sie den verwalteten privaten Endpunkt erstellt haben, entfernen Sie die Sperre. Sie können die Sperre wieder hinzufügen, nachdem der private Endpunkt erfolgreich erstellt wurde.

2. Navigieren Sie im Azure-Portal zu einem Datenbankwatcher, öffnen Sie die Seite Verwaltete private Endpunkte und wählen Sie Hinzufügen aus.

3. Geben Sie einen Namen für den privaten Endpunkt ein.

4. Wählen Sie das Abonnement der Azure-Ressource aus, für die Sie den privaten Endpunkt erstellen möchten.

5. Wählen Sie je nach Art der Ressource, für die Sie einen privaten Endpunkt erstellen möchten, den Ressourcentyp und die Zielunterressource wie folgt aus:

   Resource	Ressourcentyp	Zielunterressource
   Logischer Server	Microsoft.Sql/servers	sqlServer
   Verwaltete SQL-Instanz	Microsoft.Sql/managedInstances	managedInstance
   Azure Data Explorer-Cluster	Microsoft.Kusto/clusters	cluster
   Key vault	Microsoft.KeyVault/vaults	vault

6. Wählen Sie die Ressource aus, für die Sie einen privaten Endpunkt erstellen möchten. Dies kann ein logischer Azure SQL-Server, eine Instanz von SQL Managed Instance, ein Azure Data Explorer-Cluster oder ein Schlüsseltresor sein.

   • Das Erstellen eines privaten Endpunkts für einen logischen Server für Azure SQL-Datenbank aktiviert für den Datenbankwachter die private Verbindung für alle Datenbanken und Pools für elastische Datenbanken als Ziel auf diesem Server.

7. Geben Sie optional eine Beschreibung des privaten Endpunkts ein. Das kann für den Ressourcenbesitzer beim Genehmigen der Anforderung hilfreich sein.

8. Klicken Sie auf Erstellen. Es kann einige Minuten dauern, bis ein privater Endpunkt erstellt wird. Ein privater Endpunkt ist erstellt, sobald sich der Bereitstellungsstatus von Akzeptiert oder Wird ausgeführt in Erfolgreich ändert. Aktualisieren Sie die Ansicht, damit der aktuelle Bereitstellungsstatus angezeigt wird.

   Wichtig

   Der private Endpunkt wird im Status Ausstehend erstellt. Er muss vom Ressourcenbesitzer genehmigt werden, bevor er vom Datenbankwatcher zum Herstellen einer Verbindung mit der Ressource verwendet werden kann.

   Damit Ressourcenbesitzer die Netzwerkverbindung steuern können, werden private Endpunkte für den Datenbankwatcher nicht automatisch genehmigt.

9. Der Ressourcenbesitzer muss die Anforderung des privaten Endpunkts genehmigen.

   • Im Azure-Portal kann der Besitzer der Ressource nach Private Verbindung suchen, um das Private Link Center zu öffnen. Suchen Sie unter Ausstehende Verbindungen den erstellten privaten Endpunkt, bestätigen Sie seine Beschreibung und die Details und wählen Sie Genehmigen aus.
   • Sie können Anforderungen privater Endpunkte auch über Azure CLI genehmigen.

Wenn ein Watcher bereits ausgeführt wird, wenn ein privater Endpunkt genehmigt wird, muss er neu gestartet werden, um mit der Verwendung der privaten Verbindung zu beginnen.

Löschen eines verwalteten privaten Endpunkts

1. Wenn eine Löschsperre oder schreibgeschützte Sperre für die Ressource, die Ressourcengruppe oder die Subscription der Ressource besteht, für die Sie den verwalteten privaten Endpunkt löschen, entfernen Sie die Sperre. Sie können die Sperre wieder hinzufügen, nachdem der private Endpunkt erfolgreich gelöscht wurde.
2. Öffnen Sie auf der Azure-Portal-Seite für den Datenbankwatcher die Seite Verwaltete private Endpunkte.
3. Wählen Sie die zu löschenden privaten Endpunkte aus.
4. Klicken Sie auf Löschen.

Durch das Löschen eines verwalteten privaten Endpunkts wird die Datensammlung von SQL-Zielen beendet, die diesen privaten Endpunkt verwenden. Durch das Löschen des verwalteten privaten Endpunkts für den Azure Data Explorer-Cluster wird die Datensammlung für alle Ziele beendet. Um die Datensammlung fortzusetzen, müssen Sie den privaten Endpunkt neu erstellen oder öffentliche Verbindungen aktivieren und den Watcher neu starten.

Ändern des Datenspeichers für einen Watcher

Ein Watcher kann nur einen Datenspeicher haben.

Um den aktuellen Datenspeicher zu ändern, müssen Sie den vorhandenen Datenspeicher löschen und dann einen neuen Datenspeicher hinzufügen.

• Öffnen Sie zum Entfernen des aktuellen Datenspeichers die Seite Datenspeicher, wählen Sie den Datenspeicher im Raster und dann Löschen aus.

  • Durch das Entfernen eines Datenspeichers wird die eigentliche Datenspeicherdatenbank in einem Azure Data Explorer-Cluster oder in der Echtzeitanalyse in Microsoft Fabric nicht gelöscht.
  • Um die Datensammlung in einen entfernten Datenspeicher zu beenden, müssen Sie den Watcher beenden.
  • Wenn Sie einen Datenspeicher entfernen, müssen Sie einen neuen Datenspeicher hinzufügen, bevor Sie den Watcher erneut starten können.

• Wählen Sie zum Hinzufügen eines Datenspeichers auf der Seite Datenspeicher die Option Hinzufügen aus und wählen oder erstellen Sie dann eine Datenbank in einem Azure Data Explorer-Cluster oder in der Echtzeitanalyse.

  • Die von Ihnen ausgewählte Datenbank muss leer sein oder muss eine bereits zuvor als Datenbankwatcher-Datenspeicher verwendete Datenbank sein. Das Auswählen einer Datenbank, die nicht vom Datenbankwatcher erstellte Objekte enthält, wird nicht unterstützt.
  • Wenn Sie einen Datenspeicher hinzugefügt haben, müssen Sie dem Watcher Zugriff gewähren, damit er ihn verwenden kann. Weitere Informationen finden Sie unter Gewähren des Zugriffs auf den Datenspeicher.
  • Nach dem Neustart des Watchers beginnt er mit der Nutzung des neuen Datenspeichers.

Ändern der Überwachungsidentität

Eine Überwachung muss über eine verwaltete Identität verfügen, um sich bei SQL-Zielen, Schlüsseltresoren und dem Datenspeicher zu authentifizieren. Sie können entweder eine systemseitig oder eine benutzerseitig zugewiesene verwaltete Identität verwenden. Weitere Informationen zu verwalteten Identitäten in Azure finden Sie unter Was sind verwaltete Identitäten für Azure-Ressourcen?.

Die folgenden Überlegungen helfen Ihnen bei der Auswahl des Typs der verwalteten Identität für eine Überwachung:

• Vom System zugewiesen

  • Standardmäßig aktiviert, wenn Sie eine Überwachung erstellen
  • Immer einer einzelnen Überwachung zugeordnet
  • Erstellt und gelöscht mit der Überwachung
  • Wenn Sie eine systemseitig zugewiesene Identität für eine Überwachung deaktivieren, gehen alle Zugriffe verloren, die dieser Identität gewährt wurden. Durch erneutes Aktivieren der systemseitig zugewiesenen Identität für dieselbe Überwachung wird eine neue, andere Identität mit einer anderen Objekt-ID (Prinzipal-ID) erstellt. Sie müssen dieser neuen Identität Zugriff auf SQL-Ziele, Schlüsseltresor und Datenspeicher gewähren.

• Vom Benutzer zugewiesen

  • Nur wirksam, wenn die systemseitig zugewiesene Identität für die Überwachung deaktiviert ist
  • Dieselbe benutzerseitig zugewiesene Identität kann mehreren Überwachungen zugewiesen werden, um die Zugriffsverwaltung zu vereinfachen, z. B. bei der Überwachung großer Azure SQL-Landschaften. Anstatt den systemseitig zugewiesenen Identitäten mehrerer Überwachungen den Zugriff zu gewähren, kann dieser auch einer einzelnen benutzerseitig zugewiesenen Identität gewährt werden.
  • Um die Aufgabentrennung zu unterstützen, kann die Identitätsverwaltung von der Überwachungsverwaltung getrennt werden. Eine benutzerseitig zugewiesene Identität kann vor oder nach der Erstellung der Überwachung von anderen Benutzenden erstellt und gewährt werden.
  • Wenn eine Überwachung hingegen gelöscht wird, bleiben die benutzerseitig zugewiesene Identität und ihr Zugriff unverändert. Dieselbe Identität kann dann für eine neue Überwachung verwendet werden.
  • Das Angeben mehrerer benutzerseitig zugewiesener Identitäten für eine Überwachung wird nicht unterstützt.

Um die verwaltete Identität für eine Überwachung zu ändern, öffnen Sie die Seite Identität der Überwachung.

• Um eine systemseitig zugewiesene Identität zu verwenden, aktivieren Sie den Umschalter Systemseitig zugewiesene Identität.

• Um eine benutzerseitig zugewiesene Identität zu verwenden, deaktivieren Sie den Umschalter Systemseitig zugewiesene Identität. Wählen Sie die Schaltfläche Hinzufügen aus, um eine vorhandene benutzerseitig zugewiesene Identität zu suchen und hinzuzufügen.

  Weitere Informationen zum Erstellen einer benutzerseitig zugewiesenen Identität finden Sie unter Erstellen einer benutzerseitig zugewiesenen verwalteten Identität.

• Wenn Sie eine benutzerseitig zugewiesene Identität aus einer Überwachung entfernen möchten, wählen Sie sie in der Liste aus, und wählen Sie dann Entfernen aus. Nachdem eine benutzerseitig zugewiesene Identität entfernt wurde, müssen Sie entweder eine andere benutzerseitig zugewiesene Identität hinzufügen oder die systemseitig zugewiesene Identität aktivieren.

  Die entfernte benutzerseitig zugewiesene Identität wird nicht aus dem Microsoft Entra ID-Mandanten gelöscht.

Wählen Sie die Schaltfläche Speichern aus, um Identitätsänderungen zu speichern. Sie können keine Identitätsänderungen speichern, wenn dies dazu führen würde, dass die Überwachung über keine Identität mehr verfügt. Überwachungen ohne gültige verwaltete Identität werden nicht unterstützt.

Kurz nach dem Speichern von Identitätsänderungen stellt die Überwachung erneut eine Verbindung mit SQL-Zielen, Schlüsseltresoren (sofern verwendet) und dem Datenspeicher unter Verwendung ihrer aktuellen verwalteten Identität her.

Löschen eines Watchers

Wenn eine Löschsperre oder schreibgeschützte Sperre für den Watcher, seine Ressourcengruppe oder sein Abonnement vorhanden ist, entfernen Sie die Sperre. Sie können die Sperre wieder hinzufügen, nachdem der Watcher erfolgreich gelöscht wurde.

Wenn Sie eine Überwachung mit aktivierter systemseitig zugewiesener verwalteter Identität löschen, wird die Identität ebenfalls gelöscht. Dadurch wird jeder Zugriff, den Sie dieser Identität gewährt haben, entfernt. Wenn Sie die Überwachung später erneut erstellen, müssen Sie der systemseitig zugewiesenen verwalteten Identität der neuen Überwachung Zugriff gewähren, damit sie sich bei den einzelnen Ressource authentifizieren kann. Dies umfasst:

• Targets
• Der Datenspeicher
• Und der Schlüsseltresor (sofern verwendet)

Sie müssen einem neu erstellten Watcher auch dann Zugriff gewähren, wenn Sie denselben Watchernamen verwenden.

Wenn Sie eine Überwachung löschen, werden die Azure-Ressourcen, auf die als SQL-Ziele verwiesen wird, und der Datenspeicher nicht gelöscht. Die gesammelten SQL-Überwachungsdaten bleiben im Datenspeicher erhalten, und Sie können dieselbe Azure Data Explorer- oder Echtzeitanalyse-Datenbank als Datenspeicher verwenden, wenn Sie später einen neuen Watcher erstellen.

Gewähren des Zugriffs auf SQL-Ziele

Damit ein Watcher SQL-Überwachungsdaten erfassen kann, müssen Sie ein T-SQL-Skript ausführen, das dem Watcher spezifische, eingeschränkte SQL-Berechtigungen gewährt.

• Zum Ausführen des Skripts in Azure SQL-Datenbank benötigen Sie Serveradministrator-Zugriff auf den logischen Server mit den zu überwachenden Datenbanken und Pools für elastische Datenbanken.

  • In Azure SQL-Datenbank müssen Sie das Skript nur einmal pro logischem Server für jeden von Ihnen erstellten Watcher ausführen. Dies gewährt dem Watcher Zugriff auf alle vorhandenen und neuen Datenbanken und Pools für elastische Datenbanken auf diesem Server.

• Zum Ausführen des Skripts in Azure SQL Managed Instance müssen Sie Mitglied der Serverolle sysadmin oder securityadmin sein oder über die Serverberechtigung CONTROL für die SQL Managed Instance verfügen.

  • In Azure SQL Managed Instance müssen Sie das Skript für jede zu überwachende Instanz ausführen.

1. Navigieren Sie im Azure-Portal zum Watcher, wählen Sie SQL-Ziele aus, wählen Sie einen der Links Zugriff gewähren aus, um das T-SQL-Skript zu öffnen, und kopieren Sie das Skript. Achten Sie darauf, dass Sie den richtigen Link für Ihren Zieltyp und den Authentifizierungstyp auswählen, den Sie verwenden möchten.

   Wichtig

   Das Microsoft Entra-Authentifizierungsskript im Azure-Portal ist spezifisch für die jeweilige Überwachung, da es den Namen ihrer verwalteten Identität enthält. Eine generische Version dieses Skripts, die Sie für jeden Watcher anpassen können, finden Sie unter Gewähren des Zugriffs auf SQL-Ziele mit T-SQL-Skripts.

2. Öffnen Sie in SQL Server Management Studio, Azure Data Studio oder einem anderen SQL-Clienttool ein neues Abfragefenster und verbinden Sie es mit der master-Datenbank auf einem logischen Azure SQL-Server, der das Ziel enthält, oder mit der master-Datenbank auf einem SQL Managed Instance-Ziel.

3. Fügen Sie das T-SQL-Skript ein und führen Sie es aus, um dem Watcher Zugriff zu gewähren. Das Skript erstellt eine Anmeldung, die der Watcher zum Herstellen einer Verbindung verwendet, und gewährt bestimmte, eingeschränkte Berechtigungen zum Erfassen von Überwachungsdaten.

   1. Wenn Sie ein Microsoft Entra-Authentifizierungsskript verwenden und die Überwachung die systemseitig zugewiesene verwaltete Identität verwendet, muss die Überwachung bereits vor der Ausführung des Skripts erstellt worden sein. Wenn die Überwachung eine benutzerseitig zugewiesene verwaltete Identität verwendet, können Sie das Skript vor oder nach dem Erstellen der Überwachung ausführen.

   Sie benötigen eine Verbindung mit der Microsoft Entra-Authentifizierung, wenn Sie die T-SQL-Zugriffsskripts ausführen, die einer verwalteten Identität Zugriff gewähren.

Wenn Sie einem Watcher später neue Ziele hinzufügen, müssen Sie auf gleiche Weise Zugriff auf diese Ziele gewähren, es sei denn, diese Ziele befinden sich auf einem logischen Server, für den der Zugriff bereits gewährt wurde.

Gewähren des Zugriffs auf SQL-Ziele mit T-SQL-Skripts

Es gibt unterschiedliche Skripts für die Microsoft Entra-Authentifizierung und SQL-Authentifizierung sowie für Azure SQL-Datenbank- und Azure SQL Managed Instance-Ziele.

Ersetzen Sie vor dem Ausführen eines Skripts sämtliche im Skript gegebenenfalls vorhanden Platzhalter wie login-name-placeholder und password-placeholder durch die tatsächlichen Werte.

Gewähren des Zugriffs für mit Microsoft Entra authentifizierte Watcher

CREATE LOGIN [identity-name-placeholder] FROM EXTERNAL PROVIDER;

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [identity-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [identity-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [identity-name-placeholder];

USE master;

CREATE LOGIN [identity-name-placeholder] FROM EXTERNAL PROVIDER;

GRANT CONNECT SQL, CONNECT ANY DATABASE, VIEW ANY DATABASE, VIEW ANY DEFINITION, VIEW SERVER PERFORMANCE STATE TO [identity-name-placeholder];

USE msdb;

CREATE USER [identity-name-placeholder] FOR LOGIN [identity-name-placeholder];

GRANT SELECT ON dbo.sysjobactivity TO [identity-name-placeholder];
GRANT SELECT ON dbo.sysjobs TO [identity-name-placeholder];
GRANT SELECT ON dbo.syssessions TO [identity-name-placeholder];
GRANT SELECT ON dbo.sysjobhistory TO [identity-name-placeholder];
GRANT SELECT ON dbo.sysjobsteps TO [identity-name-placeholder];
GRANT SELECT ON dbo.syscategories TO [identity-name-placeholder];
GRANT SELECT ON dbo.sysoperators TO [identity-name-placeholder];
GRANT SELECT ON dbo.suspect_pages TO [identity-name-placeholder];
GRANT SELECT ON dbo.backupset TO [identity-name-placeholder];
GRANT SELECT ON dbo.backupmediaset TO [identity-name-placeholder];
GRANT SELECT ON dbo.backupmediafamily TO [identity-name-placeholder];

Gewähren des Zugriffs für mit SQL authentifizierte Watcher

Bei Verwendung der SQL-Authentifizierung sind weitere Schritte erforderlich, siehe Zusätzliche Konfiguration zur Verwendung der SQL-Authentifizierung.

CREATE LOGIN [login-name-placeholder] WITH PASSWORD = 'password-placeholder';

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [login-name-placeholder];

USE master;

CREATE LOGIN [login-name-placeholder] WITH PASSWORD = 'password-placeholder';

GRANT CONNECT SQL, CONNECT ANY DATABASE, VIEW ANY DATABASE, VIEW ANY DEFINITION, VIEW SERVER PERFORMANCE STATE TO [login-name-placeholder];

USE msdb;

CREATE USER [login-name-placeholder] FOR LOGIN [login-name-placeholder];

GRANT SELECT ON dbo.sysjobactivity TO [login-name-placeholder];
GRANT SELECT ON dbo.sysjobs TO [login-name-placeholder];
GRANT SELECT ON dbo.syssessions TO [login-name-placeholder];
GRANT SELECT ON dbo.sysjobhistory TO [login-name-placeholder];
GRANT SELECT ON dbo.sysjobsteps TO [login-name-placeholder];
GRANT SELECT ON dbo.syscategories TO [login-name-placeholder];
GRANT SELECT ON dbo.sysoperators TO [login-name-placeholder];
GRANT SELECT ON dbo.suspect_pages TO [login-name-placeholder];
GRANT SELECT ON dbo.backupset TO [login-name-placeholder];
GRANT SELECT ON dbo.backupmediaset TO [login-name-placeholder];
GRANT SELECT ON dbo.backupmediafamily TO [login-name-placeholder];

Zusätzliche Konfiguration zur Verwendung der SQL-Authentifizierung

Zur sicheren Speicherung der Anmeldedaten für die Authentifizierung bei Verwendung der SQL-Authentifizierung im Datenbankwatcher ist eine zusätzliche Konfiguration erforderlich.

Gehen Sie folgendermaßen vor, um den Datenbankwatcher so zu konfigurieren, dass er die Verbindung mit einem Ziel mithilfe der SQL-Authentifizierung herstellt:

1. Erstellen Sie einen Tresor in Azure Key Vault oder bestimmen Sie einen vorhandenen Tresor, den Sie verwenden können. Der Tresor muss das RBAC-Berechtigungsmodell verwenden. Das RBAC-Berechtigungsmodell ist die Standardeinstellung für neue Tresore. Wenn Sie einen vorhandenen Tresor verwenden möchten, stellen Sie sicher, dass er nicht für die Verwendung des älteren Zugriffsrichtlinienmodells konfiguriert ist.

   Wenn Sie eine private Verbindung mit dem Tresor verwenden möchten, müssen Sie auf der Seite Verwaltete private Endpunkte einen privaten Endpunkt erstellen. Wählen Sie Microsoft.KeyVault/vaults als Ressourcentyp und vault als Zielunterressource aus. Stellen Sie sicher, dass sich der private Endpunkt genehmigt ist, bevor Sie den Watcher starten.

   Wenn Sie öffentliche Konnektivität nutzen möchten, muss der Tresor öffentlichen Zugriff von allen Netzwerken aus zulassen. Das Einschränken der öffentlichen Verbindung des Tresors auf bestimmte Netzwerke wird im Datenbankwatcher nicht unterstützt.

2. Erstellen Sie eine Anmeldung für die SQL-Authentifizierung auf allen logischen Azure SQL-Servern oder verwalteten Instanzen, die Sie überwachen möchten, und erteilen Sie die spezifischen, eingeschränkten Berechtigungen mit den bereitgestellten Zugriffsskripts. Ersetzen Sie die Platzhalter für den Anmeldenamen und das Kennwort im Skript durch die tatsächlichen Werte. Verwenden Sie ein sicheres Kennwort.

3. Erstellen Sie im Tresor zwei Geheimnisse: ein Geheimnis für den Anmeldenamen und ein separates Geheimnis für das Kennwort. Verwenden Sie einen gültigen Namen als Namen des Geheimnisses, und geben Sie den Anmeldenamen und das Kennwort aus dem T-SQL-Skript als Wert der einzelnen Geheimnisse ein.

   Die Namen der beiden Geheimnisse könnten z. B. database-watcher-login-name und database-watcher-password lauten. Die Werte der Geheimnisse wären ein Anmeldename und ein sicheres Kennwort.

   Zum Erstellen von Geheimnissen müssen Sie Mitglied der RBAC-Rolle Key Vault-Geheimnisbeauftragter sein.

4. Fügen Sie ein SQL-Ziel einem Watcher hinzu. Aktivieren Sie beim Hinzufügen des Ziels das Kontrollkästchen SQL-Authentifizierung verwenden, und wählen Sie den Tresor aus, in dem die Geheimnisse für den Anmeldename und das Kennwort gespeichert sind. Geben Sie die Namen der Geheimnisse für den Anmeldenamen und das Kennwort in den entsprechenden Feldern ein.

   Geben Sie beim Hinzufügen eines SQL-Ziels nicht den tatsächlichen Anmeldenamen und das Kennwort ein. Im vorangehenden Beispiel würden Sie die Namen database-watcher-login-name und database-watcher-password der Geheimnisse eingeben.

5. Wenn Sie im Azure-Portal ein SQL-Ziel hinzufügen, erhält die verwaltete Identität der Überwachung automatisch den erforderlichen Zugriff auf die Geheimnisse im Schlüsseltresor, sofern die aktuellen Benutzenden Mitglied der Rolle Besitzer oder der Benutzerzugriffsadministrator für den Schlüsseltresor sind. Führen Sie andernfalls den nächsten Schritt aus, um den erforderlichen Zugriff manuell zu gewähren.

6. Fügen Sie auf der Seite Access control (IAM) jedes Geheimnisses eine Rollenzuweisung für die verwaltete Identität des Watchers in der RBAC-Rolle Key Vault-Geheimnisbenutzer hinzu. Nach dem Prinzip der geringsten Rechte sollten Sie diese Rollenzuweisung für jedes Geheimnis hinzufügen und nicht für den gesamten Tresor. Die Zugriffssteuerungsseite (IAM) wird nur angezeigt, wenn der Tresor für die Verwendung des RBAC-Berechtigungsmodells konfiguriert ist.

Wenn Sie für verschiedene SQL-Ziele unterschiedliche Anmeldedaten für die SQL-Authentifizierung verwenden möchten, müssen Sie mehrere Geheimnispaare erstellen. Die Geheimnisse für die einzelnen SQL-Ziele können Sie im selben Tresor oder in verschiedenen Tresoren speichern.

Gewähren des Zugriffs auf den Datenspeicher

Zum Erstellen und Verwalten des Datenbankschemas im Datenspeicher und zum Erfassen von Überwachungsdaten ist für den Datenbank-Watcher die Mitgliedschaft in der RBAC-Rolle Admins in der Datenspeicherdatenbank in einem Azure Data Explorer-Cluster oder in der Echtzeitanalyse erforderlich. Der Datenbankwatcher benötigt keinen Zugriff auf Clusterebene auf den Azure Data Explorer-Cluster oder Zugriff auf andere, im selben Cluster eventuell vorhandene Datenbanken.

Wenn Sie als Datenspeicher eine Datenbank in einem Azure Data Explorer-Cluster verwenden, wird dieser Zugriff automatisch gewährt, wenn Sie Mitglied der RBAC-Rolle Besitzer für den Cluster sind. Andernfalls muss der Zugriff wie in diesem Abschnitt beschrieben gewährt werden.

Wenn Sie eine Datenbank bei der Echtzeitanalyse oder in einem kostenlosen Azure Data Explorer-Cluster verwenden, müssen Sie den Zugriff mit KQL gewähren.

Gewähren des Zugriffs auf eine Azure Data Explorer-Datenbank über das Azure-Portal

Den Zugriff auf eine Datenbank im Azure Data Explorer-Cluster können Sie über das Azure-Portal gewähren:

1. Wählen Sie für eine Datenbank in einem Azure Data Explorer-Cluster im Ressourcenmenü unter Sicherheit und Netzwerkbetrieb die Option Berechtigungen aus. Verwenden Sie nicht die Seite Berechtigungen des Clusters.
2. Wählen Sie Hinzufügen und dann Admin aus.
3. Wählen Sie auf der Seite Neue Prinzipale die Option Unternehmensanwendungen aus. Wenn die Überwachung die systemseitig zugewiesene verwaltete Identität verwendet, geben Sie den Namen der Überwachung in das Suchfeld ein. Wenn die Überwachung eine benutzerseitig zugewiesene verwaltete Identität verwendet, geben Sie den Anzeigenamen dieser Identität in das Suchfeld ein.
4. Wählen Sie die Unternehmensanwendung für die verwaltete Identität der Überwachung aus.

Gewähren des Zugriffs auf eine Azure Data Explorer-Datenbank mit KQL

Statt über das Azure-Portal können Sie den Zugriff auf die Datenbank auch mithilfe eines KQL-Befehls gewähren. Gewähren Sie nach dieser Methode den Zugriff auf eine Datenbank in der Echtzeitanalyse oder in einem kostenlosen Azure Data Explorer-Cluster.

1. Stellen Sie über den Kusto-Explorer oder die Web-Benutzeroberfläche des Azure Data Explorers eine Verbindung zu einer Datenbank her.

2. Im folgenden KQL-Beispielbefehl müssen Sie die drei Platzhalter ersetzen, wie in der Tabelle angemerkt:

   .add database [adx-database-name-placeholder] admins ('aadapp=identity-principal-id-placeholder;tenant-primary-domain-placeholder');
   

   Platzhalter	Ersatz
   adx-database-name-placeholder	Der Name einer Datenbank in einem Azure Data Explorer-Cluster oder in der Echtzeitanalyse.
   identity-principal-id-placeholder	Sie finden die Prinzipal-ID einer verwalteten Identität (GUID) auf der Seite Identität der Überwachung. Wenn die systemseitig zugewiesene Identität aktiviert ist, verwenden Sie deren Prinzipal-ID. Verwenden Sie andernfalls die Prinzipal-ID der benutzerseitig zugewiesenen Identität.
   tenant-primary-domain-placeholder	Der Domänenname des Microsoft Entra ID-Mandanten der verwalteten Identität der Überwachung Dieser ist in der Übersicht für Microsoft Entra ID im Azure-Portal zu finden. Anstelle der primären Mandantendomäne kann auch der GUID-Wert der Mandanten-ID verwendet werden. Dieser Teil des Befehls ist erforderlich, wenn Sie eine Datenbank bei der Echtzeitanalyse oder in einem kostenlosen Azure Data Explorer-Cluster verwenden. Der Domänenname oder die Mandanten-ID (und das vorangestellte Semikolon) kann für eine Datenbank in einem Azure Data Explorer-Cluster weggelassen werden, da sich der Cluster immer im selben Microsoft Entra ID-Mandanten wie die verwaltete Identität der Überwachung befindet.

   Zum Beispiel:

   .add database [watcher_data_store] admins ('aadapp=9da7bf9d-3098-46b4-bd9d-3b772c274931;contoso.com');
   

Weitere Informationen finden Sie unter Rollenbasierte Zugriffssteuerung mit Kusto.

Gewähren des Zugriffs auf den Datenspeicher für Benutzer und Gruppen

Sie können das Azure-Portal oder einen KQL-Befehl verwenden, um Benutzern und Gruppen Zugriff auf eine Datenbank in einem Azure Data Explorer-Cluster oder in Real-Time Analytics zu gewähren. Um Zugriff zu gewähren, müssen Sie Mitglied der Administrator-RBAC-Rolle in der Datenbank sein.

Gewähren Sie KQL-Befehl den Zugriff auf eine Datenbank in einem kostenlosen Azure Data Explorer-Cluster oder in der Echtzeitanalyse. Nach dem Prinzip der geringstmöglichen Rechte sollten Sie Benutzer*innen und Gruppen keiner anderen RBAC-Rolle als Viewer hinzufügen.

Gewähren des Zugriffs auf den Datenspeicher über das Azure-Portal

Sie können Benutzern und Gruppen den Zugriff auf eine Datenbank im Azure Data Explorer-Cluster über das Azure-Portal gewähren:

1. Wählen Sie für eine Datenbank in einem Azure Data Explorer-Cluster im Ressourcenmenü unter Sicherheit und Netzwerkbetrieb die Option Berechtigungen aus. Verwenden Sie nicht die Seite Berechtigungen des Clusters.
2. Wählen Sie Hinzufügen und dann Viewer aus.
3. Geben Sie auf der Seite Neue Prinzipale den Namen des Benutzers oder der Gruppe in das Suchfeld ein.
4. Wählen Sie den Benutzer oder die Gruppe aus.

Gewähren des Zugriffs auf den Datenspeicher mit KQL

Statt über das Azure-Portal können Sie Benutzern und Gruppen den Zugriff auf die Datenbank auch mithilfe eines KQL-Befehls gewähren. Die folgenden Beispiel-KQL-Befehle gewähren den Lesezugriff auf Daten für den Benutzer mary@contoso.com und die Gruppe SQLMonitoringUsers@contoso.com in einem Microsoft Entra ID-Mandanten mit einem bestimmten Mandanten-ID-Wert:

.add database [watcher_data_store] viewers ('aaduser=mary@contoso.com');

.add database [watcher_data_store] viewers ('aadgroup=SQLMonitoringUsers@contoso.com;8537e70e-7fb8-43d3-aac5-8b30fb3dcc4c');

Weitere Informationen finden Sie unter Rollenbasierte Zugriffssteuerung mit Kusto.

Um Benutzern und Gruppen aus einem anderen Mandanten Zugriff auf den Datenspeicher zu gewähren, müssen Sie die mandantenübergreifende Authentifizierung in Ihrem Azure Data Explorer-Cluster aktivieren. Weitere Informationen finden Sie unter Zulassen von mandantenübergreifenden Abfragen und Befehlen.

Verwalten des Datenspeichers

Dieser Abschnitt beschreibt die Möglichkeiten zum Verwalten des Überwachungsdatenspeichers, einschließlich Skalierung, Datenaufbewahrung und sonstiger Konfigurationen. Die Überlegungen zur Clusterskalierung in diesem Abschnitt sind im Fall einer Datenbank im Azure Data Explorer-Cluster relevant. Im Fall einer Datenbank in der Echtzeitanalyse in Fabric wird die Skalierung automatisch verwaltet.

Skalierung eines Azure Data Explorer-Clusters

Sie können Ihren Azure Data Explorer-Cluster nach Bedarf skalieren. Sie können Ihren Cluster z. B. auf die SKU Sehr klein Dev/Test herunterskalieren, wenn keine Vereinbarung zum Service Level (SLA) erforderlich ist und wenn die Abfrage- und Datenerfassungsleistung akzeptabel bleibt.

Bei vielen Datenbankwatcherbereitstellungen ist die standardmäßige SKU Sehr klein, für Compute optimiert mit 2 Instanzen auf unbestimmte Zeit ausreichend. In einigen Fällen müssen Sie entsprechend den im Lauf der Zeit erfolgten Änderungen von Konfiguration und Workload ihren Cluster skalieren, um eine angemessene Abfrageleistung und eine geringe Datenerfassungslatenz zu gewährleisten.

Azure Data Explorer unterstützt die vertikale und horizontale Clusterskalierung. Durch vertikales Skalieren ändern Sie die Cluster-SKU, wodurch sich die Anzahl der vCPUs, der Arbeitsspeicher und der Zwischenspeicher pro Instanz (Knoten) ändert. Durch horizontales Skalieren bleibt die SKU gleich, aber die Anzahl der Instanzen im Cluster wird erhöht oder verringert.

Wenn Sie eines oder mehrere der folgenden Symptome bemerken, müssen Sie den Cluster horizontal oder vertikal (hoch) skalieren:

• Die Leistung von Dashboard- oder Ad-hoc-Abfragen wird zu langsam.
• Sie führen viele gleichzeitige Abfragen auf Ihrem Cluster aus und stellen Drosselungsfehler fest.
• Die Datenerfassungslatenz ist durchweg höher als akzeptabel.

Im Allgemeinen müssen Sie Ihren Cluster nicht skalieren, wenn die Datenmenge im Datenspeicher im Lauf der Zeit zunimmt. Dies liegt daran, dass Dashboardabfragen und die gängigsten analytischen Abfragen nur die neuesten Daten verwenden, die im lokalen SSD-Speicher auf Clusterknoten zwischengespeichert sind.

Wenn Sie jedoch analytische Abfragen ausführen, die sich auf längere Zeitbereiche erstrecken, können sie mit der Zeit langsamer werden, weil Gesamtumfang der gesammelten Daten zunimmt und nicht mehr in den lokalen SSD-Speicher passt. In diesem Fall kann für eine angemessene Abfrageleistung eine Skalierung des Clusters erforderlich sein.

• Wenn Sie den Cluster skalieren müssen, empfehlen wir zunächst eine horizontale Skalierung, um die Anzahl der Instanzen zu erhöhen. Dadurch bleibt der Cluster während des Skalierungsprozesses für Abfragen und die Erfassung verfügbar.

  • Sie können die optimierte Autoskalierung aktivieren, damit die Anzahl der Instanzen infolge von Änderungen der Workload oder saisonalen Trends automatisch verringert oder erhöht wird.

• Sie werden vielleicht feststellen, dass manche Abfragen auch nach dem horizontalen Skalieren des Clusters immer noch nicht erwartungsgemäß ausgeführt werden. Dies kann der Fall sein, wenn die Abfrageleistung an die in einer Instanz (Knoten) des Clusters verfügbaren Ressourcen gebunden ist. In diesem Fall müssen Sie den Cluster vertikal hochskalieren.

  • Die vertikale Clusterskalierung dauert mehrere Minuten. Während dieses Prozesses gibt es eine Ausfallzeit, die zur Beendigung der Datensammlung durch den Watcher führen kann. Wenn das der Fall ist, müssen Sie den Watcher beenden und neu starten, wenn der Skalierungsvorgang abgeschlossen ist.

Kostenloser Azure Data Explorer-Cluster

Für den kostenlosen Azure Data Explorer-Cluster gelten bestimmte Kapazitätsbeschränkungen, einschließlich eines Speicherkapazitätslimits für die ursprünglichen unkomprimierten Daten. Sie können einen kostenlosen Azure Data Explorer-Cluster nicht skalieren, um seine Compute- oder Speicherkapazität zu erhöhen. Wenn der Cluster seine Speicherkapazität erreicht oder sie überschreitet, wird auf der Seite des kostenlosen Clusters eine Warnmeldung angezeigt.

Wenn Sie die Speicherkapazität erreichen, werden keine neuen Überwachungsdaten erfasst, die vorhandene Daten bleiben aber auf den Dashboards der Datenbanküberwachung zugänglich und können mithilfe von KQL- oder SQL-Abfragen analysiert werden.

Wenn Sie feststellen, dass die Spezifikationen des kostenlosen Clusters für Ihre Anforderungen unzureichend sind, können Sie ein Upgrade auf einen vollständigen Azure Data Explorer-Cluster durchführen, um alle gesammelten Daten aufzubewahren. Da es während des Upgrades zu einer Ausfallzeit kommen kann, müssen Sie den Watcher gegebenenfalls beenden und neu starten, um die Datensammlung fortzusetzen, sobald das Upgrade abgeschlossen ist.

Um den kostenlosen Azure Data Explorer-Cluster weiterhin zu verwenden, verwalten Sie die Datenaufbewahrung so, dass die älteren Daten automatisch gelöscht werden und Speicherplatz für neue Daten freigegeben wird. Wenn wieder Speicherplatz verfügbar ist, müssen Sie die Überwachung möglicherweise beenden und neu starten, um die Datensammlung fortzusetzen.

Verwalten der Datenaufbewahrung

Wenn Sie keine älteren Daten benötigen, können Sie die Datenaufbewahrungsrichtlinien so konfigurieren, dass automatisch eine endgültige Löschung erfolgt. Standardmäßig ist die Datenaufbewahrung in einer neuen Datenbank in einem Azure Data Explorer-Cluster oder in der Echtzeitanalyse auf 365 Tage festgelegt.

• Sie können den Zeitraum für die Datenaufbewahrung auf Datenbankebene oder für einzelne Tabellen in der Datenbank verkürzen.
• Sie können die Aufbewahrungszeit auch verlängern, wenn Sie Überwachungsdaten für mehr als ein Jahr speichern müssen. Es gibt keine Obergrenze für den Datenaufbewahrungszeitraum.
• Wenn Sie für verschiedene Tabellen unterschiedliche Datenaufbewahrungszeiträume konfigurieren, kann es vorkommen, dass Dashboards für die älteren Zeitbereiche nicht erwartungsgemäß funktionieren. Das kann der Fall sein, wenn Daten in manchen Tabellen noch vorhanden sind, in anderen Tabellen für das gleiche Zeitintervall aber bereits endgültig gelöscht wurden.

Die Menge der SQL-Überwachungsdaten, die im Datenspeicher aufgenommen werden, hängt von Ihren SQL-Workloads und der Größe Ihrer Azure SQL-Umgebung ab. Sie können die folgende KQL-Abfrage verwenden, um die durchschnittliche Datenmenge pro Tag anzuzeigen, den Speicherverbrauch im Zeitverlauf zu schätzen und Datenaufbewahrungsrichtlinien zu verwalten.

.show database extents
| summarize OriginalSize = sum(OriginalSize),
            CompressedSize = sum(CompressedSize)
            by bin(MinCreatedOn, 1d)
| summarize DailyAverageOriginal = format_bytes(avg(OriginalSize)),
            DailyAverageCompressed = format_bytes(avg(CompressedSize));

Schema- und Zugriffsänderungen im Datenspeicher des Datenbankwatchers

Mit der Zeit wird Microsoft vielleicht neue Datasets für den Datenbankwatcher einführen oder vorhandene Datasets erweitern. Dies bedeutet, dass neue Tabellen im Datenspeicher oder neue Spalten in vorhandenen Tabellen gegebenenfalls automatisch hinzugefügt werden.

Dazu muss die aktuelle verwaltete Identität eines Datenbank-Watchers Mitglied der RBAC-Rolle Admins im Datenspeicher sein. Das Widerrufen dieser Rollenmitgliedschaft oder das Ersetzen durch die Mitgliedschaft in einer anderen RBAC-Rolle kann sich auf die Datenerfassung durch den Datenbankwatcher und die Schemaverwaltung auswirken und wird nicht unterstützt.

Ebenso wird das Erstellen von neuen Objekten wie Tabellen, externen Tabellen, materialisierten Sichten, Funktionen usw. im Datenspeicher des Datenbankwatchers nicht unterstützt. Sie können mit clusterübergreifenden und datenbankübergreifende Abfragen Daten in Ihrem Datenspeicher aus anderen Azure Data Explorer-Clustern oder aus anderen Datenbanken im selben Cluster abfragen.

Beendeter Azure Data Explorer-Cluster

Ein Azure Data Explorer-Cluster kann beendet werden, z.B. um Kosten zu sparen. Standardmäßig wird ein Azure Data Explorer-Cluster, der im Azure-Portal erstellt wurde, nach mehreren Tagen der Inaktivität automatisch beendet. Dies kann zum Beispiel vorkommen, wenn Sie den Watcher beenden, der Daten in die einzige Datenbank in Ihrem Cluster aufnimmt, und Sie keine Abfragen in dieser Datenbank ausführen.

Wenn Sie beim Erstellen eines neuen Watchers die Standardoption zum Erstellen eines neuen Azure Data Explorer-Clusters verwenden, wird das automatische Stoppverhalten deaktiviert, um unterbrechungsfreie Datensammlung zu ermöglichen.

Wenn der Cluster beendet wird, wird auch die Datensammlung durch den Datenbank-Watcher beendet. Um die Datensammlung fortzusetzen, müssen Sie den Cluster starten. Starten Sie den Watcher neu, sobald der Cluster ausgeführt wird.

Sie können das automatische Beenden deaktivieren, wenn der Cluster auch bei Inaktivität verfügbar bleiben soll. Dadurch können sich die Clusterkosten erhöhen.

Streamingerfassung

Der Datenbankwatcher erfordert, dass für den Azure Data Explorer-Cluster, der die Datenspeicherdatenbank enthält, die Streamingerfassung aktiviert ist. Die Streamingerfassung wird beim Erstellen eines neuen Watchers für den neu erstellten Azure Data Explorer-Cluster automatisch aktiviert. Sie ist auch in der Echtzeitanalyse und in kostenlosen Azure Data Explorer-Clustern aktiviert.

Wenn einen vorhandenen Azure Data Explorer-Cluster verwenden möchten, müssen Sie erst einmal die Streamingerfassung aktivieren. Dies dauert einige Minuten, und es erfolgt ein Neustart des Clusters.

Private Konnektivität zum Datenspeicher

Wenn der öffentliche Zugriff in einem Azure Data Explorer-Cluster deaktiviert ist, müssen Sie einen privaten Endpunkt erstellen, um im Browser eine Verbindung mit dem Cluster herzustellen und die SQL-Überwachungsdaten in Dashboards anzuzeigen oder die Daten direkt abzufragen. Dieser private Endpunkt ergänzt den erstellten verwalteten privaten Endpunkt, damit der Watcher Überwachungsdaten in einer Datenbank im Azure Data Explorer-Cluster erfassen kann.

• Wenn Sie von einer Azure-VM aus eine Verbindung zu einem Azure Data Explorer-Cluster herstellen, müssen Sie einen privaten Endpunkt für den Azure Data Explorer-Cluster im virtuellen Azure-Netzwerk erstellen, in dem die Azure-VM bereitgestellt wird.

• Wenn Sie von einem lokalen Computer aus eine Verbindung zum Azure Data Explorer-Cluster herstellen, haben Sie folgende Möglichkeiten:

  1. Verwenden Sie Azure VPN Gateway oder Azure ExpressRoute, um eine private Verbindung von Ihrem lokalen Netzwerk zu einem Azure Virtual Network herzustellen.
  2. Erstellen Sie einen privaten Endpunkt für den Azure Data Explorer-Cluster im virtuellen Azure-Netzwerk, in dem die VPN- oder ExpressRoute-Verbindung endet, oder in einem anderen virtuellen Azure-Netzwerk, das für den Datenverkehr auf Ihrem lokalen Computer erreichbar ist.
  3. Konfigurieren Sie die DNS für diesen privaten Endpunkt.

Private Konnektivität ist für kostenlose Azure Data Explorer-Cluster oder für die Echtzeitanalyse in Microsoft Fabric nicht verfügbar.

Überwachen großer Umgebungen

Zum Überwachen einer großen Azure SQL-Umgebung müssen Sie möglicherweise mehrere Watcher erstellen.

Jeder Watcher braucht eine Datenbank auf einem Azure Data Explorer-Cluster oder in der Echtzeitanalyse als Datenspeicher. Die von Ihnen erstellten Watcher können eine einzige Datenbank als gemeinsamen Datenspeicher oder separate Datenbanken als separate Datenspeicher verwenden. Mithilfe der folgenden Überlegungen können die für Ihre Überwachungsszenarien und Anforderungen optimale Entscheidung treffen.

Überlegungen zu einem gemeinsamen Datenspeicher:

• Es gibt einen umfassenden Überblick über Ihre gesamte Azure SQL-Umgebung.
• Die Dashboards eines Watchers zeigen alle Daten im Datenspeicher an, selbst wenn die Daten von anderen Watchern erfasst werden.
• Benutzer*innen mit Zugriff auf den Datenspeicher haben Zugriff auf die Überwachungsdaten für die gesamte Azure SQL-Umgebung.

Überlegungen zu separaten Datenspeichern:

• Teilmengen Ihrer Azure SQL-Umgebung werden unabhängig voneinander überwacht. Dashboards von Datenbank-Watchern im Azure-Portal zeigen stets die Daten aus einem einzelnen Datenspeicher an.
• Benutzer mit Zugriff auf mehrere Datenspeicher können anhand von clusterübergreifenden oder datenbankübergreifenden KQL-Abfragen mit einer einzigen Abfrage auf Überwachungsdaten in mehreren Datenspeichern zugreifen.
• Da der Datenzugriff im Azure Data Explorer und in der Echtzeitanalyse pro Datenbank verwaltet wird, können Sie den Zugriff auf die Überwachungsdaten für die Teilmengen Ihrer Daten auf präzise Weise verwalten.
• Sie können mehrere Datenbank im selben Azure Data Explorer-Cluster unterbringen, um Clusterressourcen gemeinsam zu nutzen und Kosten zu sparen, während die Daten in jeder Datenbank dennoch isoliert bleiben.
• Wenn Sie eine vollständige Trennung von Umgebungen benötigen, einschließlich des Netzwerkzugriffs auf Azure Data Explorer-Cluster, können Sie verschiedene Datenbanken auf unterschiedlichen Clustern unterbringen.

Zugehöriger Inhalt

• Schnellstart: Erstellen eines Datenbankwatchers zum Überwachen von Azure SQL (Vorschau)
• Überwachen von Azure SQL-Workloads mit Datenbankwatcher (Vorschau)
• Datensammlung und Datasets des Datenbankwatchers (Vorschau)
• Analysieren von Überwachungsdaten des Datenbankwatchers (Vorschau)
• Häufig gestellte Fragen zum Datenbankwatcher