Verbessern der Resilienz durch Replizieren Ihres Log Analytics-Arbeitsbereichs in allen Regionen

Die regionsübergreifende Replizierung Ihres Log Analytics-Arbeitsbereichs erhöht die Ausfallsicherheit, da Sie im Falle eines regionalen Ausfalls auf den replizierten Arbeitsbereich umschalten und den Betrieb fortsetzen können. In diesem Artikel wird erläutert, wie die Replizierung von Log Analytics-Arbeitsbereichen funktioniert, wie Sie Ihren Arbeitsbereich replizieren, wie Sie hin- und herschalten und wie Sie entscheiden, wann Sie zwischen Ihren replizierten Arbeitsbereichen wechseln.

Das folgende Video gibt einen kurzen Überblick über die Funktionsweise der Log Analytics-Arbeitsbereichsreplikation:

Wichtig

Obwohl wir manchmal den Begriff „Failover“ verwenden, z. B. im API-Aufruf, wird Failover auch allgemein zur Beschreibung eines automatischen Prozesses verwendet. Daher wird in diesem Artikel der Begriff „Switchover“ verwendet, um zu betonen, dass der Wechsel zum replizierten Arbeitsbereich eine Aktion ist, die Sie manuell auslösen.

Funktionsweise der Log Analytics-Arbeitsbereichreplikation

Ihr ursprünglicher Arbeitsbereich und die zugehörige Region werden als primär bezeichnet. Der replizierte Arbeitsbereich und die alternative Region werden als sekundär bezeichnet.

Der Prozess der Arbeitsbereichsreplikation erstellt eine Instanz Ihres Arbeitsbereichs in der sekundären Region. Der Prozess erstellt den sekundären Arbeitsbereich mit der gleichen Konfiguration wie Ihren primären Arbeitsbereich, und Azure Monitor aktualisiert den sekundären Arbeitsbereich automatisch mit allen zukünftigen Änderungen, die Sie an der Konfiguration Ihres primären Arbeitsbereichs vornehmen.

Der sekundäre Arbeitsbereich ist ein „Schatten“-Arbeitsbereich, der nur der Ausfallsicherheit dient. Der sekundäre Arbeitsbereich wird im Azure-Portal nicht angezeigt, und Sie können ihn nicht direkt verwalten oder darauf zugreifen.

Wenn Sie die Arbeitsbereichsreplikation aktivieren, sendet Azure Monitor neue Protokolle, die in Ihren primären Arbeitsbereich aufgenommen werden, auch an Ihre sekundäre Region. Protokolle, die Sie im Arbeitsbereich erfassen, bevor Sie die Replikation des Arbeitsbereichs aktivieren, werden nicht kopiert.

Hinweis

Die Arbeitsbereichreplikation repliziert vollständig alle Tabellenschemas, sendet jedoch nur neue Protokolle, die seit der Aktivierung der Replikation aufgenommen wurden. Protokolle, die im Arbeitsbereich erfasst werden, bevor Sie die Replikation des Arbeitsbereichs aktivieren, werden nicht kopiert.

Wenn Ihre primäre Region von einem Ausfall betroffen ist, können Sie umschalten und alle Erfassungs- und Abfrageanforderungen an Ihre sekundäre Region weiterleiten. Nachdem Azure den Ausfall beseitigt hat und Ihr primärer Arbeitsbereich wieder in Ordnung ist, können Sie wieder zu Ihrer primären Region wechseln.

Wenn Sie wechseln, wird der sekundäre Arbeitsbereich aktiv und Ihr primärer wird inaktiv. Azure Monitor nimmt dann neue Daten über die Erfassungspipeline in Ihrer sekundären Region auf, anstatt in der primären Region. Wenn Sie zu Ihrer sekundären Region wechseln, repliziert Azure Monitor alle Daten, die Sie aus der sekundären Region in die primäre Region erfassen. Der Prozess ist asynchron und hat keinen Einfluss auf die Erfassungslatenz.

Hinweis

Wenn die primäre Region nach dem Wechsel zur sekundären Region keine eingehenden Protokolldaten verarbeiten kann, puffert Azure Monitor die Daten in der sekundären Region für bis zu 11 Tage. Während der ersten vier Tage versucht Azure Monitor automatisch in regelmäßigen Abständen, die Daten zu replizieren.

Schutz vor Verlust von in Übertragung begriffenen Daten während eines regionalen Ausfalls

Azure Monitor verfügt über mehrere Mechanismen, um sicherzustellen, dass Daten während der Übertragung nicht verloren gehen, wenn in der primären Region ein Fehler auftritt.

Azure Monitor schützt Daten, die den Erfassungsendpunkt der primären Region erreichen, wenn die Pipeline der primären Region für die Verarbeitung der Daten nicht verfügbar ist. Wenn die Pipeline verfügbar wird, verarbeitet sie weiterhin in Übertragung begriffene Daten, und Azure Monitor erfasst und repliziert die Daten in die sekundäre Region.

Wenn der Erfassungsendpunkt der primären Region nicht verfügbar ist, versucht der Azure Monitor-Agent regelmäßig das Senden von Protokolldaten an den Endpunkt. Der Datenerfassungsendpunkt in der sekundären Region beginnt einige Minuten nach dem Auslösen des Switchovers, Daten von Agenten zu empfangen.

Wenn Sie Ihren eigenen Client schreiben, um Protokolldaten an Ihren Log Analytics-Arbeitsbereich zu senden, stellen Sie sicher, dass der Client fehlgeschlagene Erfassungsanforderungen behandelt.

Überlegungen zur Bereitstellung

Hinweis

Die Arbeitsbereichreplikation unterstützt derzeit keine Replikation von Hilfstabellen und sollte nicht für Arbeitsbereiche aktiviert werden, die Hilfstabellen enthalten. Hilfstabellen werden nicht repliziert und sind daher im Falle eines regionalen Fehlers nicht vor Datenverlust geschützt und sind nicht verfügbar, wenn Sie zum sekundären Arbeitsbereich wechseln.

• Die Operationen der Arbeitsbereichsverwaltung können während des Switchovers nicht initiiert werden, einschließlich:

  • Ändern der Arbeitsbereichaufbewahrung, des Tarifs, der täglichen Obergrenze usw.
  • Ändern der Netzwerkeinstellungen
  • Ändern des Schemas durch neue benutzerdefinierte Protokolle oder Verbinden von Plattformprotokollen von neuen Ressourcenanbietern, z. B. Senden von Diagnoseprotokollen aus einem neuen Ressourcentyp

• Der Failoverprozess aktualisiert Ihre DNS-Einträge (Domain Name System), um alle Anforderungen zur Erfassung an Ihre sekundäre Region zur Verarbeitung umzuleiten. Einige HTTP-Clients verfügen über persistente Verbindungen und könnten länger brauchen, um auf DNS-Updates zu reagieren. Während des Switchover versuchen diese Clients möglicherweise eine Zeit lang, Protokolle über die Primärregion zu erfassen. Möglicherweise erfassen Sie Protokolle in Ihrem primären Arbeitsbereich mit verschiedenen Clients, darunter der alte Log Analytics-Agent, der Azure Monitor-Agent, Code (mit der Protokollerfassungs-API oder der alten HTTP-Datensammlungs-API) und andere Dienste wie Microsoft Sentinel.

Wichtig

