Tolerantie verbeteren door uw Log Analytics-werkruimte in verschillende regio's te repliceren

Het repliceren van uw Log Analytics-werkruimte in verschillende regio's verbetert de tolerantie door u over te schakelen naar de gerepliceerde werkruimte en door te gaan met bewerkingen als er sprake is van een regionale storing. In dit artikel wordt uitgelegd hoe replicatie van Log Analytics-werkruimten werkt, hoe u uw werkruimte repliceert, hoe u kunt overschakelen en hoe u kunt bepalen wanneer u tussen uw gerepliceerde werkruimten schakelt.

Hier volgt een video met een kort overzicht van hoe replicatie van Log Analytics-werkruimten werkt:

Belangrijk

Hoewel we soms de termfailover gebruiken, bijvoorbeeld in de API-aanroep, wordt failover ook vaak gebruikt om een automatisch proces te beschrijven. Daarom gebruikt dit artikel de term overschakeling om te benadrukken dat de overschakeling naar de gerepliceerde werkruimte een actie is die door uzelf handmatig wordt geactiveerd.

Hoe replicatie van Log Analytics-werkruimte werkt

Uw oorspronkelijke werkruimte en regio worden de primaire werkruimte en regio genoemd. De gerepliceerde werkruimte en alternatieve regio worden de secundaire regio genoemd.

Het replicatieproces van de werkruimte maakt een kopie van uw werkruimte in de tweede regio. Het proces maakt de secundaire werkruimte met dezelfde configuratie als uw primaire werkruimte en Azure Monitor werkt de secundaire werkruimte automatisch bij met toekomstige wijzigingen die u aanbrengt in de configuratie van uw primaire werkruimte.

De secundaire werkruimte is alleen een 'schaduwwerkruimte' voor tolerantiedoeleinden. U kunt de secundaire werkruimte niet zien in Azure Portal en u kunt deze niet rechtstreeks beheren of openen.

Wanneer u werkruimtereplicatie inschakelt, verzendt Azure Monitor ook nieuwe logboeken die zijn opgenomen naar uw primaire werkruimte naar uw secundaire regio. Logboekgegevens die u in de werkruimte invoert voordat u werkruimtereplicatie activeert, worden niet gekopieerd.

Notitie

Met werkruimtereplicatie worden alle tabelschema's volledig gerepliceerd, maar worden alleen nieuwe logboeken verzonden die zijn opgenomen sinds de replicatie is geactiveerd. Logboeken die zijn opgenomen in de werkruimte voordat u werkruimtereplicatie inschakelt, worden niet gekopieerd.

Als een storing van invloed is op uw primaire regio, kunt u alle opname- en queryaanvragen overschakelen en omleiden naar uw secundaire regio. Nadat Azure de storing heeft beperkt en uw primaire werkruimte weer in orde is, kunt u teruggaan naar uw primaire regio.

Wanneer u overschakelt, wordt de secundaire werkruimte actief en wordt uw primaire werkruimte inactief. Azure Monitor neemt vervolgens nieuwe gegevens op via de opnamepijplijn in uw secundaire regio, in plaats van de primaire regio. Wanneer u overschakelt naar uw secundaire regio, repliceert Azure Monitor alle gegevens die u van de secundaire regio naar de primaire regio opneemt. Het proces is asynchroon en heeft geen invloed op uw opnamelatentie.

Notitie

Nadat u bent overgeschakeld naar de secundaire regio, als de primaire regio geen binnenkomende logboekgegevens kan verwerken, buffert Azure Monitor de gegevens in de secundaire regio maximaal 11 dagen. Tijdens de eerste vier dagen probeert Azure Monitor automatisch de gegevens periodiek te repliceren.

Bescherming tegen verlies van gegevens tijdens transport bij een regionale storing

Azure Monitor heeft verschillende mechanismen om ervoor te zorgen dat gegevens die worden overgedragen, niet verloren gaan wanneer er een fout optreedt in de primaire regio.

Azure Monitor beveiligt gegevens die het opname-eindpunt van de primaire regio bereiken wanneer de pijplijn van de primaire regio niet beschikbaar is om de gegevens te verwerken. Wanneer de pijplijn beschikbaar wordt, blijft deze gegevens verwerken tijdens het transport, en Azure Monitor verwerkt en repliceert de gegevens naar de secundaire regio.

Als het opname-eindpunt van de primaire regio niet beschikbaar is, probeert de Azure Monitor-agent regelmatig logboekgegevens naar het eindpunt te verzenden. Het eindpunt voor gegevensopname in de secundaire regio begint enkele minuten na het activeren van overschakeling gegevens van agents te ontvangen.

Als u uw eigen client schrijft om logboekgegevens naar uw Log Analytics-werkruimte te verzenden, moet u ervoor zorgen dat de client mislukte opnameaanvragen afhandelt.

Implementatieoverwegingen

Notitie

Werkruimtereplicatie biedt momenteel geen ondersteuning voor replicatie van hulptabellen en mag niet worden ingeschakeld voor werkruimten met hulptabellen. Hulptabellen worden niet gerepliceerd en worden daarom niet beschermd tegen gegevensverlies in het geval van een regionale storing en zijn niet beschikbaar wanneer u overschakelt naar uw secundaire werkruimte.

• Werkruimtebeheerbewerkingen kunnen niet worden gestart tijdens de overschakeling, waaronder:

  • Wijziging van de retentie van werkruimte, prijscategorie, dagelijkse limiet, enzovoort
  • Wijziging van netwerkinstellingen
  • Het schema wijzigen via nieuwe aangepaste logboeken of het verbinden van platformlogboeken van nieuwe resourceproviders, zoals het verzenden van diagnostische logboeken vanuit een nieuw resourcetype

