Verbeter de tolerantie door uw Log Analytics-werkruimte te repliceren tussen regio's (preview)

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 termoverschakeling om te benadrukken dat de switch naar de gerepliceerde werkruimte een actie is die u handmatig activeert.

Vereiste machtigingen

Actie	Vereiste machtigingen
Werkruimtereplicatie inschakelen	Microsoft.OperationalInsights/workspaces/write en Microsoft.Insights/dataCollectionEndpoints/write machtigingen, zoals geleverd door de ingebouwde rol Inzender voor bewaking, bijvoorbeeld
Overschakelen en terugschakelen (failover en failback activeren)	Microsoft.OperationalInsights/locations/workspaces/failover, Microsoft.OperationalInsights/workspaces/failbacken Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action machtigingen, zoals geleverd door de ingebouwde rol Inzender voor bewaking, bijvoorbeeld
Werkruimtestatus controleren	Microsoft.OperationalInsights/workspaces/read machtigingen voor de Log Analytics-werkruimte, zoals geleverd door de ingebouwde rol Inzender voor bewaking, bijvoorbeeld

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 exemplaar van uw werkruimte in de secundaire 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. Logboeken die u opneemt naar 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.

Belangrijk

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. Gedurende de eerste vier dagen reattempten azure Monitor automatisch opnieuw om de gegevens periodiek te repliceren.

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	Regio's	Opmerkingen
Noord-Amerika	VS - oost	Replicatie wordt niet ondersteund naar of vanuit de regio VS - oost 2.
	VS - oost 2	Replicatie wordt niet ondersteund naar of vanuit de regio VS - oost.
	VS - west
	VS - west 2
	Central US
	VS - zuid-centraal
	Canada - centraal
Europa	Europa -west
	Europa - noord
	Vk - zuid
	VK - west
	Duitsland - west-centraal
	Frankrijk - centraal

Vereisten voor gegevenslocatie

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 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 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 Beperkingen en beperkingen voor de volledige lijst.

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.

Belangrijk

Replicatie van Log Analytics-werkruimten die zijn gekoppeld aan een toegewezen cluster, wordt momenteel niet ondersteund.

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=2023-01-01-preview

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

Hierin:

• <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 de inrichtingsstatus Van aanvraag controleren.

De inrichtingsstatus van de aanvraag controleren

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

GET

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

Hierin:

• <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 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.

Regels voor gegevensverzameling koppelen aan het eindpunt van de systeemgegevensverzameling

U gebruikt regels voor gegevensverzameling (DCR) om logboekgegevens te verzamelen met behulp van de Azure Monitor-agent en de API voor logboekopname.

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 systeemgegevens is identiek aan uw werkruimte-id. Alleen regels voor gegevensverzameling die u aan het eindpunt voor systeemgegevensverzameling van de werkruimte koppelt, maken replicatie en overschakeling mogelijk. Met dit gedrag kunt u de set logboekstreams opgeven die moeten worden gerepliceerd, zodat u de replicatiekosten kunt beheren.

Als u gegevens wilt repliceren die u verzamelt met behulp van regels voor gegevensverzameling, koppelt u de regels voor gegevensverzameling aan het eindpunt van de systeemgegevensverzameling voor uw Log Analytics-werkruimte:

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. Selecteer DCE configureren op de pagina Overzicht van gegevensverzamelingsregel en selecteer het eindpunt voor systeemgegevensverzameling in de beschikbare lijst:

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

Belangrijk

Regels voor gegevensverzameling die zijn verbonden met het eindpunt voor systeemgegevensverzameling van een werkruimte, 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.

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=2023-01-01-preview

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

Hierin:

• <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 de inrichtingsstatus Van aanvraag controleren.

Werkruimte- en servicestatus bewaken

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 resourcestatus van de werkruimte
• 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 van opnamevolumes per tabel en resource bewaken
  • Het slagingspercentage van query's per tabel, gebruiker of resource bewaken
  • Waarschuwingen maken op basis van uw query's

Notitie

U kunt ook logboekquery's gebruiken om uw secundaire werkruimte te bewaken, maar houd er rekening mee dat logboekreplicatie wordt uitgevoerd in batchbewerkingen. De gemeten latentie kan fluctueren en geeft geen statusprobleem aan met uw secundaire 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 Beperkingen en beperkingen 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.
• U ondervindt een probleem met betrekking tot werkruimtebeheer, zoals het wijzigen van de retentie van werkruimten. Werkruimtebeheerbewerkingen worden altijd verwerkt in uw primaire regio. Tijdens de overschakeling worden bewerkingen voor werkruimtebeheer geblokkeerd.