Protokoll-Suchwarnungsregeln funktionieren weiterhin, wenn Sie zwischen Regionen wechseln, es sei denn, der Warnungsdienst in der aktiven Region funktioniert nicht ordnungsgemäß, oder die Warnungsregeln sind nicht verfügbar. Dies kann beispielsweise passieren, wenn die Region, in der die Warnungsregeln erstellt wurden, vollständig ausgefallen ist. Die Replikation von Warnungsregeln in allen Regionen erfolgt nicht automatisch als Teil der Arbeitsbereichreplikation, kann aber vom Benutzer durchgeführt werden (z. B. durch Exportieren aus der primären Region und Importieren in die sekundäre Region).

• Der Bereinigungsvorgang, der Datensätze aus einem Arbeitsbereich löscht, entfernt die betreffenden Datensätze sowohl aus dem primären als auch aus dem sekundären Arbeitsbereich. Der Bereinigungsvorgang schlägt fehl, wenn eine der Arbeitsbereichsinstanzen nicht verfügbar ist.

• Microsoft Sentinel aktualisiert Protokolle in den Tabellen Watchlist und Threat Intelligence alle 12 Tage. Da also nur neue Protokolle in den replizierten Arbeitsbereich aufgenommen werden, kann es bis zu 12 Tage dauern, bis Watchlist- und Threat Intelligence-Daten vollständig an den sekundären Speicherort repliziert werden.

• Die Fähigkeit des früheren Log Analytics-Agenten, auf eine Lösung abzuzielen, wird beim Switchover nicht unterstützt. Während des Switchover werden Lösungsdaten von allen Agents erfasst.

• Diese Features werden derzeit nicht oder nur teilweise unterstützt:

  Merkmal	Unterstützung
  Hilfstabellenpläne	Nicht unterstützt. Azure Monitor repliziert keine Daten aus Tabellen, die den Hilfsprotokollplan verwenden, in Ihren sekundären Arbeitsbereich. Daher sind diese Daten bei einem regionalen Ausfall nicht vor Datenverlust geschützt und stehen nicht zur Verfügung, wenn Sie zu Ihrem sekundären Arbeitsbereich wechseln.
  Jobs suchen, Wiederherstellen	Teilweise unterstützt – Suchaufträge und Wiederherstellungsoperationen erstellen Tabellen und füllen sie mit Suchergebnissen oder wiederhergestellten Daten. Nachdem Sie die Arbeitsbereichsreplikation aktiviert haben, werden neue Tabellen, die für diese Operationen erstellt wurden, in Ihren sekundären Arbeitsbereich repliziert. Tabellen, die vor der Aktivierung der Replikation aufgefüllt wurden, werden nicht repliziert. Wenn diese Vorgänge noch laufen, wenn Sie umschalten, ist das Ergebnis unerwartet. Der Vorgang kann erfolgreich abgeschlossen werden, aber nicht repliziert werden, oder er kann fehlschlagen, je nach Zustand Ihres Arbeitsbereichs und dem genauen Zeitpunkt.
  Application Insights über Log Analytics-Arbeitsbereiche	Nicht unterstützt
  VM Insights	Nicht unterstützt
  Containereinblicke	Nicht unterstützt
  Private Verknüpfungen	Während des Failovers nicht unterstützt

Unterstützte Regionen

Die Replikation von Arbeitsbereichen wird derzeit für Arbeitsbereiche in einer begrenzten Anzahl von Regionen unterstützt, die nach Regionsgruppen (Gruppen von geografisch benachbarten Regionen) organisiert sind. Wenn Sie die Replikation aktivieren, wählen Sie einen sekundären Standort aus der Liste der unterstützten Regionen in derselben Regionsgruppe wie der primäre Standort des Arbeitsbereichs. Zum Beispiel kann ein Arbeitsbereich in „Europa, Westen“ in „Europa, Norden“ repliziert werden, aber nicht in „USA, Westen 2“, da diese Regionen zu unterschiedlichen Regionengruppen gehören.

Die folgenden Regionengruppen und Regionen werden derzeit unterstützt:

Regionsgruppe	Primäre Regionen	Sekundäre Regionen (Speicherorte für die Replikation)
Nordamerika	Kanada, Mitte Kanada, Osten Zentral-USA Ost-USA* Ost-USA 2* USA Nord Mitte Südzentral USA* USA, Westen-Mitte Westen der USA USA, Westen 2 USA, Westen 3	Kanada, Mitte Zentral-USA Ost-USA* Ost-USA 2* Westen der USA USA, Westen 2
Südamerika	Brasilien, Süden Brasilien Südosten	Brasilien, Süden Brasilien Südosten
Europa	Frankreich, Mitte Frankreich Süd Deutschland Nord Deutschland West Central Italien, Norden Europa, Norden Norwegen, Osten Westnorwegen Polen, Mitte Südbritannien Spanien Zentral Schweden, Mitte Schweden Süd Schweiz Nord Westschweiz Europa, Westen Vereinigtes Königreich, Westen	Frankreich, Mitte Europa, Norden Südbritannien Europa, Westen
Naher Osten	Katar, Mitte UAE Central Vereinigte Arabische Emirate, Norden	Katar, Mitte UAE Central Vereinigte Arabische Emirate, Norden
Indien	Indien, Mitte Südindien	Indien, Mitte Südindien
Asien-Pazifik	Ostasien Japan, Osten Japan, Westen Südkorea, Mitte Südkorea Südostasien	Ostasien Japan, Osten Zentral-Korea
Ozeanien	Australien Zentral Australien Central 2 Australien, Osten Australien Südosten	Australien Zentral Australien, Osten Australien Südosten
Afrika	Südafrika, Norden Südafrika, Westen	Südafrika, Norden Südafrika, Westen

Hinweis

Arbeitsbereiche in Ost-USA, Ost-US 2 und Süd-Zentral-USA können nur in sekundäre Regionen außerhalb dieser Gruppe von drei repliziert werden. Wählen Sie einen anderen sekundären Standort aus der Region "Nordamerika" aus.

Anforderungen an die Datenresidenz

Die Kundschaft hat unterschiedliche Anforderungen an die Datenaufbewahrung, daher ist es wichtig, dass Sie die Kontrolle darüber haben, wo Ihre Daten gespeichert werden. Azure Monitor verarbeitet und speichert Protokolle in den von Ihnen gewählten primären und sekundären Regionen. Weitere Informationen finden Sie unter Unterstützte Regionen.

Support für Microsoft Sentinel und andere Dienste

Verschiedene Dienste und Funktionen, die Log Analytics-Arbeitsbereiche verwenden, sind mit der Arbeitsbereichsreplikation und dem Switchover kompatibel. Diese Dienste und Funktionen funktionieren weiterhin, wenn Sie zum sekundären Arbeitsbereich wechseln.

So können sich beispielsweise regionale Netzwerkprobleme, die eine Latenz bei der Protokollaufnahme verursachen, auf die Microsoft Sentinel-Kundschaft auswirken. Die Kundschaft, die replizierte Arbeitsbereiche verwendet, kann zu ihrer sekundären Region wechseln, um mit ihrem Log Analytics-Arbeitsbereich und Sentinel weiterzuarbeiten. Wenn sich das Netzwerkproblem jedoch auf den Zustand des Sentinel-Dienstes auswirkt, kann ein Wechsel in eine andere Region das Problem nicht beheben.

Einige Azure Monitor-Benutzeroberflächen, einschließlich Application Insights und VM Insights, sind derzeit nur teilweise mit Arbeitsbereichsreplikation und Switchover kompatibel. Die vollständige Liste finden Sie unter Überlegungen zur Bereitstellung.

Preismodell