• Tijdens het failoverproces worden uw DNS-records (Domain Name System) bijgewerkt om alle opnameaanvragen om te leiden naar uw secundaire regio voor verwerking. Sommige HTTP-clients hebben 'plakverbindingen' en kunnen langer duren om dns-updates op te halen. Tijdens de overstap proberen deze clients mogelijk enige tijd logboeken op te nemen via de primaire regio. Mogelijk verwerkt u logboeken in uw primaire werkruimte door verschillende clients te gebruiken, waaronder de verouderde Log Analytics Agent, Azure Monitor Agent, code (met behulp van de Logs Ingestion API of de verouderde HTTP-gegevensverzamelings-API) en andere services, zoals Microsoft Sentinel.

Belangrijk

Waarschuwingsregels voor zoeken in logboeken blijven werken wanneer u schakelt tussen regio's, tenzij de Waarschuwingen-service in de actieve regio niet goed werkt of de waarschuwingsregels niet beschikbaar zijn. Dit kan bijvoorbeeld gebeuren als de regio waarin de waarschuwingsregels zijn gemaakt, volledig niet beschikbaar is. Replicatie van waarschuwingsregels tussen regio's wordt niet automatisch uitgevoerd als onderdeel van werkruimtereplicatie, maar kan worden uitgevoerd door de gebruiker (bijvoorbeeld door te exporteren vanuit de primaire regio en te importeren naar de secundaire regio).

• Met de opschoningsbewerking, waarmee records uit een werkruimte worden verwijderd, worden de relevante records verwijderd uit zowel de primaire als de secundaire werkruimten. Als een van de werkruimte-exemplaren niet beschikbaar is, mislukt de opschoonoperatie.

• Microsoft Sentinel vernieuwt elke 12 dagen logboeken in de tabellen Watchlist en Threat Intelligence. Omdat alleen nieuwe logboeken worden opgenomen in de gerepliceerde werkruimte, kan het tot 12 dagen duren voordat de watchlist- en bedreigingsinformatiegegevens volledig naar de secundaire locatie worden gerepliceerd.

• Tijdens de overgang wordt de mogelijkheid van de oplossing om zich te richten op de verouderde Log Analytics-agent niet ondersteund. Tijdens de overschakeling worden oplossingsgegevens van alle agents opgenomen.

• Deze functies worden momenteel niet ondersteund of slechts gedeeltelijk ondersteund:

  Kenmerk	Ondersteuning
  Plannen voor hulptabellen	Wordt niet ondersteund. Azure Monitor repliceert geen gegevens in tabellen met het hulplogboekplan naar uw secundaire werkruimte. Deze gegevens worden daarom niet beschermd tegen gegevensverlies in het geval van een regionale storing en zijn niet beschikbaar wanneer u overschakelt naar uw secundaire werkruimte.
  Vacatures zoeken, Herstellen	Gedeeltelijk ondersteund: met zoektaken en herstelbewerkingen worden tabellen gemaakt en gevuld met zoekresultaten of herstelde gegevens. Nadat u werkruimtereplicatie hebt ingeschakeld, worden nieuwe tabellen die voor deze bewerkingen zijn gemaakt, gerepliceerd naar uw secundaire werkruimte. Tabellen die zijn ingevuld voordat u replicatie inschakelt, worden niet gerepliceerd. Als deze bewerkingen worden uitgevoerd wanneer u overschakelt, is het resultaat onverwacht. Het kan succesvol voltooien maar niet repliceren, of het kan mislukken, afhankelijk van de gezondheid van uw werkruimte en het precieze moment.
  Application Insights met betrekking tot Log Analytics workspaces	Niet ondersteund
  VM-Inzichten	Niet ondersteund
  Container Insights	Niet ondersteund
  Privélinks	Niet ondersteund tijdens failover

Ondersteunde regio’s

Werkruimtereplicatie wordt momenteel ondersteund voor werkruimten in een beperkte set regio's, ingedeeld op regiogroepen (groepen van geografisch aangrenzende regio's). Wanneer u replicatie inschakelt, selecteert u een secundaire locatie in de lijst met ondersteunde regio's in dezelfde regiogroep als de primaire locatie van de werkruimte. Een werkruimte in Europa - west kan bijvoorbeeld worden gerepliceerd in Europa - noord, maar niet in VS - west 2, omdat deze regio's zich in verschillende regiogroepen bevinden.

Deze regiogroepen en regio's worden momenteel ondersteund:

Regiogroep	Hoofdregio's	Secundaire regio's (replicatielocaties)
Noord-Amerika	Canada - centraal Canada Oost Centraal-VS Oost-VS Oost US 2* VS - noord-centraal VS - zuid-centraal* West-Centraal VS Westelijke VS Westelijke VS 2 Westelijke VS 3	Canada - centraal Centraal-VS Oost-VS Oost US 2* Westelijke VS Westelijke Verenigde Staten 2
Zuid-Amerika	Brazilië - zuid Brazilië - zuidoost	Brazilië - zuid Brazilië - zuidoost
Europa	Frankrijk - centraal Frankrijk - zuid Duitsland - noord Duitsland - west-centraal Italië - noord Europa - noord Noorwegen - oost Noorwegen West Polen - centraal Zuid Verenigd Koninkrijk Spanje - centraal Zweden - centraal Zuid-Zweden Zwitserland - noord West-Zwitserland West-Europa West Verenigd Koninkrijk	Frankrijk - centraal Europa - noord Zuid Verenigd Koninkrijk West-Europa
Midden-Oosten	Qatar Centraal UAE Central VAE Noord	Qatar Centraal UAE Central VAE Noord
India	Centraal India Zuid-India	Centraal India Zuid-India
Azië en Stille Oceaan	Oost-Azië Oost-Japan Japan Westen Centraal Korea Zuid-Korea Zuidoost-Azië	Oost-Azië Oost-Japan Centraal-Korea
Oceanië	Australië - centraal Australië - centraal 2 Australië - oost Australië - zuidoost	Australië - centraal Australië - oost Australië - zuidoost
Afrika	Zuid-Afrika - noord Zuid-Afrika West	Zuid-Afrika - noord Zuid-Afrika West