Duur van 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:

• Opname: problemen met de opnamepijplijn in uw primaire regio kunnen van invloed zijn op de replicatie van gegevens naar uw secundaire werkruimte. Tijdens de overschakeling worden logboeken in plaats daarvan verzonden naar de opnamepijplijn in de secundaire regio.

• Query: Als query's in uw primaire werkruimte mislukken of time-outs, kunnen waarschuwingen voor zoeken in logboeken worden beïnvloed. 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.

Triggeroverschakeling

Controleer voordat u overschakelt of de replicatiebewerking van de werkruimte 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=2023-01-01-preview

Hierin:

• <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 de inrichtingsstatus Van aanvraag controleren.

Terugschakelen naar uw primaire werkruimte

Het switchback-proces annuleert het opnieuw omleiden van query's en logboekopnameaanvragen naar de secundaire werkruimte. Wanneer u terugschakelt, gaat Azure Monitor terug naar routeringsquery's en logboekopnameaanvragen 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 teruggaan?

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

Replicatiestatus van logboek

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.

Status van primaire werkruimte

Er zijn twee belangrijke statusitems die moeten worden ingecheckt om over te schakelen 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.

Triggerswitchback

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=2023-01-01-preview

Hierin:

• <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 die moet worden overgeschakeld tijdens de switchback.

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 de inrichtingsstatus Van aanvraag 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 failover activeert, wordt deze schakelopties geactiveerd. 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 eenvoudige 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 Tekenreeks.

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.

End-to-end opnamelatentie bewaken

De opnamelatentie meet de tijd die nodig is om logboeken op te nemen naar 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 opnamepijplijn 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.

Opnamevolume bewaken

Metingen van opnamevolumes kunnen helpen bij het identificeren van onverwachte wijzigingen in het totale of tabelspecifieke opnamevolume 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 (standstill)
• Opnameafwijkingen - pieken en dips 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 bewaken

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 opnamestandstill

Als u logboeken via agents opneemt, kunt u de heartbeat van de agent gebruiken om connectiviteit te detecteren. Een still heartbeat kan de opname van logboeken in uw werkruimte stoppen. 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

Opnameafwijkingen 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 de opnamevolumes die u in uw werkruimte bewaakt, of maak uw eigen anomaliedetector ter ondersteuning van uw 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.

Met de volgende query wordt berekend:

• 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

Beperkingen en limieten

• Replicatie van Log Analytics-werkruimten die zijn gekoppeld aan een toegewezen cluster, wordt momenteel niet ondersteund.

• 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 opschoonbewerking.

• Replicatie van waarschuwingsregels tussen regio's wordt momenteel niet ondersteund. Omdat Azure Monitor ondersteuning biedt voor het uitvoeren van query's op de inactieve regio, blijven waarschuwingen op basis van query's werken wanneer u schakelt tussen regio's, tenzij de Waarschuwingen-service in de actieve regio niet goed werkt of de waarschuwingsregels niet beschikbaar zijn.

• 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.

• Tijdens de overstap worden bewerkingen voor werkruimtebeheer niet ondersteund, waaronder:

  • Werkruimteretentie, prijscategorie, dagelijkse limiet wijzigen, enzovoort
  • Netwerkinstellingen wijzigen
  • Schema wijzigen via nieuwe aangepaste logboeken of het verbinden van platformlogboeken van nieuwe resourceproviders, zoals het verzenden van diagnostische logboeken vanaf een nieuw resourcetype

• De oplossing die is gericht op de verouderde Log Analytics-agent, wordt niet ondersteund tijdens de overschakeling. Daarom worden tijdens de overschakeling oplossingsgegevens van alle agents opgenomen.

• 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 de bijgewerkte DNS op te halen. Tijdens de overstap proberen deze clients mogelijk enige tijd logboeken op te nemen via de primaire regio. Mogelijk neemt u logboeken op in uw primaire werkruimte met behulp van verschillende clients, waaronder de verouderde Log Analytics-agent, Azure Monitor-agent, code (met behulp van de logboekopname-API of de verouderde HTTP-gegevensverzamelings-API) en andere services, zoals Sentinel.

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

  Functie	Ondersteuning
  Hulptabelplannen	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.
  Zoektaken, 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 voltooien, maar niet repliceren, of mislukken, afhankelijk van de status van uw werkruimte en de exacte timing.
  Application Insights via Log Analytics-werkruimten	Niet ondersteund
  VM Insights	Niet ondersteund
  Container Insights	Niet ondersteund
  Privékoppelingen	Niet ondersteund tijdens failover

Gerelateerde inhoud

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