Wenn Sie die Arbeitsbereichsreplikation aktivieren, werden Ihnen die Kosten für die Replikation aller Daten berechnet, die Sie in Ihren Arbeitsbereich aufnehmen.

Wichtig

Wenn Sie Daten über den Azure Monitor-Agent, die Protokollerfassungs-API, Azure Event Hubs oder andere Datenquellen, die Datensammlungsregeln verwenden, an Ihren Arbeitsbereich senden, achten Sie darauf, dass Sie Ihre Datensammlungsregeln mit dem Datensammlungsendpunkt Ihres Arbeitsbereichs verknüpfen. Diese Verknüpfung stellt sicher, dass die von Ihnen aufgenommenen Daten in Ihren sekundären Arbeitsbereich repliziert werden. Wenn Sie Ihre Datensammlungsregeln nicht mit dem Datensammlungsendpunkt des Arbeitsbereichs verknüpfen, werden Ihnen weiterhin alle Daten in Rechnung gestellt, die Sie in Ihren Arbeitsbereich aufnehmen, auch wenn die Daten nicht repliziert werden.

Erforderliche Berechtigungen

Handlung	Erforderliche Berechtigungen
Aktivieren der Arbeitsbereichreplikation	Berechtigungen vom Typ Microsoft.OperationalInsights/workspaces/write und Microsoft.Insights/dataCollectionEndpoints/write, wie sie z. B. von der integrierten Rolle „Mitwirkender an der Überwachung“ bereitgestellt werden
Wechseln und Zurückwechseln im Rahmen des Switchovers (Auslösen von Failover und Failback)	Berechtigungen vom Typ Microsoft.OperationalInsights/locations/workspaces/failover, Microsoft.OperationalInsights/workspaces/failback, Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action und Microsoft.Insights/dataCollectionEndpoints/triggerFailback/action, wie sie z. B. von der integrierten Rolle „Mitwirkender an der Überwachung“ bereitgestellt werden
Überprüfen des Arbeitsbereichsstatus	Berechtigungen vom Typ Microsoft.OperationalInsights/workspaces/read für den Log Analytics-Arbeitsbereich, wie sie beispielsweise von der integrierten Rolle „Mitwirkender an der Überwachung“ bereitgestellt werden

Aktivieren und Deaktivieren der Arbeitsbereichsreplikation

Sie aktivieren und deaktivieren die Arbeitsbereichsreplikation mit einem REST-Befehl. Der Befehl löst einen zeitintensiven Vorgang aus, d. h. es kann einige Minuten dauern, bis die neuen Einstellungen übernommen werden. Nachdem Sie die Replikation aktiviert haben, kann es bis zu einer Stunde dauern, bis alle Tabellen (Datentypen) mit der Replikation beginnen, und einige Datentypen beginnen möglicherweise vor anderen mit der Replikation. Änderungen, die Sie an Tabellenschemata vornehmen, nachdem Sie die Arbeitsbereichsreplikation aktiviert haben – z. B. neue benutzerdefinierte Protokolltabellen oder benutzerdefinierte Felder, die Sie erstellen, oder Diagnoseprotokolle, die für neue Ressourcentypen eingerichtet werden – können bis zu einer Stunde dauern, bis die Replikation beginnt.

Verwenden Sie einen dedizierten Cluster?

Wenn Ihr Arbeitsbereich mit einem dedizierten Cluster verknüpft ist, müssen Sie zuerst die Replikation auf dem Cluster und nur dann im Arbeitsbereich aktivieren. Dieser Vorgang erstellt einen zweiten Cluster in Ihrer sekundären Region (keine zusätzlichen Gebühren über die Replikationsgebühren hinaus), um Ihrem Arbeitsbereich die Nutzung eines dedizierten Clusters zu ermöglichen, selbst wenn ein Failover auftritt. Dies bedeutet auch, dass Features wie clusterverwaltete Schlüssel (CMK) während des Failovers (mit demselben Schlüssel) weiterhin funktionieren. Sobald die regionsübergreifende Replikation aktiviert ist, aktivieren Sie die Replikation für einen oder mehrere der Arbeitsbereiche, die mit diesem Cluster verknüpft sind.

Wichtig

Sobald die Clusterreplikation aktiviert ist, erfordert die Änderung des Replikationsziels das Deaktivieren der Replikation und das erneute Aktivieren in einem anderen Speicherort.

Verwenden Sie den folgenden PUT-Befehl, um die Replikation auf Ihrem dedizierten Cluster zu aktivieren. Dieser Aufruf gibt 202 zurück. Es ist ein langwieriger Vorgang, der eine gewisse Zeit in Anspruch nehmen kann. Sie können den genauen Zustand nachverfolgen, wie unter Cluster-Bereitstellungsstatus prüfen erläutert.

Verwenden Sie den PUT folgenden Befehl, um die Clusterreplikation zu aktivieren:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "<secondary_region>"
        }
    },
    "location": "<primary_region>"
}

Wo:

• <subscription_id>: Die Abonnement-ID im Zusammenhang mit Ihrem Cluster
• <resourcegroup_name> : Die Ressourcengruppe, die Ihre Log Analytics-Clusterressource enthält
• <cluster_name>: Der Name Ihres dedizierten Clusters
• <primary_region>: Die primäre Region für Ihren dedizierten Log Analytics-Cluster
• <secondary_region>: Die Region, in der Azure Monitor den sekundären dedizierten Cluster erstellt

Überprüfen des Clusterbereitstellungsstatus

Führen Sie den folgenden GET Befehl aus, um den Bereitstellungsstatus Ihres Clusters zu überprüfen:

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/clusters/<cluster_name>?api-version=2025-02-01

Wo:

• <subscription_id>: Die Abonnement-ID im Zusammenhang mit Ihrem Cluster
• <resourcegroup_name>: Die Ressourcengruppe, die Ihre Log Analytics-Clusterressource enthält
• <cluster_name>: Der Name Ihres Log Analytics-Clusters

Verwenden Sie den GET Befehl, um zu überprüfen, ob sich der Bereitstellungsstatus des Clusters von Updating zu Succeeded" ändert" und die sekundäre Region wie erwartet festgelegt wird.

Hinweis

Wenn Sie die Clusterreplikation aktivieren, wird ein neuer Cluster am sekundären Speicherort bereitgestellt. Dieser Vorgang kann 1-2 Stunden dauern.

Aktivieren der Arbeitsbereichreplikation

Verwenden Sie den Befehl PUT, um die Replikation in Ihrem Log Analytics-Arbeitsbereich zu aktivieren:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "<secondary_region>"
        }
    },
    "location": "<primary_region>"
}

Wo:

• <subscription_id>: Die Abonnement-ID, die sich auf Ihren Arbeitsbereich bezieht.
• <resourcegroup_name> : Die Ressourcengruppe, die Ihre Log Analytics-Arbeitsbereichsressource enthält
• <workspace_name>: Der Name Ihres Arbeitsbereichs
• <primary_region>: Die primäre Region für Ihren Log Analytics-Arbeitsbereich
• <secondary_region>: Die Region, in der Azure Monitor den sekundären Arbeitsbereich erstellt

Die unterstützten location-Werte finden Sie unter Unterstützte Regionen.

Der Befehl PUT ist ein zeitintensiver Vorgang, der einige Zeit in Anspruch nehmen kann. Ein erfolgreicher Aufruf gibt einen 200-Statuscode zurück. Sie können den Bereitstellungsstatus Ihrer Anforderung nachverfolgen, wie im Bereitstellungsstatus des Arbeitsbereichs beschrieben.