Notitie

Werkruimten in VS - oost, VS - oost 2 en VS - zuid-centraal kunnen alleen worden gerepliceerd naar secundaire regio's buiten die set van drie. Selecteer een andere secundaire locatie in de regiogroep Noord-Amerika.

Vereisten voor gegevensopslag

Verschillende klanten hebben verschillende vereisten voor gegevenslocatie, dus het is belangrijk dat u bepaalt waar uw gegevens worden opgeslagen. Azure Monitor verwerkt en slaat logboeken op in de primaire en secundaire regio's die u kiest. Zie Ondersteunde regio's voor meer informatie.

Ondersteuning voor Microsoft Sentinel en andere services

Verschillende services en functies die gebruikmaken van Log Analytics-werkruimten zijn compatibel met werkruimtereplicatie en switchover. Deze services en functies blijven werken wanneer u overschakelt naar de secundaire werkruimte.

Regionale netwerkproblemen die leiden tot latentie van logboekopname, kunnen bijvoorbeeld van invloed zijn op Microsoft Sentinel-klanten. Klanten die gebruikmaken van gerepliceerde werkruimten, kunnen overschakelen naar hun secundaire regio om verder te werken met hun Log Analytics-werkruimte en Sentinel. Als het netwerkprobleem echter van invloed is op de status van de Sentinel-service, wordt het probleem niet opgelost door over te schakelen naar een andere regio.

Sommige Azure Monitor-ervaringen, waaronder Application Insights en VM Insights, zijn momenteel slechts gedeeltelijk compatibel met werkruimtereplicatie en switchover. Zie Implementatieoverwegingen voor de volledige lijst.

Prijsmodel

Wanneer u werkruimtereplicatie inschakelt, worden er kosten in rekening gebracht voor de replicatie van alle gegevens die u in uw werkruimte opneemt.

Belangrijk

Als u gegevens naar uw werkruimte verzendt met behulp van de Azure Monitor-agent, de Logboekopname-API, Azure Event Hubs of andere gegevensbronnen die gebruikmaken van regels voor gegevensverzameling, moet u ervoor zorgen dat u uw regels voor gegevensverzameling koppelt aan het eindpunt voor gegevensverzameling van uw werkruimte. Deze koppeling zorgt ervoor dat de gegevens die u opneemt, worden gerepliceerd naar uw secundaire werkruimte. Als u uw regels voor gegevensverzameling niet koppelt aan het eindpunt voor het verzamelen van werkruimtegegevens, worden er nog steeds kosten in rekening gebracht voor alle gegevens die u in uw werkruimte opneemt, ook al worden de gegevens niet gerepliceerd.

Vereiste toestemmingen

Actie	Vereiste toestemmingen
Werkruimtereplicatie inschakelen	Microsoft.OperationalInsights/workspaces/write en Microsoft.Insights/dataCollectionEndpoints/write machtigingen, zoals geleverd door de ingebouwde rol Monitoringbijdrager, bijvoorbeeld
Overschakelen en terugschakelen (activeer failover en failback)	Microsoft.OperationalInsights/locations/workspaces/failover, Microsoft.OperationalInsights/workspaces/failback, Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action en Microsoft.Insights/dataCollectionEndpoints/triggerFailback/action machtigingen, zoals opgegeven door de ingebouwde rol Monitoring-bijdrager, bijvoorbeeld
Werkruimtestatus controleren	Microsoft.OperationalInsights/workspaces/read machtigingen voor de Log Analytics-werkruimte, zoals geleverd door de standaardrol Monitoringbijdrager, bijvoorbeeld

Werkruimtereplicatie in- en uitschakelen

U schakelt replicatie van werkruimten in en uit met behulp van een REST-opdracht. De opdracht activeert een langdurige bewerking, wat betekent dat het enkele minuten kan duren voordat de nieuwe instellingen zijn toegepast. Nadat u replicatie hebt ingeschakeld, kan het maximaal één uur duren voordat alle tabellen (gegevenstypen) worden gerepliceerd en sommige gegevenstypen kunnen beginnen met repliceren voordat andere. Wijzigingen die u aanbrengt in tabelschema's nadat u werkruimtereplicatie hebt ingeschakeld, bijvoorbeeld nieuwe aangepaste logboektabellen of aangepaste velden die u maakt, of diagnostische logboeken die zijn ingesteld voor nieuwe resourcetypen, kunnen tot één uur duren om te beginnen met repliceren.

Gebruikt u een toegewezen cluster?

Als uw werkruimte is gekoppeld aan een toegewezen cluster, moet u eerst replicatie inschakelen op het cluster en vervolgens alleen in de werkruimte. Met deze bewerking maakt u een tweede cluster in uw secundaire regio (geen extra kosten buiten de replicatiekosten), zodat uw werkruimte een toegewezen cluster kan blijven gebruiken, zelfs als u een failover uitvoert. Dit betekent ook dat functies zoals door cluster beheerde sleutels (CMK) blijven werken (met dezelfde sleutel) tijdens een failover. Zodra replicatie tussen regio's is ingeschakeld, gaat u verder met het inschakelen van replicatie voor een of meer werkruimten die aan dit cluster zijn gekoppeld.

Belangrijk

Zodra de clusterreplicatie is ingeschakeld, vereist het wijzigen van de replicatiebestemming dat u de replicatie uitschakelt en opnieuw inschakelt voor een andere locatie.

Gebruik de volgende PUT-opdracht om replicatie in te schakelen op uw toegewezen cluster. Deze aanroep retourneert 202. Het is een langdurige bewerking die enige tijd kan duren en u kunt de exacte status bijhouden, zoals wordt uitgelegd in de inrichtingsstatus van het cluster controleren.

Gebruik deze PUT opdracht om clusterreplicatie in te schakelen:

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>"
}

Waar:

• <subscription_id>: De abonnements-id die is gerelateerd aan uw cluster
• <resourcegroup_name> : De resourcegroep die uw Log Analytics-clusterresource bevat
• <cluster_name>: De naam van uw toegewezen cluster
• <primary_region>: De primaire regio voor uw toegewezen Log Analytics-cluster
• <secondary_region>: de regio waar Azure Monitor het secundaire dedicated cluster creëert

Controleer de voorzieningsstatus van het cluster

Voer deze GET opdracht uit om de inrichtingsstatus van uw cluster te controleren:

GET

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

Waar:

• <subscription_id>: De abonnements-id die is gerelateerd aan uw cluster
• <resourcegroup_name>: De resourcegroep die uw Log Analytics-clusterresource bevat
• <cluster_name>: De naam van uw Log Analytics-cluster

Gebruik de GET opdracht om te controleren of de inrichtingsstatus van het cluster verandert van Updating in Succeededen de secundaire regio is ingesteld zoals verwacht.

Notitie

Wanneer u clusterreplicatie inschakelt, wordt een nieuw cluster ingericht op de secundaire locatie. Dit proces kan 1-2 uur duren.

Werkruimtereplicatie inschakelen

Gebruik deze PUT opdracht om replicatie in te schakelen voor uw Log Analytics-werkruimte:

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>"
}

Waar:

• <subscription_id>: De abonnements-id die is gerelateerd aan uw werkruimte
• <resourcegroup_name> : De resourcegroep die uw Log Analytics-werkruimteresource bevat
• <workspace_name>: De naam van uw werkruimte
• <primary_region>: De primaire regio voor uw Log Analytics-werkruimte
• <secondary_region>: De regio waarin Azure Monitor de secundaire werkruimte maakt

Zie Ondersteunde regio's voor de ondersteunde location waarden.

De PUT opdracht is een langdurige bewerking die enige tijd kan duren. Een geslaagde aanroep retourneert een 200 statuscode. U kunt de inrichtingsstatus van uw aanvraag bijhouden, zoals beschreven in Inrichtingsstatus van werkruimte controleren.

Belangrijk

Als uw werkruimte is gekoppeld aan een toegewezen cluster, schakelt u eerst replicatie in op het cluster. Houd er ook rekening mee dat de secundaire locatie van uw werkruimte identiek moet zijn aan de secundaire locatie van het toegewezen cluster.

Inrichtingsstatus van werkruimte controleren

Voer deze GET opdracht uit om de inrichtingsstatus van uw werkruimte te controleren:

GET

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

Waar:

• <subscription_id>: de abonnements-id die is gerelateerd aan uw werkruimte.
• <resourcegroup_name>: De resourcegroep die uw Log Analytics-werkruimte bevat.
• <workspace_name>: de naam van uw Log Analytics-werkruimte.

Gebruik de GET opdracht om te controleren of de inrichtingsstatus van de werkruimte verandert van Updating in Succeededen de secundaire regio is ingesteld zoals verwacht.

Notitie

Wanneer u replicatie inschakelt voor werkruimten die communiceren met Sentinel, kan het maximaal 12 dagen duren voordat de watchlist- en bedreigingsinformatiegegevens volledig naar de secundaire werkruimte worden gerepliceerd.

Controleren of replicatie is ingeschakeld in een werkruimte

Als u wilt controleren of en waar werkruimtereplicatie is ingeschakeld, controleert u deze instellingen.

Selecteer in Azure Portal het werkruimteoverzicht>. Als replicatie is ingeschakeld, wordt in de sectie Essentials de secundaire locatie weergegeven, die de regio van de gerepliceerde werkruimte aangeeft.

Dezelfde sectie Essentials heeft een JSON-weergave die de replicatiedetails weergeeft als een JSON-object, dat ook beschikbaar is via REST/CLI.

Regels voor gegevensverzameling koppelen aan het eindpunt voor het verzamelen van werkruimtegegevens

Azure Monitor Agent, de Logboekopname-API en Azure Event Hubs verzamelen gegevens en verzenden deze naar de bestemming die u opgeeft op basis van de wijze waarop u uw regels voor gegevensverzameling (DCR) instelt.

Als u regels voor gegevensverzameling hebt die gegevens naar uw primaire werkruimte verzenden, moet u de regels koppelen aan een eindpunt voor systeemgegevensverzameling (DCE), dat azure Monitor maakt wanneer u werkruimtereplicatie inschakelt. De naam van het eindpunt voor het verzamelen van werkruimtegegevens is identiek aan uw werkruimte-id. Alleen regels voor gegevensverzameling die u aan het eindpunt voor gegevensverzameling van de werkruimte koppelt, schakelen replicatie en overschakeling in. Met dit gedrag kunt u de set logboekstreams opgeven die moeten worden gerepliceerd, zodat u de replicatiekosten kunt beheren.

Als u gegevens die u verzamelt wilt repliceren met behulp van regels voor gegevensverzameling, koppelt u de regels voor gegevensverzameling aan het eindpunt van de werkruimtegegevensverzameling:

1. Selecteer in Azure Portal regels voor gegevensverzameling.

2. Selecteer in het scherm Regels voor gegevensverzameling een regel voor gegevensverzameling waarmee gegevens worden verzonden naar uw primaire Log Analytics-werkruimte.

3. Op de Overzicht pagina van de gegevensverzamelingsregel, selecteer Configureer DCE en selecteer het eindpunt voor het verzamelen van gegevens van de werkruimte uit de beschikbare lijst.

   

   Controleer de eigenschappen van het werkruimteobject voor meer informatie over de System DCE.

Belangrijk

Regels voor gegevensverzameling die zijn verbonden met een eindpunt voor het verzamelen van werkruimtegegevens, kunnen alleen gericht zijn op die specifieke werkruimte. De regels voor het verzamelen van gegevens mogen niet gericht zijn op andere bestemmingen, zoals andere werkruimten of Azure Storage-accounts.

Wat u moet controleren als de replicatie van de werkruimte mislukt

• Is de werkruimte gekoppeld aan een toegewezen cluster?
  • Replicatie moet zijn ingeschakeld op het cluster voordat deze kan worden ingeschakeld in de werkruimte.
  • Zowel cluster- als werkruimtereplicatie moeten worden ingesteld op dezelfde secundaire locatie. Als het cluster bijvoorbeeld wordt gerepliceerd naar Europa - noord, kunnen de werkruimten die eraan zijn gekoppeld, alleen worden gerepliceerd naar Europa - noord.
• Hebt u de REST API gebruikt om replicatie in te schakelen?
  • Controleer of u API-versie 2025-02-01 of hoger hebt gebruikt.
• Bevindt de primaire werkruimte zich in VS - oost, VS - oost 2 of VS - zuid-centraal?
  • VS - oost, VS - oost 2 en VS - zuid-centraal kunnen niet naar elkaar worden gerepliceerd.
• Waar bevindt de primaire werkruimte zich en waar bevindt zich de secundaire werkruimte? Beide locaties moeten zich in dezelfde regiogroep bevinden. Werkruimten in amerikaanse regio's kunnen bijvoorbeeld geen replicatie (secundaire regio) in Europa hebben en omgekeerd. Zie Ondersteunde regio's voor de lijst met regiogroepen.
• Hebt u de vereiste toestemmingen?
• Hebt u voldoende tijd voor het voltooien van de replicatiebewerking toegestaan? replicatie is een langdurige bewerking. Controleer de status van de operatie zoals uitgelegd in Controleer de inrichtingsstatus van de werkruimte.
• Hebt u geprobeerd replicatie opnieuw in te schakelen om de secundaire locatie van de werkruimte te wijzigen? Als u de locatie van uw secundaire werkruimte wilt wijzigen, moet u eerst werkruimtereplicatie uitschakelen, de bewerking alleen voltooien en vervolgens replicatie naar een andere secundaire locatie inschakelen.

Wat moet u controleren wanneer werkruimtereplicatie is ingesteld, maar logboeken niet worden gerepliceerd?

• Het kan een uur duren voordat de replicatie wordt toegepast en sommige gegevenstypen kunnen beginnen met repliceren voordat andere.
• Logboeken die zijn opgenomen in de werkruimte voordat replicatie is ingeschakeld, worden niet gekopieerd naar de secundaire werkruimte. Alleen logboeken die worden opgenomen nadat replicatie is ingeschakeld, worden gerepliceerd.
• Als sommige logboeken worden gerepliceerd en andere niet, controleert u of alle regels voor gegevensverzameling (DCR's) waarmee logboeken naar de werkruimte worden gestreamd, correct zijn geconfigureerd. Als u de DCR's wilt bekijken die zijn gericht op de werkruimte, raadpleegt u het tabblad Gegevensverzameling van Log Analytics Workspace Insights in Azure Portal.

Werkruimtereplicatie uitschakelen

Gebruik deze PUT opdracht om replicatie voor een werkruimte uit te schakelen:

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>"
}

Waar:

• <subscription_id>: de abonnements-id die is gerelateerd aan uw werkruimte.
• <resourcegroup_name> : De resourcegroep die uw werkruimteresource bevat.
• <workspace_name>: De naam van uw werkruimte.
• <primary_region>: de primaire regio voor uw werkruimte.

De PUT opdracht is een langdurige bewerking die enige tijd kan duren. Een geslaagde aanroep retourneert een 200 statuscode. U kunt de inrichtingsstatus van uw aanvraag bijhouden, zoals beschreven in Inrichtingsstatus van werkruimte controleren.

Belangrijk

Als u een toegewezen cluster gebruikt, moet u clusterreplicatie uitschakelen nadat u replicatie hebt uitgeschakeld voor elke werkruimte die aan dit cluster is gekoppeld.

Clusterreplicatie uitschakelen

Het uitschakelen van clusterreplicatie kan alleen worden uitgevoerd nadat replicatie is uitgeschakeld voor alle werkruimten die aan dit cluster zijn gekoppeld (indien eerder ingeschakeld). Gebruik deze PUT opdracht om replicatie voor een werkruimte uit te schakelen:

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>"
}

Waar:

• <subscription_id>: de abonnements-id die is gerelateerd aan uw cluster.
• <resourcegroup_name> : De resourcegroep die uw clusterresource bevat.
• <workspace_name>: De naam van uw cluster.
• <primary_region>: de primaire regio voor uw cluster.

De PUT opdracht is een langdurige bewerking die enige tijd kan duren. Een geslaagde aanroep retourneert een 200 statuscode. U kunt de inrichtingsstatus van uw aanvraag bijhouden, zoals beschreven in Inrichtingsstatus van werkruimte controleren.

Notitie

Zodra de replicatie is uitgeschakeld en het gerepliceerde cluster is gewist, worden de gerepliceerde logboeken verwijderd en kunnen ze niet meer worden benaderd. De oorspronkelijke kopie op uw primaire locatie wordt in dit proces niet gewijzigd.

Belangrijk

Het proces voor het verwijderen van clusterreplicatie duurt 14 dagen. Als u dit proces sneller wilt voltooien, maakt u een Azure-ondersteuningsaanvraag.

De status van werkruimte en service bewaken en controleren

Opnamelatentie of queryfouten zijn voorbeelden van problemen die vaak kunnen worden verwerkt door failover naar uw secundaire regio. Dergelijke problemen kunnen worden gedetecteerd met behulp van Service Health-meldingen en logboekquery's.

Service Health-meldingen zijn handig voor servicegerelateerde problemen. Als u problemen wilt identificeren die van invloed zijn op uw specifieke werkruimte (en mogelijk niet de hele service), kunt u andere metingen gebruiken:

• Waarschuwingen maken op basis van de gezondheid van de werkruimtebronnen

• Uw eigen drempelwaarden instellen voor metrische gegevens over de status van de werkruimte