Wichtig

Wenn Ihr Arbeitsbereich mit einem dedizierten Cluster verknüpft ist, aktivieren Sie zuerst die Replikation auf dem Cluster. Beachten Sie außerdem, dass der sekundäre Speicherort Ihres Arbeitsbereichs mit dem sekundären Speicherort des dedizierten Clusters identisch sein muss.

Überprüfen Sie den Bereitstellungsstatus des Arbeitsbereichs

Führen Sie den folgenden GET Befehl aus, um den Bereitstellungsstatus Ihres Arbeitsbereichs zu überprüfen:

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>?api-version=2025-02-01

Wo:

• <subscription_id>: Die Abonnement-ID, die sich auf Ihren Arbeitsbereich bezieht.
• <resourcegroup_name>: Die Ressourcengruppe, die Ihre Log Analytics-Arbeitsbereichsressource enthält.
• <workspace_name>: Der Name Ihres Log Analytics-Arbeitsbereichs.

Verwenden Sie den Befehl GET, um zu überprüfen, ob der Bereitstellungsstatus des Arbeitsbereichs von Updating auf Succeeded wechselt und die sekundäre Region wie erwartet eingestellt ist.

Hinweis

Wenn Sie die Replikation für Arbeitsbereiche aktivieren, die mit Sentinel interagieren, kann es bis zu 12 Tage dauern, bis Watchlist- und Threat Intelligence-Daten vollständig auf den sekundären Arbeitsbereich repliziert sind.

Überprüfen, ob die Replikation in einem Arbeitsbereich aktiviert ist

Um zu überprüfen, ob und wo die Arbeitsbereichreplikation aktiviert ist, überprüfen Sie diese Einstellungen.

Wählen Sie im Azure-Portal die Arbeitsbereichsübersicht> aus. Wenn die Replikation aktiviert ist, zeigt der Abschnitt "Essentials " den sekundären Speicherort an, der den Bereich des replizierten Arbeitsbereichs angibt.

Derselbe Abschnitt "Essentials" verfügt über eine JSON-Ansicht , in der die Replikationsdetails als JSON-Objekt angezeigt werden, das auch über REST/CLI verfügbar ist.

Datensammlungsregeln mit dem Datensammlungsendpunkt des Arbeitsbereichs verknüpfen

Der Azure Monitor-Agent, die Protokollerfassungs-API und Azure Event Hubs sammeln Daten und senden sie an das von Ihnen angegebene Ziel, basierend auf der Einrichtung Ihrer Datensammlungsregeln (Data Collection Rules, DCR).

Wenn Sie Datensammlungsregeln anwenden, die Daten an Ihren primären Arbeitsbereich senden, müssen Sie die Regeln mit einem Systemdatensammlungsendpunkt (Data Collection Endpoint, DCE) verknüpfen, den Azure Monitor erstellt, wenn Sie die Arbeitsbereichsreplikation aktivieren. Der Name des Datensammlungsendpunkts Ihres Arbeitsbereichs ist identisch mit Ihrer Arbeitsbereichs-ID. Nur Datensammlungsregeln, die Sie mit dem Datensammlungsendpunkt des Arbeitsbereichs verknüpfen, ermöglichen Replikation und Switchover. Mit diesem Verhalten können Sie die Menge der zu replizierenden Protokollströme angeben, was Ihnen hilft, Ihre Replikationskosten zu steuern.

Um Daten, die Sie mithilfe von Datensammlungsregeln sammeln, zu replizieren, verknüpfen Sie Ihre Datensammlungsregeln mit dem Datensammlungsendpunkt des Arbeitsbereichs:

1. Wählen Sie im Azure-Portal die Datensammlungsregeln aus.

2. Wählen Sie im Bildschirm Datensammlungsregeln eine Datensammlungsregel aus, die Daten an Ihren primären Log Analytics-Arbeitsbereich sendet.

3. Wählen Sie auf der Seite ÜbersichtDCE konfigurieren aus, und wählen Sie den Datensammlungsendpunkt des Arbeitsbereichs aus der verfügbaren Liste aus:

   

   Ausführliche Informationen zum System DCE finden Sie in den Arbeitsbereichsobjekteigenschaften.

Wichtig

Datensammlungsregeln, die mit einem Datensammlungsendpunkt eines Arbeitsbereichs verbunden sind, können nur auf diesen speziellen Arbeitsbereich abzielen. Die Datensammlungsregeln dürfen nicht auf andere Ziele abzielen, z. B. auf andere Arbeitsbereiche oder Azure Storage-Konten.

Was überprüft werden sollte, wenn die Arbeitsbereichreplikation fehlschlägt

• Ist der Arbeitsbereich mit einem dedizierten Cluster verknüpft?
  • Die Replikation muss auf dem Cluster aktiviert sein, bevor sie im Arbeitsbereich aktiviert werden kann.
  • Sowohl die Cluster- als auch die Arbeitsbereichreplikation müssen auf denselben sekundären Speicherort eingestellt sein. Wenn der Cluster beispielsweise nach Nordeuropa repliziert wird, können die damit verknüpften Arbeitsbereiche nur nach Nordeuropa repliziert werden.
• Haben Sie die REST-API zum Aktivieren der Replikation verwendet?
  • Überprüfen Sie, ob Sie DIE API-Version 2025-02-01 oder höher verwendet haben.
• Befindet sich der primäre Arbeitsbereich in ost-US, Ost-USA 2 oder Süd-Zentral-USA?
  • Ost-USA, Ost-USA 2 und Süd-Zentral-USA können nicht miteinander repliziert werden.
• Wo befindet sich der primäre Arbeitsbereich und wo befindet sich der sekundäre Arbeitsbereich? Beide Standorte müssen sich in derselben Regionsgruppe befinden. Beispielsweise können Arbeitsbereiche, die sich in US-Regionen befinden, nicht über eine Replikation (sekundäre Region) in Europa verfügen und umgekehrt. Eine Liste der Regionsgruppen finden Sie unter "Unterstützte Regionen".
• Verfügen Sie über die erforderlichen Berechtigungen?
• Haben Sie genügend Zeit für den Abschluss des Replikationsvorgangs eingeplant? Die Replikation ist ein lang andauernder Vorgang. Überwachen Sie den Status des Vorgangs, wie unter Überprüfen des Bereitstellungsstatus des Arbeitsbereichs erläutert.
• Haben Sie versucht, die Replikation erneut zu aktivieren, um den sekundären Speicherort des Arbeitsbereichs zu ändern? Um den Speicherort Des sekundären Arbeitsbereichs zu ändern, müssen Sie zuerst die Arbeitsbereichreplikation deaktivieren, den Vorgang abschließen und nur dann die Replikation an einen anderen sekundären Speicherort aktivieren.

Was sollte überprüft werden, wenn die Arbeitsbereichsreplikation eingerichtet ist, aber die Protokolle nicht repliziert werden?

• Die Replikation kann bis zu einer Stunde dauern, bis sie beginnt, und einige Datentypen können vor anderen mit der Replikation beginnen.
• Protokolle, die vor der Aktivierung der Replikation im Arbeitsbereich erfasst wurden, werden nicht in den sekundären Arbeitsbereich kopiert. Nur Protokolle, die nach der Aktivierung der Replikation erfasst wurden, werden repliziert.
• Wenn einige Protokolle repliziert werden und andere nicht – überprüfen Sie alle Datensammlungsregeln (Data Collection Rules, DCRs), die Protokolle an den Arbeitsbereich streamen, ob sie ordnungsgemäß konfiguriert sind. Informationen zum Überprüfen der DCRs, die auf den Arbeitsbereich abzielen, finden Sie auf der Registerkarte "Log Analytics Workspace Insights Data Collection" im Azure-Portal.