• Maak uw eigen bewakingsquery's om te fungeren als aangepaste statusindicatoren voor uw werkruimte, zoals beschreven in Werkruimteprestaties bewaken met behulp van query's, om:

  • Opnamelatentie per tabel meten
  • Bepalen of de bron van latentie de verzamelingsagenten of de opnamepijplijn is
  • Afwijkingen in innamevolumes per tabel en hulpbron bewaken
  • Het slagingspercentage van query's per tabel, gebruiker of resource bewaken
  • Waarschuwingen maken op basis van uw query's

Notitie

U kunt ook logqueries gebruiken om uw tweede werkruimte te bewaken, maar houd rekening met dat logboekreplicatie wordt uitgevoerd in batchbewerkingen. De gemeten latentie kan fluctueren en geeft geen gezondheidsprobleem aan met uw tweede werkruimte. Zie De inactieve werkruimte controleren voor meer informatie.

Overschakelen naar uw secundaire werkruimte

Tijdens de overschakeling werken de meeste bewerkingen hetzelfde als wanneer u de primaire werkruimte en regio gebruikt. Sommige bewerkingen hebben echter iets ander gedrag of worden geblokkeerd. Zie Implementatieoverwegingen voor meer informatie.

Wanneer moet ik overschakelen?

U bepaalt wanneer u wilt overschakelen naar uw secundaire werkruimte en overschakelt naar uw primaire werkruimte op basis van doorlopende prestatie- en statuscontrole en uw systeemstandaarden en -vereisten.

Er zijn verschillende punten om rekening mee te houden in uw plan voor overschakeling, zoals beschreven in de volgende subsecties.

Type probleem en bereik

Met het overschakelingsproces worden opname- en queryaanvragen naar uw secundaire regio gerouteerd, waardoor meestal een defect onderdeel wordt overgeslagen dat latentie of storing veroorzaakt in uw primaire regio. Als gevolg hiervan is overschakeling waarschijnlijk niet handig als:

• Er is een probleem tussen regio's met een onderliggende resource. Als bijvoorbeeld dezelfde resourcetypen mislukken in zowel uw primaire als secundaire regio's.
• Je ondervindt een probleem met betrekking tot werkruimtebeheer, zoals het wijzigen van de retentie van de werkruimte. Beheerhandelingen van werkruimten worden altijd uitgevoerd in uw primaire regio. Tijdens de overschakeling worden bewerkingen voor werkruimtebeheer geblokkeerd.

De duur van het probleem

Overschakeling is niet onmiddellijk. Het proces van het omleiden van aanvragen is afhankelijk van DNS-updates, die sommige clients binnen enkele minuten ophalen, terwijl andere meer tijd in beslag kunnen nemen. Daarom is het handig om te begrijpen of het probleem binnen een paar minuten kan worden opgelost. Als het waargenomen probleem consistent of doorlopend is, wacht u niet om over te schakelen. Hieronder volgen een aantal voorbeelden:

• Invoer: Problemen met de invoerpijplijn in uw primaire regio kunnen de datareproductie naar uw secundaire werkruimte beïnvloeden. Tijdens de overschakeling worden logs in plaats daarvan verzonden naar de dataverwerkingslijn in de secundaire regio.

• Query: Als queries in uw primaire werkruimte mislukken of een time-out bereiken, kan dit de logboekzoekwaarschuwingen beïnvloeden. In dit scenario schakelt u over naar uw secundaire werkruimte om ervoor te zorgen dat al uw waarschuwingen correct worden geactiveerd.

Secundaire werkruimtegegevens

Logboeken die zijn opgenomen in uw primaire werkruimte voordat u replicatie inschakelt, worden niet gekopieerd naar de secundaire werkruimte. Als u werkruimtereplicatie drie uur geleden hebt ingeschakeld en u nu overschakelt naar uw secundaire werkruimte, kunnen uw query's alleen gegevens retourneren van de afgelopen drie uur.

Voordat u tijdens het overschakelen tussen regio's overschakelt, moet uw secundaire werkruimte een nuttig volume aan logboeken bevatten. We raden u aan ten minste één week te wachten nadat u replicatie hebt ingeschakeld voordat u overschakelt. De zeven dagen zorgen ervoor dat er voldoende gegevens beschikbaar zijn in uw secundaire regio.

Overschakeling activeren

Controleer voordat u overschakelt dat de replicatiebewerking van de werkruimte succesvol is voltooid. Overschakeling slaagt alleen wanneer de secundaire werkruimte correct is geconfigureerd.

Gebruik deze POST opdracht om over te schakelen naar uw secundaire werkruimte:

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

Waar:

• <subscription_id>: de abonnements-id die is gerelateerd aan uw werkruimte.
• <resourcegroup_name> : De resourcegroep die uw werkruimteresource bevat.
• <secondary_region>: De regio waar u tijdens de overstap naar wilt overschakelen.
• <workspace_name>: De naam van de werkruimte die moet worden overgeschakeld tijdens de overschakeling.

De POST opdracht is een langdurige bewerking die enige tijd kan duren. Een geslaagde aanroep retourneert een 202 statuscode. U kunt de inrichtingsstatus van uw aanvraag bijhouden, zoals beschreven in Inrichtingsstatus van werkruimte controleren.

Wat u moet controleren als overschakeling faalt

• Hebt u de REST API gebruikt om overschakeling (failover) te activeren?
  • Controleer of u API-versie 2025-02-01 of hoger hebt gebruikt.
  • Controleer of de secundaire locatie in de failoveropdracht de secundaire locatie is die is ingesteld voor deze werkruimte. Deze informatie is beschikbaar in de Azure Portal-weergave van de werkruimte en via API.
• Voor het schakelen tussen regio's is een rol van Log Analytics-inzender vereist voor de resourcegroep van de werkruimte en niet alleen voor de werkruimte zelf.

Terugschakelen naar uw primaire werkruimte