Deaktivieren der Arbeitsbereichreplikation

Verwenden Sie den Befehl PUT, um die Replikation für einen Arbeitsbereich zu deaktivieren:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

Wo:

• <subscription_id>: Die Abonnement-ID, die sich auf Ihren Arbeitsbereich bezieht.
• <resourcegroup_name>: Die Ressourcengruppe, die Ihre Arbeitsbereichressource enthält.
• <workspace_name>: Der Name Ihres Arbeitsbereichs.
• <primary_region>: Die primäre Region für Ihren Arbeitsbereich.

Der Befehl PUT ist ein zeitintensiver Vorgang, der einige Zeit in Anspruch nehmen kann. Ein erfolgreicher Aufruf gibt einen 200-Statuscode zurück. Sie können den Bereitstellungsstatus Ihrer Anforderung nachverfolgen, wie im Bereitstellungsstatus des Arbeitsbereichs beschrieben.

Wichtig

Wenn Sie einen dedizierten Cluster verwenden, sollten Sie die Clusterreplikation deaktivieren, nachdem Sie die Replikation für jeden Arbeitsbereich deaktiviert haben, der mit diesem Cluster verknüpft ist.

Deaktivieren der Clusterreplikation

Das Deaktivieren der Clusterreplikation kann nur nach dem Deaktivieren der Replikation für alle Arbeitsbereiche erfolgen, die mit diesem Cluster verknüpft sind (sofern zuvor aktiviert). Verwenden Sie den Befehl PUT, um die Replikation für einen Arbeitsbereich zu deaktivieren:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

Wo:

• <subscription_id>: Die Abonnement-ID, die sich auf Ihr Cluster bezieht.
• <resourcegroup_name> : Die Ressourcengruppe, die Ihre Clusterressource enthält.
• <workspace_name>: Der Name des Clusters.
• <primary_region>: Die primäre Region für Ihren Cluster.

Der Befehl PUT ist ein zeitintensiver Vorgang, der einige Zeit in Anspruch nehmen kann. Ein erfolgreicher Aufruf gibt einen 200-Statuscode zurück. Sie können den Bereitstellungsstatus Ihrer Anforderung nachverfolgen, wie im Bereitstellungsstatus des Arbeitsbereichs beschrieben.

Hinweis

Sobald die Replikation deaktiviert ist und der replizierte Cluster gelöscht wird, werden die replizierten Protokolle gelöscht und können nicht mehr darauf zugreifen. Die ursprüngliche Kopie an Ihrem primären Speicherort wird in diesem Prozess nicht geändert.

Wichtig

Der Vorgang des Entfernens der Clusterreplikation dauert 14 Tage. Wenn Sie diesen Vorgang schneller ausführen müssen, erstellen Sie eine Azure-Supportanfrage.

Überwachen des Arbeitsbereichs und der Dienstintegrität

Erfassungslatenz oder Abfrageausfälle sind Beispiele für Probleme, die oft durch einen Failover zu Ihrer sekundären Region gelöst werden können. Solche Probleme können mit Hilfe von Service Health-Benachrichtigungen und Protokollabfragen erkannt werden.

Service Health-Benachrichtigungen sind für dienstbezogene Probleme nützlich. Um Probleme zu identifizieren, die sich auf Ihren spezifischen Arbeitsbereich (und möglicherweise nicht auf den gesamten Dienst) auswirken, können Sie andere Maßnahmen ergreifen:

• Warnungen basierend auf der Ressourcengesundheit des Arbeitsbereichs erstellen

• Festlegen eigener Schwellenwerte für Arbeitsbereichs-Gesundheitskennzahlen

• Erstellen Sie eigene Überwachungsabfragen, die als benutzerdefinierte Gesundheitsindikatoren für Ihren Arbeitsbereich dienen, wie unter Überwachen der Arbeitsbereichsleistung mithilfe von Abfragen beschrieben:

  • Messen der Erfassungslatenz pro Tabelle
  • Identifizieren, ob die Quelle der Latenz die Erfassungsagenten oder die Erfassungspipeline ist
  • Überwachen Sie Anomalien des Erfassungsvolumens pro Tabelle und Ressource
  • Überwachen der Abfrageerfolgsrate pro Tabelle, benutzende Person oder Ressource
  • Erstellen von Warnungen basierend auf Ihren Abfragen

Hinweis

Sie können auch Protokollabfragen verwenden, um Ihren sekundären Arbeitsbereich zu überwachen, aber bedenken Sie, dass die Replikation von Protokollen in Batch-Operationen durchgeführt wird. Die gemessene Latenz kann schwanken und deutet nicht auf ein Problem mit Ihrem sekundären Arbeitsbereich hin. Weitere Informationen finden Sie unter Überwachen des inaktiven Arbeitsbereichs.

Wechseln Sie zu Ihrem sekundären Arbeitsbereich

Während der Umschaltung funktionieren die meisten Operationen genauso wie bei der Verwendung des primären Arbeitsbereichs und der Region. Einige Vorgänge weisen jedoch ein geringfügig anderes Verhalten auf oder werden blockiert. Weitere Informationen finden Sie unter Überlegungen zur Bereitstellung.

Wann sollte ich wechseln?

Sie entscheiden auf der Grundlage der laufenden Leistungs- und Zustandsüberwachung sowie Ihrer Systemstandards und -anforderungen, wann Sie zu Ihrem sekundären Arbeitsbereich wechseln und wann Sie zu Ihrem primären Arbeitsbereich zurückkehren.

Bei Ihrem Plan für den Switchover sind mehrere Punkte zu berücksichtigen, die in den folgenden Unterabschnitten beschrieben werden.

Typ und Umfang des Problems

Der Switchoverprozess leitet Erfassungs- und Abfrageanforderungen an Ihre sekundäre Region weiter, die in der Regel alle fehlerhaften Komponenten umgeht, die in Ihrer primären Region Latenz oder Ausfälle verursachen. Folglich ist Switchover wahrscheinlich nicht hilfreich, wenn:

• Es gibt ein regionübergreifendes Problem mit einer zugrunde liegenden Ressource. Zum Beispiel, wenn dieselben Ressourcentypen sowohl in der primären als auch in der sekundären Region ausfallen.
• Sie ein Problem im Zusammenhang mit der Arbeitsbereichsverwaltung, z. B. die Änderung der Arbeitsbereichsspeicherung, haben. Die Verwaltung des Arbeitsbereichs wird immer in Ihrer primären Region durchgeführt. Während der Umstellung werden Arbeitsbereichsverwaltungsvorgänge blockiert.

Problemdauer

Der Switchover erfolgt nicht sofort. Der Prozess der Umleitung von Anforderungen beruht auf DNS-Aktualisierungen, die einige Clients innerhalb von Minuten abrufen, während andere mehr Zeit benötigen könnten. Daher ist es hilfreich zu wissen, ob das Problem innerhalb weniger Minuten behoben werden kann. Wenn das beobachtete Problem beständig oder dauerhaft ist, sollten Sie mit dem Switchover nicht warten. Im Folgenden finden Sie einige Beispiele:

• Erfassung: Probleme mit der Erfassungspipeline in Ihrer primären Region können sich auf die Datenreplikation auf Ihren sekundären Arbeitsbereich auswirken. Beim Switchover werden die Protokolle stattdessen an die Erfassungspipeline in der sekundären Region gesendet.

• Abfrage: Wenn Abfragen in Ihrem primären Arbeitsbereich fehlschlagen oder eine Zeitüberschreitung vorliegt, können die Warnmeldungen der Protokollsuche davon betroffen sein. Wechseln Sie in diesem Fall zu Ihrem sekundären Arbeitsbereich, um sicherzustellen, dass alle Ihre Warnmeldungen korrekt ausgelöst werden.

Daten im sekundären Arbeitsbereich

Protokolle, die vor der Aktivierung der Replikation in den primären Arbeitsbereich erfasst wurden, werden nicht in den sekundären Arbeitsbereich kopiert. Wenn Sie die Arbeitsbereichsreplikation vor drei Stunden aktiviert haben und nun zu Ihrem sekundären Arbeitsbereich wechseln, können Ihre Abfragen nur Daten aus den letzten drei Stunden zurückgeben.

Bevor Sie während des Switchover die Region wechseln, muss Ihr sekundärer Arbeitsbereich eine sinnvolle Menge an Protokollen enthalten. Wir empfehlen, nach der Aktivierung der Replikation mindestens eine Woche zu warten, bevor Sie den Switchover auslösen. Die sieben Tage reichen aus, um genügend Daten in Ihrer Sekundärregion zur Verfügung zu stellen.

Switchover auslösen

Vergewissern Sie sich vor dem Switchover, dass der Arbeitsbereichreplikationsvorgang erfolgreich abgeschlossen wurde. Der Switchover ist nur erfolgreich, wenn der sekundäre Arbeitsbereich ordnungsgemäß konfiguriert ist.

Verwenden Sie den Befehl POST, um zum sekundären Arbeitsbereich zu wechseln:

POST 
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/locations/<secondary_region>/workspaces/<workspace_name>/failover?api-version=2025-02-01

Wo:

• <subscription_id>: Die Abonnement-ID, die sich auf Ihren Arbeitsbereich bezieht.
• <resourcegroup_name>: Die Ressourcengruppe, die Ihre Arbeitsbereichressource enthält.
• <secondary_region>: Die Region, zu der im Rahmen des Switchovers gewechselt werden soll.
• <workspace_name>: Der Name des Arbeitsbereichs, zu dem im Rahmen des Switchovers gewechselt werden soll.

Der Befehl POST ist ein zeitintensiver Vorgang, der einige Zeit in Anspruch nehmen kann. Ein erfolgreicher Aufruf gibt einen 202-Statuscode zurück. Sie können den Bereitstellungsstatus Ihrer Anforderung nachverfolgen, wie im Bereitstellungsstatus des Arbeitsbereichs beschrieben.

Was zu prüfen ist, wenn der Switchover (Failover) fehlschlägt

• Haben Sie die REST-API zum Auslösen eines Wechsels (Failover) verwendet?
  • Überprüfen Sie, ob Sie DIE API-Version 2025-02-01 oder höher verwendet haben.
  • Überprüfen Sie, ob der im Failover-Befehl angegebene sekundäre Speicherort tatsächlich der für diesen Workspace konfigurierte sekundäre Speicherort ist. Diese Informationen sind in der Azure-Portalansicht des Arbeitsbereichs und über die API verfügbar.
• Für das Wechseln von Regionen ist eine Teilnehmerrolle für Log Analytics in der Ressourcengruppe des Arbeitsbereichs und nicht nur für den Arbeitsbereich selbst erforderlich.

Zurück zu Ihrem primären Arbeitsbereich wechseln

Der Switchbackvorgang hebt die Umleitung von Abfragen und Anforderungen an die Protokollaufnahme auf den sekundären Arbeitsbereich auf. Wenn Sie zurückwechseln, leitet Azure Monitor die Abfragen und Anforderungen für die Protokollaufnahme wieder an Ihren primären Arbeitsbereich weiter.

Wenn Sie zu Ihrer sekundären Region wechseln, repliziert Azure Monitor die Protokolle von Ihrem sekundären Arbeitsbereich in Ihren primären Arbeitsbereich. Wenn ein Ausfall den Protokollerfassungsprozess in der primären Region beeinträchtigt, kann es einige Zeit dauern, bis Azure Monitor die Erfassung der replizierten Protokolle in Ihrem primären Arbeitsbereich abschließt.

Wann sollte ich zurückwechseln?

Bei Ihrem Plan für den Switchback sind mehrere Punkte zu berücksichtigen, die in den folgenden Unterabschnitten beschrieben werden.

Protokollreplikationsstatus

Überprüfen Sie vor dem Zurückwechseln, ob Azure Monitor die Replikation aller während des Switchover erfassten Protokolle in der primären Region abgeschlossen hat. Wenn Sie zurückwechseln, bevor alle Protokolle in den primären Arbeitsbereich repliziert wurden, geben Ihre Abfragen möglicherweise nur Teilergebnisse zurück, bis die Aufnahme der Protokolle abgeschlossen ist.

Sie können Ihren primären Arbeitsbereich im Azure-Portal für die inaktive Region abfragen, wie unter Überwachen des inaktiven Arbeitsbereichs beschrieben.

Zustand des primären Arbeitsbereichs

Es gibt zwei wichtige Gesundheitspunkte, die Sie bei der Vorbereitung auf die Rückkehr zu Ihrem primären Arbeitsbereich überprüfen müssen:

• Bestätigen Sie, dass es keine ausstehenden Service Health-Benachrichtigungen für den primären Arbeitsbereich und die Region gibt.
• Stellen Sie sicher, dass Ihr primärer Arbeitsbereich Protokolle erfasst und Abfragen wie erwartet verarbeitet.

Beispiele dafür, wie Sie Ihren primären Arbeitsbereich abfragen, wenn Ihr sekundärer Arbeitsbereich aktiv ist, und die Umleitung von Anforderungen an Ihren sekundären Arbeitsbereich umgehen können, finden Sie unter Überwachen des inaktiven Arbeitsbereichs.

Switchback auslösen

Bevor Sie zurückwechseln, bestätigen Sie die Integrität des primären Arbeitsbereichs und die vollständige Replikation von Protokollen.

Der Switchbackprozess aktualisiert Ihre DNS-Einträge. Nach der Aktualisierung der DNS-Einträge kann es einige Zeit dauern, bis alle Clients die aktualisierten DNS-Einstellungen erhalten und die Weiterleitung zum primären Arbeitsbereich wieder aufnehmen.

Verwenden Sie den Befehl POST, um zurück zum primären Arbeitsbereich zu wechseln:

POST

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/failback?api-version=2025-02-01

Wo:

• <subscription_id>: Die Abonnement-ID, die sich auf Ihren Arbeitsbereich bezieht.
• <resourcegroup_name>: Die Ressourcengruppe, die Ihre Arbeitsbereichressource enthält.
• <workspace_name>: Der Name des Arbeitsbereichs, zu dem während des Switchbacks gewechselt werden soll.

Der Befehl POST ist ein zeitintensiver Vorgang, der einige Zeit in Anspruch nehmen kann. Ein erfolgreicher Aufruf gibt einen 202-Statuscode zurück. Sie können den Bereitstellungsstatus Ihrer Anforderung nachverfolgen, wie im Bereitstellungsstatus des Arbeitsbereichs beschrieben.

Überwachen des inaktiven Arbeitsbereichs