Het switchback-proces annuleert het opnieuw omleiden van query's en logboekopnameaanvragen naar de secundaire werkruimte. Wanneer u terugschakelt, stuurt Azure Monitor opnieuw queries en logboekverzoeken voor opname naar uw primaire werkruimte.

Wanneer u overschakelt naar uw secundaire regio, repliceert Azure Monitor logboeken van uw secundaire werkruimte naar uw primaire werkruimte. Als een storing van invloed is op het logboekopnameproces in de primaire regio, kan het even duren voordat Azure Monitor de opname van de gerepliceerde logboeken naar uw primaire werkruimte voltooit.

Wanneer moet ik terugschakelen?

Er zijn verschillende punten om rekening mee te houden in uw planning voor een switchback, zoals beschreven in de volgende subsecties.

Logreplicatiestatus

Controleer voordat u terugschakelt of Azure Monitor alle logboeken heeft gerepliceerd die zijn opgenomen tijdens de overschakeling naar de primaire regio. Als u terugschakelt voordat alle logboeken worden gerepliceerd naar de primaire werkruimte, kunnen uw query's gedeeltelijke resultaten retourneren totdat de logboekopname is voltooid.

U kunt een query uitvoeren op uw primaire werkruimte in Azure Portal voor de inactieve regio, zoals beschreven in De inactieve werkruimte controleren.

Gezondheid van primaire werkruimte

Er zijn twee belangrijke gezondheidsaspecten die moeten worden nagegaan ter voorbereiding van de terugkeer naar uw primaire werkruimte.

• Controleer of er geen openstaande Service Health-meldingen zijn voor de primaire werkruimte en regio.
• Controleer of uw primaire werkruimte logboeken opneemt en query's verwerkt zoals verwacht.

Zie De inactieve werkruimte controleren voor voorbeelden van het uitvoeren van query's op uw primaire werkruimte wanneer uw secundaire werkruimte actief is en het omleiden van aanvragen naar uw secundaire werkruimte omzeilen.

Schakel terugschakeling in

Voordat u terugschakelt, moet u de status van de primaire werkruimte bevestigen en de replicatie van logboeken voltooien.

Het switchback-proces werkt uw DNS-records bij. Nadat de DNS-records zijn bijgewerkt, kan het even duren voordat alle clients de bijgewerkte DNS-instellingen ontvangen en de routering naar de primaire werkruimte hervatten.

Als u wilt terugkeren naar uw primaire werkruimte, gebruikt u deze POST opdracht:

POST

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

Waar:

• <subscription_id>: de abonnements-id die is gerelateerd aan uw werkruimte.
• <resourcegroup_name> : De resourcegroep die uw werkruimteresource bevat.
• <workspace_name>: De naam van de werkruimte om naar terug te schakelen tijdens de omschakeling.

De POST opdracht is een langdurige bewerking die enige tijd kan duren. Een geslaagde aanroep retourneert een 202 statuscode. U kunt de inrichtingsstatus van uw aanvraag bijhouden, zoals beschreven in Inrichtingsstatus van werkruimte controleren.

De inactieve werkruimte controleren

De actieve regio van uw werkruimte is standaard de regio waar u de werkruimte maakt en de inactieve regio de secundaire regio is, waarbij Azure Monitor de gerepliceerde werkruimte maakt.

Wanneer u een failover activeert, vindt er een omschakeling plaats: de secundaire regio wordt geactiveerd en de primaire regio wordt inactief. We zeggen dat het inactief is omdat het niet het directe doel is van logboekopname en queryaanvragen.

Het is handig om een query uit te voeren op de inactieve regio voordat u tussen regio's schakelt om te controleren of de werkruimte in de inactieve regio de logboeken bevat die u daar verwacht te zien.

Een inactieve regio opvragen

Als u een query wilt uitvoeren op logboekgegevens in de inactieve regio, gebruikt u deze GET-opdracht:

GET

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

Als u bijvoorbeeld een korte query wilt uitvoeren, zoals Perf | count de afgelopen dag in uw secundaire regio, gebruikt u:

GET

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

U kunt controleren of Azure Monitor uw query uitvoert in de beoogde regio door deze velden in de LAQueryLogs tabel te controleren, die wordt gemaakt wanneer u querycontrole inschakelt in uw Log Analytics-werkruimte:

• isWorkspaceInFailover: Geeft aan of de werkruimte zich in de schakelmodus bevond tijdens de query. Het gegevenstype is Booleaanse waarde (Waar, Onwaar).
• workspaceRegion: De regio van de werkruimte waarop de query is gericht. Het gegevenstype is String.

Prestaties van werkruimten bewaken met behulp van query's

U wordt aangeraden de query's in deze sectie te gebruiken om waarschuwingsregels te maken die u op de hoogte stellen van mogelijke problemen met de status of prestaties van de werkruimte. De beslissing om over te schakelen vereist echter uw zorgvuldige overweging en mag niet automatisch worden uitgevoerd.

In de queryregel kunt u een voorwaarde definiëren om over te schakelen naar uw secundaire werkruimte na een opgegeven aantal schendingen. Zie Een waarschuwingsregel voor zoeken in logboeken maken of bewerken voor meer informatie.

Twee belangrijke metingen van de prestaties van de werkruimte omvatten opnamelatentie en opnamevolume. In de volgende secties worden deze bewakingsopties besproken.

Bewaak de end-to-end opnamelatentie

De opnamelatentie meet de tijd die nodig is om logs in te voeren in de werkruimte. De tijdmeting begint wanneer de eerste vastgelegde gebeurtenis plaatsvindt en eindigt wanneer het logboek wordt opgeslagen in uw werkruimte. De totale opnamelatentie bestaat uit twee delen:

• Agentlatentie: de tijd die de agent nodig heeft om een gebeurtenis te rapporteren.
• Latentie van opnamepijplijn (back-end): de tijd die nodig is voor de opnamepijplijn om de logboeken te verwerken en naar uw werkruimte te schrijven.