Standardmäßig ist der aktive Bereich Ihres Arbeitsbereichs die Region, in der Sie den Arbeitsbereich erstellen, und die inaktive Region ist die sekundäre Region, in der Azure Monitor den replizierten Arbeitsbereich erstellt.

Wenn Sie ein Failover auslösen, kehrt sich dies um: Die sekundäre Region wird aktiviert, und die primäre Region wird inaktiv. Wir sagen, es ist inaktiv, da es nicht das direkte Ziel der Protokollaufnahme und Abfrageanforderungen ist.

Es ist hilfreich, die inaktive Region abzufragen, bevor Sie zwischen Regionen wechseln, um zu überprüfen, ob der Arbeitsbereich in der inaktiven Region die Protokolle enthält, die dort angezeigt werden sollen.

Inaktive Region abfragen

Verwenden Sie den folgenden GET-Befehl, um Protokolldaten in der inaktiven Region abzufragen:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=<query>&timespan=<timespan-in-ISO8601-format>&overrideWorkspaceRegion=<primary|secondary>

Wenn Sie beispielsweise eine kurze Abfrage wie Perf | count für den letzten Tag in Ihrer sekundären Region ausführen möchten, verwenden Sie Folgendes:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=Perf%20|%20count&timespan=P1D&overrideWorkspaceRegion=secondary

Sie können bestätigen, dass Azure Monitor Ihre Abfrage in der vorgesehenen Region ausführt, indem Sie diese Felder in der Tabelle LAQueryLogs überprüfen, die erstellt wird, wenn Sie die Abfrageüberwachung in Ihrem Log Analytics-Arbeitsbereich aktivieren:

• isWorkspaceInFailover: Gibt an, ob sich der Arbeitsbereich während der Abfrage im Switchovermodus befand. Der Datentyp ist boolesch (True, False).
• workspaceRegion: Der Bereich des Arbeitsbereichs, der von der Abfrage adressiert wird. Der Datentyp ist „String“.

Überwachen der Arbeitsbereichleistung mithilfe von Abfragen

Wir empfehlen, die Abfragen in diesem Abschnitt zu verwenden, um Warnregeln zu erstellen, die Sie über mögliche Probleme im Arbeitsbereich oder bei der Leistung informieren. Die Entscheidung für einen Switchover muss jedoch sorgfältig überlegt werden und sollte nicht automatisch getroffen werden.

In der Abfrageregel können Sie eine Bedingung definieren, um nach einer bestimmten Anzahl von Verstößen zum sekundären Arbeitsbereich zu wechseln. Weitere Informationen finden Sie unter Erstellen oder Bearbeiten einer Warnungsregel für die Protokollsuche.

Zwei wichtige Messgrößen für die Leistung des Arbeitsbereichs sind die Erfassungslatenz und das Erfassungsvolumen. In den folgenden Abschnitten werden diese Überwachungsoptionen erläutert.

Überwachen der End-to-End-Erfassungslatenz

Die Erfassungslatenz misst die Zeit, die für die Erfassung von Protokollen im Arbeitsbereich benötigt wird. Die Zeitmessung beginnt, wenn das erste protokollierte Ereignis eintritt, und endet, wenn das Protokoll in Ihrem Arbeitsbereich gespeichert wird. Die gesamte Erfassungslatenz setzt sich aus zwei Teilen zusammen:

• Agentlatenz: Die vom Agent erforderliche Zeit, um ein Ereignis zu melden.
• Latenz der Erfassungspipeline (Backend): Die für die Erfassungspipeline erforderliche Zeit zum Verarbeiten der Protokolle und Speichern in Ihrem Arbeitsbereich.

Unterschiedliche Datentypen weisen unterschiedliche Erfassungslatenz auf. Sie können die Erfassung für jeden Datentyp separat messen oder eine allgemeine Abfrage für alle Typen und eine feinere Abfrage für bestimmte Typen, die für Sie von größerer Bedeutung sind, erstellen. Wir empfehlen Ihnen, das 90. Perzentil der Erfassungslatenz zu messen, das empfindlicher auf Veränderungen reagiert als der Durchschnitt oder das 50. Perzentil (Median).

In den folgenden Abschnitten wird gezeigt, wie Sie die Erfassungslatenz für Ihren Arbeitsbereich mithilfe von Abfragen überprüfen können.

Die grundlegende Erfassungslatenz bestimmter Tabellen bewerten

Beginnen Sie mit der Ermittlung der Standardlatenz bestimmter Tabellen über mehrere Tage.

Diese Beispielabfrage erstellt ein Diagramm des 90. Perzentils der Erfassungslatenz in der Tabelle „Perf“:

// Assess the ingestion latency baseline for a specific data type
Perf
| where TimeGenerated > ago(3d) 
| project TimeGenerated, 
IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize LatencyIngestion90Percentile=percentile(IngestionDurationSeconds, 90) by bin(TimeGenerated, 1h) 
| render timechart

Nachdem Sie die Abfrage ausgeführt haben, überprüfen Sie die Ergebnisse und das gerenderte Diagramm, um die erwartete Latenzzeit für diese Tabelle zu ermitteln.

Überwachung und Warnung bei aktueller Erfassungslatenz

Nachdem Sie die grundlegende Erfassungslatenz für eine bestimmte Tabelle ermittelt haben, erstellen Sie eine Warnregel für die Protokollsuche für die Tabelle, die auf Änderungen der Latenz über einen kurzen Zeitraum basiert.

Diese Abfrage berechnet die Erfassungslatenz der letzten 20 Minuten:

// Track the recent ingestion latency (in seconds) of a specific table
Perf
| where TimeGenerated > ago(20m) 
| extend IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize Ingestion90Percent_seconds=percentile(IngestionDurationSeconds, 90)

Da mit gewissen Schwankungen zu rechnen ist, sollten Sie eine Warnregelbedingung erstellen, um zu überprüfen, ob die Abfrage einen Wert liefert, der deutlich über der Basislinie liegt.

Die Quelle der Erfassungslatenz ermitteln

Wenn Sie feststellen, dass die Erfassungslatenz insgesamt zunimmt, können Sie mithilfe von Abfragen feststellen, ob die Quelle der Latenz die Agenten oder die Erfassungspipeline sind.

Diese Abfrage stellt die Latenzzeit des 90. Perzentils der Agenten und der Pipeline getrennt dar:

// Assess agent and pipeline (backend) latency
Perf
| where TimeGenerated > ago(1h) 
| extend AgentLatencySeconds = (_TimeReceived-TimeGenerated)/1s,
    PipelineLatencySeconds=(ingestion_time()-_TimeReceived)/1s
| summarize percentile(AgentLatencySeconds,90), percentile(PipelineLatencySeconds,90) by bin(TimeGenerated,5m)
| render columnchart

Hinweis

Obwohl das Diagramm die 90-Perzentil-Daten als gestapelte Spalten anzeigt, entspricht die Summe der Daten in den beiden Diagrammen nicht der gesamten Erfassung des 90-Perzentils.

Überwachen des Erfassungsvolumens

Messungen des Erfassungsvolumens können dabei helfen, unerwartete Änderungen des gesamten oder tabellenspezifischen Erfassungsvolumens für Ihren Arbeitsbereich zu erkennen. Die Messungen des Abfragevolumens können Ihnen helfen, Leistungsprobleme bei der Erfassung von Protokollen zu erkennen. Einige nützliche Volumenmessungen umfassen:

• Gesamterfassungsvolumen pro Tabelle
• Konstante Erfassungsmenge (Stillstand)
• Erfassungsanomalien – Spitzen und Einbrüche im Erfassungsvolumen