Verschillende gegevenstypen hebben een andere opnamelatentie. U kunt de opname voor elk gegevenstype afzonderlijk meten of een algemene query maken voor alle typen en een nauwkeurigere query voor specifieke typen die voor u van een hoger belang zijn. We raden u aan het 90e percentiel van de opnamelatentie te meten, wat gevoeliger is om te veranderen dan het gemiddelde of het 50e percentiel (mediaan).

In de volgende secties ziet u hoe u query's gebruikt om de opnamelatentie voor uw werkruimte te controleren.

Latentie van opname volgens basislijn van specifieke tabellen evalueren

Begin met het bepalen van de basislijnlatentie van specifieke tabellen gedurende meerdere dagen.

Met deze voorbeeldquery wordt een grafiek gemaakt van het 90e percentiel van opnamelatentie in de tabel 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

Nadat u de query hebt uitgevoerd, bekijkt u de resultaten en de weergegeven grafiek om de verwachte latentie voor die tabel te bepalen.

De huidige opnamelatentie bewaken en waarschuwen

Nadat u de latentie van de basislijnopname voor een specifieke tabel hebt vastgesteld, maakt u een waarschuwingsregel voor zoeken in logboeken voor de tabel op basis van wijzigingen in latentie gedurende een korte periode.

Met deze query wordt de opnamelatentie in de afgelopen 20 minuten berekend:

// 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)

Omdat u enkele schommelingen kunt verwachten, maakt u een waarschuwingsregelvoorwaarde om te controleren of de query een waarde retourneert die aanzienlijk groter is dan de basislijn.

De bron van opnamelatentie bepalen

Wanneer u merkt dat de totale opnamelatentie toeneemt, kunt u query's gebruiken om te bepalen of de bron van de latentie de agents of de opnamelijn is.

Met deze query wordt de 90e percentiellatentie van de agents en van de pijplijn afzonderlijk weergegeven:

// 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

Notitie

Hoewel in de grafiek de 90e percentielgegevens als gestapelde kolommen worden weergegeven, is de som van de gegevens in de twee grafieken niet gelijk aan het totale opnamepercentage van het 90e percentiel.

Het volume van opnames bewaken

Metingen van innamevolumes kunnen helpen bij het opsporen van onverwachte wijzigingen in het totale of tabelspecifieke innamevolume voor uw werkruimte. De metingen van het queryvolume kunnen u helpen bij het identificeren van prestatieproblemen met logboekopname. Enkele nuttige volumemetingen zijn:

• Totaal opnamevolume per tabel
• Constant opnamevolume (stilstand)
• Opnameafwijkingen - schommelingen in opnamevolume

In de volgende secties ziet u hoe u query's gebruikt om het opnamevolume voor uw werkruimte te controleren.

Totaal opnamevolume per tabel controleren

U kunt een query definiëren om het opnamevolume per tabel in uw werkruimte te bewaken. De query kan een waarschuwing bevatten die controleert op onverwachte wijzigingen in het totaal of tabelspecifieke volumes.

Deze query berekent het totale opnamevolume in het afgelopen uur per tabel in megabytes per seconde (MB's):

// 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

Controleren op innamestilstand

Als u logboeken via agents verzamelt, kunt u de heartbeat van de agent gebruiken om connectiviteit te detecteren. Een stilstaande hartslag kan een onderbreking in de verzameling van loggegevens in uw werkruimte onthullen. Wanneer de querygegevens een opname-stilstand onthullen, kunt u een voorwaarde definiëren om een gewenst antwoord te activeren.

Met de volgende query wordt de heartbeat van de agent gecontroleerd om verbindingsproblemen op te sporen:

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

Innameafwijkingen bewaken

U kunt pieken en dips in de gegevens van uw werkruimteopnamevolume op verschillende manieren identificeren. Gebruik de functie series_decompose_anomalies() om afwijkingen te extraheren uit het opnamevolume dat je bewaakt in je werkruimte, of maak je eigen anomaliedetector ter ondersteuning van je unieke werkruimtescenario's.

Afwijkingen identificeren met behulp van series_decompose_anomalies

De series_decompose_anomalies() functie identificeert afwijkingen in een reeks gegevenswaarden. Met deze query wordt het uurlijkse opnamevolume van elke tabel in uw Log Analytics-werkruimte berekend en gebruikt series_decompose_anomalies() om afwijkingen te identificeren:

// 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

Zie Anomalieën detecteren en analyseren met behulp van KQL Machine Learning-mogelijkheden in Azure Monitor voor meer informatie over series_decompose_anomalies() het detecteren van afwijkingen in logboekgegevens.

Uw eigen anomaliedetector maken

U kunt een aangepaste anomaliedetector maken ter ondersteuning van de scenariovereisten voor uw werkruimteconfiguratie. Deze sectie bevat een voorbeeld om het proces te demonstreren.

De volgende query berekent:

• Verwachte opnamevolume: per uur per tabel (op basis van de mediaan van medianen, maar u kunt de logica aanpassen)
• Werkelijk opnamevolume: per uur, per tabel

Als u onbelangrijke verschillen tussen het verwachte en het werkelijke opnamevolume wilt filteren, past de query twee filters toe:

• Wijzigingspercentage: meer dan 150% of minder dan 66% van het verwachte volume, per tabel
• Volume van wijziging: Geeft aan of het toegenomen of verlaagde volume groter is dan 0,1% van het maandelijkse volume van die tabel

// 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

Controleren of de query is geslaagd en mislukt

Elke query retourneert een antwoordcode die aangeeft dat deze is geslaagd of mislukt. Wanneer de query mislukt, bevat het antwoord ook de fouttypen. Een hoge piek van fouten kan duiden op een probleem met de beschikbaarheid of serviceprestaties van de werkruimte.

Met deze query wordt geteld hoeveel query's een serverfoutcode hebben geretourneerd:

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

Gerelateerde inhoud

• Status van Log Analytics-werkruimte bewaken
• Operationele problemen bewaken in uw Azure Monitor Log Analytics-werkruimte