In den folgenden Abschnitten wird gezeigt, wie Sie das Erfassungsvolumen für Ihren Arbeitsbereich mithilfe von Abfragen überprüfen können.

Überwachen des Gesamterfassungsvolumens pro Tabelle

Sie können eine Abfrage definieren, um das Erfassungsvolumen pro Tabelle in Ihrem Arbeitsbereich zu überwachen. Die Abfrage kann eine Warnung enthalten, die auf unerwartete Änderungen des Gesamtvolumens oder der tabellenspezifischen Volumina prüft.

Diese Abfrage berechnet das gesamte Erfassungsvolumen der letzten Stunde pro Tabelle in Megabyte pro Sekunde (MBs):

// Calculate total ingestion volume over the past hour per table
Usage 
| where TimeGenerated > ago(1h) 
| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated,1h), DataType

Überprüfen des Stillstands bei der Erfassung

Wenn Sie Protokolle über Agenten erfassen, können Sie den Heartbeat des Agenten zur Erkennung der Konnektivität verwenden. Ein stillstehender Heartbeat kann eine Unterbrechung der Erfassung von Protokollen in Ihrem Arbeitsbereich aufzeigen. Wenn die Abfragedaten einen Erfassungsstopp ergeben, können Sie eine Bedingung definieren, um eine gewünschte Reaktion auszulösen.

Die folgende Abfrage überprüft den Heartbeat des Agenten, um Konnektivitätsprobleme zu erkennen:

// Count agent heartbeats in the last ten minutes
Heartbeat 
| where TimeGenerated>ago(10m) 
| count

Überwachen von Erfassungsanomalien

Sie können Spitzen und Abfälle in den Daten Ihres Erfassungsvolumens im Arbeitsbereich auf verschiedene Weise erkennen. Verwenden Sie die Funktion series_decompose_anomalies(), um Anomalien aus den Erfassungsvolumina zu extrahieren, die Sie in Ihrem Arbeitsbereich überwachen, oder erstellen Sie Ihren eigenen Anomaliedetektor, um Ihre speziellen Arbeitsbereichsszenarien zu unterstützen.

Identifizierung von Anomalien mit series_decompose_anomalies

Die Funktion series_decompose_anomalies() identifiziert Anomalien in einer Reihe von Datenwerten. Diese Abfrage berechnet das stündliche Erfassungsvolumen jeder Tabelle in Ihrem Log Analytics-Arbeitsbereich und verwendet series_decompose_anomalies(), um Anomalien zu erkennen:

// Calculate hourly ingestion volume per table and identify anomalies
Usage
| where TimeGenerated > ago(24h)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| summarize
    Timestamp=make_list(TimeGenerated),
    IngestionVolumeMB=make_list(IngestionVolumeMB)
    by DataType
| extend series_decompose_anomalies(IngestionVolumeMB)
| mv-expand
    Timestamp,
    IngestionVolumeMB,
    series_decompose_anomalies_IngestionVolumeMB_ad_flag,
    series_decompose_anomalies_IngestionVolumeMB_ad_score,
    series_decompose_anomalies_IngestionVolumeMB_baseline
| where series_decompose_anomalies_IngestionVolumeMB_ad_flag != 0

Weitere Informationen über die Verwendung von series_decompose_anomalies() zur Erkennung von Anomalien in Protokolldaten finden Sie unter Erkennen und Analysieren von Anomalien mithilfe der KQL-Maschinenlernfunktionen in Azure Monitor.

Erstellen Eines eigenen Anomalieerkennungsmodul

Sie können ein benutzerdefiniertes Anomalieerkennungsmodul erstellen, um die Szenarioanforderungen für Ihre Arbeitsbereichskonfiguration zu unterstützen. Dieser Abschnitt enthält ein Beispiel zum Veranschaulichen des Prozesses.

Die folgende Abfrage berechnet:

• Erwartetes Erfassungsvolumen: Pro Stunde, nach Tabelle (basierend auf dem Median der Mediane, aber Sie können die Logik anpassen)
• Tatsächliches Erfassungsvolumen: Pro Stunde, nach Tabelle

Um unbedeutende Unterschiede zwischen dem erwarteten und dem tatsächlichen Erfassungsvolumen herauszufiltern, wendet die Abfrage zwei Filter an:

• Änderungsrate: Über 150 % oder unter 66 % des erwarteten Volumens pro Tabelle
• Änderungsvolumen: Gibt an, ob das erhöhte oder verringerte Volumen mehr als 0,1 % des monatlichen Volumens dieser Tabelle beträgt

// Calculate expected vs actual hourly ingestion per table
let TimeRange=24h;
let MonthlyIngestionByType=
    Usage
    | where TimeGenerated > ago(30d)
    | summarize MonthlyIngestionMB=sum(Quantity) by DataType;
// Calculate the expected ingestion volume by median of hourly medians
let ExpectedIngestionVolumeByType=
    Usage
    | where TimeGenerated > ago(TimeRange)
    | project TimeGenerated, DataType, Quantity
    | summarize IngestionMedian=percentile(Quantity, 50) by bin(TimeGenerated, 1h), DataType
    | summarize ExpectedIngestionVolumeMB=percentile(IngestionMedian, 50) by DataType;
Usage
| where TimeGenerated > ago(TimeRange)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| join kind=inner (ExpectedIngestionVolumeByType) on DataType
| extend GapVolumeMB = round(IngestionVolumeMB-ExpectedIngestionVolumeMB,2)
| where GapVolumeMB != 0
| extend Trend=iff(GapVolumeMB > 0, "Up", "Down")
| extend IngestedVsExpectedAsPercent = round(IngestionVolumeMB * 100 / ExpectedIngestionVolumeMB, 2)
| join kind=inner (MonthlyIngestionByType) on DataType
| extend GapAsPercentOfMonthlyIngestion = round(abs(GapVolumeMB) * 100 / MonthlyIngestionMB, 2)
| project-away DataType1, DataType2
// Determine whether the spike/deep is substantial: over 150% or under 66% of the expected volume for this data type
| where IngestedVsExpectedAsPercent > 150 or IngestedVsExpectedAsPercent < 66
// Determine whether the gap volume is significant: over 0.1% of the total monthly ingestion volume to this workspace
| where GapAsPercentOfMonthlyIngestion > 0.1
| project
    Timestamp=format_datetime(todatetime(TimeGenerated), 'yyyy-MM-dd HH:mm:ss'),
    Trend,
    IngestionVolumeMB,
    ExpectedIngestionVolumeMB,
    IngestedVsExpectedAsPercent,
    GapAsPercentOfMonthlyIngestion

Überwachen von erfolgreichen und fehlgeschlagenen Abfragen

Jede Abfrage gibt einen Antwortcode zurück, der den Erfolg oder Fehler anzeigt. Wenn die Abfrage fehlschlägt, enthält die Antwort auch die Fehlerarten. Eine hohe Anzahl von Fehlern kann auf ein Problem mit der Verfügbarkeit des Arbeitsbereichs oder der Leistung des Dienstes hinweisen.

Diese Abfrage zählt, bei wie vielen Abfragen ein Serverfehlercode zurückgegeben wurde:

// Count query errors
LAQueryLogs 
| where ResponseCode>=500 and ResponseCode<600 
| count

Zugehöriger Inhalt

• Überwachung der Gesundheit eines Log Analytics-Arbeitsbereichs
• Überwachen von Betriebsproblemen in Ihrem Log Analytics-Arbeitsbereich in Azure Monitor