Azure Cosmos DB-besturingsvlakbewerkingen controleren

Artikel
08/15/2024

VAN TOEPASSING OP: NoSQL MongoDB Cassandra Gremlin Tafel

Control Plane in Azure Cosmos DB is een RESTful-service waarmee u diverse bewerkingen kunt uitvoeren op het Azure Cosmos DB-account. Er wordt een openbaar resourcemodel (bijvoorbeeld database, account) en verschillende bewerkingen beschikbaar gesteld aan de eindgebruikers om acties uit te voeren op het resourcemodel. De besturingsvlakbewerkingen omvatten wijzigingen in het Azure Cosmos DB-account of de container. Bewerkingen zoals een Azure Cosmos DB-account maken, een regio toevoegen, doorvoer bijwerken, failover van regio's, een VNet toevoegen, enzovoort, zijn enkele besturingsvlakbewerkingen. In dit artikel wordt uitgelegd hoe u de besturingsvlakbewerkingen controleert in Azure Cosmos DB. U kunt de besturingsvlakbewerkingen uitvoeren op Azure Cosmos DB-accounts met behulp van Azure CLI, PowerShell of Azure Portal, terwijl u voor containers Azure CLI of PowerShell gebruikt.

Hier volgen enkele voorbeeldscenario's waarin het controleren van besturingsvlakbewerkingen nuttig is:

U wilt een waarschuwing ontvangen wanneer de firewallregels voor uw Azure Cosmos DB-account worden gewijzigd. De waarschuwing is vereist om niet-geautoriseerde wijzigingen in regels te vinden die de netwerkbeveiliging van uw Azure Cosmos DB-account bepalen en snelle actie ondernemen.
U wilt een waarschuwing ontvangen als er een nieuwe regio wordt toegevoegd of verwijderd uit uw Azure Cosmos DB-account. Het toevoegen of verwijderen van regio's heeft gevolgen voor facturerings- en gegevenssoevereinevereisten. Deze waarschuwing helpt u bij het detecteren van een onbedoelde toevoeging of verwijdering van regio's in uw account.
U wilt meer informatie krijgen uit de diagnostische logboeken over wat er is gewijzigd. Een VNet is bijvoorbeeld gewijzigd.

Schrijftoegang voor sleutelgebaseerde metagegevens uitschakelen

Voordat u de besturingsvlakbewerkingen in Azure Cosmos DB controleert, schakelt u de schrijftoegang voor op sleutels gebaseerde metagegevens uit voor uw account. Wanneer schrijftoegang voor sleutelgebaseerde metagegevens is uitgeschakeld, kunnen clients die verbinding maken met het Azure Cosmos DB-account via accountsleutels geen toegang krijgen tot het account. U kunt schrijftoegang uitschakelen door de disableKeyBasedMetadataWriteAccess eigenschap in te stellen op true. Nadat u deze eigenschap hebt ingesteld, kunnen wijzigingen in elke resource van een gebruiker met de juiste Azure-rol en -referenties plaatsvinden.

Als de SDK-clients bewerkingen voor maken of bijwerken uitvoeren nadat de disableKeyBasedMetadataWriteAccess SDK is ingeschakeld, wordt een fout 'Bewerking 'POST' voor de resource 'ContainerNameorDatabaseName' niet toegestaan via het Azure Cosmos DB-eindpunt . U moet toegang tot dergelijke bewerkingen voor uw account inschakelen of de bewerkingen voor maken/bijwerken uitvoeren via Azure Resource Manager, Azure CLI of Azure PowerShell. Als u wilt terugschakelen, stelt u disableKeyBasedMetadataWriteAccess in op false met behulp van Azure CLI. Zorg ervoor dat u de waarde van disableKeyBasedMetadataWriteAccess onwaar wijzigt in plaats van waar.

Houd rekening met de volgende punten bij het uitschakelen van de schrijftoegang voor metagegevens:

Evalueer en zorg ervoor dat uw toepassingen geen metagegevens aanroepen uitvoeren die de bovenstaande resources wijzigen (bijvoorbeeld verzameling maken, doorvoer bijwerken, ...) met behulp van de SDK of accountsleutels.
Wanneer disableKeyBasedMetadataWriteAccess deze is ingesteld op true, worden de metagegevensbewerkingen die door de SDK worden uitgegeven, geblokkeerd. U kunt ook Azure Portal, Azure CLI, Azure PowerShell of Azure Resource Manager-sjabloonimplementaties gebruiken om deze bewerkingen uit te voeren.

Diagnostische logboeken inschakelen voor besturingsvlakbewerkingen

U kunt diagnostische logboeken inschakelen voor besturingsvlakbewerkingen met behulp van Azure Portal. Nadat de diagnostische logboeken zijn ingeschakeld, wordt de bewerking vastgelegd als een paar begin- en volledige gebeurtenissen met relevante details. De regioFailoverStart en RegionFailoverComplete voltooien bijvoorbeeld de failover-gebeurtenis van de regio.

Gebruik de volgende stappen om logboekregistratie in te schakelen voor besturingsvlakbewerkingen:

Meld u aan bij Azure Portal en navigeer naar uw Azure Cosmos DB-account.
Open het deelvenster Diagnostische instellingen en geef een naam op voor de logboeken die u wilt maken.
Selecteer ControlPlaneRequests voor logboektype en selecteer de optie Verzenden naar Log Analytics .
Verzend desgewenst de diagnostische logboeken naar Azure Storage, Azure Event Hubs, Azure Monitor of een derde partij.

U kunt de logboeken ook opslaan in een opslagaccount of streamen naar een Event Hub. In dit artikel wordt beschreven hoe u logboeken naar Log Analytics verzendt en deze vervolgens opvraagt. Nadat u deze optie hebt ingeschakeld, duurt het enkele minuten voordat de diagnostische logboeken van kracht worden. Alle besturingsvlakbewerkingen die na dat punt worden uitgevoerd, kunnen worden bijgehouden. In de volgende schermopname ziet u hoe u logboeken van het besturingsvlak inschakelt:

Logboekregistratie van aanvragen voor besturingsvlak inschakelen

De besturingsvlakbewerkingen weergeven

Nadat u logboekregistratie hebt ingeschakeld, gebruikt u de volgende stappen om bewerkingen voor een specifiek account op te sporen:

Meld u aan bij het Azure-portaal.
Open het tabblad Monitor in de linkernavigatiebalk en selecteer vervolgens het deelvenster Logboeken . Er wordt een gebruikersinterface geopend waarin u eenvoudig query's kunt uitvoeren met dat specifieke account binnen het bereik. Voer de volgende query uit om logboeken van het besturingsvlak weer te geven:
```
AzureDiagnostics
| where ResourceProvider=="MICROSOFT.DOCUMENTDB" and Category=="ControlPlaneRequests"
| where TimeGenerated >= ago(1h)
```
In de volgende schermopnamen worden logboeken vastgelegd wanneer een consistentieniveau wordt gewijzigd voor een Azure Cosmos DB-account. De activityId_g waarde van resultaten verschilt van de activiteits-id van een bewerking:

In de volgende schermopnamen worden logboeken vastgelegd wanneer de keyspace of een tabel van een Cassandra-account wordt gemaakt en wanneer de doorvoer wordt bijgewerkt. De logboeken van het besturingsvlak voor het maken en bijwerken van bewerkingen in de database en de container worden afzonderlijk geregistreerd, zoals wordt weergegeven in de volgende schermopname:

De identiteit identificeren die is gekoppeld aan een specifieke bewerking

Als u verder fouten wilt opsporen, kunt u een specifieke bewerking in het activiteitenlogboek identificeren met behulp van de activityId_g of door de tijdstempel van de bewerking. Tijdstempel wordt gebruikt voor sommige Resource Manager-clients waarbij de activiteits-id niet expliciet wordt doorgegeven. Het activiteitenlogboek bevat details over de identiteit waarmee de bewerking is gestart. In de volgende schermopname ziet u hoe u de activityId_g bewerkingen kunt vinden die eraan zijn gekoppeld in het activiteitenlogboek:

Gebruik de activiteits-id en zoek de bewerkingen

Besturingsvlakbewerkingen voor Azure Cosmos DB-account

Hier volgen de besturingsvlakbewerkingen die beschikbaar zijn op accountniveau. De meeste bewerkingen worden bijgehouden op accountniveau. Deze bewerkingen zijn beschikbaar als metrische gegevens in Azure Monitor:

Regio toegevoegd
Regio verwijderd
Account verwijderd
Failover van regio
Account gemaakt
Virtueel netwerk verwijderd
Accountnetwerkinstellingen bijgewerkt
Accountreplicatie-instellingen bijgewerkt
Accountsleutels bijgewerkt
Back-upinstellingen van account bijgewerkt
Diagnostische instellingen van account bijgewerkt

Besturingsvlakbewerkingen voor database of containers

Hier volgen de besturingsvlakbewerkingen die beschikbaar zijn op database- en containerniveau. Deze bewerkingen zijn beschikbaar als metrische gegevens in Azure Monitor:

SQL Database gemaakt
SQL Database bijgewerkt
Sql Database-doorvoer bijgewerkt
SQL Database verwijderd
SQL-container gemaakt
SQL-container bijgewerkt
Sql-containerdoorvoer bijgewerkt
SQL-container verwijderd
Cassandra Keyspace gemaakt
Cassandra Keyspace bijgewerkt
Cassandra Keyspace-doorvoer bijgewerkt
Cassandra Keyspace verwijderd
Cassandra-tabel gemaakt
Cassandra-tabel bijgewerkt
Cassandra-tabeldoorvoer bijgewerkt
Cassandra-tabel verwijderd
Gremlin-database gemaakt
Gremlin-database bijgewerkt
Gremlin-databasedoorvoer bijgewerkt
Gremlin-database verwijderd
Gremlin Graph gemaakt
Gremlin Graph bijgewerkt
Gremlin Graph-doorvoer bijgewerkt
Gremlin Graph verwijderd
Mongo-database gemaakt
Mongo-database bijgewerkt
Doorvoer van Mongo-database bijgewerkt
Mongo-database verwijderd
Mongo-verzameling gemaakt
Mongo-verzameling bijgewerkt
Doorvoer van Mongo-verzameling bijgewerkt
Mongo-verzameling verwijderd
AzureTable-tabel gemaakt
AzureTable-tabel bijgewerkt
AzureTable Table-doorvoer bijgewerkt
AzureTable-tabel verwijderd

Diagnostische logboekbewerkingen

Hier volgen de bewerkingsnamen in diagnostische logboeken voor verschillende bewerkingen:

RegionAddStart, RegionAddComplete
RegionRemoveStart, RegionRemoveComplete
AccountDeleteStart, AccountDeleteComplete
RegionFailoverStart, RegionFailoverComplete
AccountCreateStart, AccountCreateComplete
AccountUpdateStart, AccountUpdateComplete
VirtualNetworkDeleteStart, VirtualNetworkDeleteComplete
DiagnosticLogUpdateStart, DiagnosticLogUpdateComplete

Voor API-specifieke bewerkingen heeft de bewerking de volgende indeling:

ApiKind + ApiKindResourceType + OperationType
ApiKind + ApiKindResourceType + "Doorvoer" + operationType

Voorbeeld

CassandraKeyspacesCreate
CassandraKeyspacesUpdate
CassandraKeyspacesThroughputUpdate
SqlContainersUpdate

De eigenschap ResourceDetails bevat de hele hoofdtekst van de resource als nettolading van de aanvraag en bevat alle eigenschappen die zijn aangevraagd om bij te werken

Diagnostische logboekquery's voor besturingsvlakbewerkingen

Hier volgen enkele voorbeelden voor het ophalen van diagnostische logboeken voor besturingsvlakbewerkingen:

AzureDiagnostics 
| where Category startswith "ControlPlane"
| where OperationName contains "Update"
| project httpstatusCode_s, statusCode_s, OperationName, resourceDetails_s, activityId_g

AzureDiagnostics 
| where Category =="ControlPlaneRequests"
| where TimeGenerated >= todatetime('2020-05-14T17:37:09.563Z')
| project TimeGenerated, OperationName, apiKind_s, apiKindResourceType_s, operationType_s, resourceDetails_s

AzureDiagnostics
| where Category == "ControlPlaneRequests"
| where OperationName startswith "SqlContainersUpdate"

AzureDiagnostics
| where Category == "ControlPlaneRequests"
| where OperationName startswith "SqlContainersThroughputUpdate"

Voer een query uit om de activityId en de aanroeper op te halen die de bewerking container verwijderen heeft gestart:

(AzureDiagnostics
| where Category == "ControlPlaneRequests"
| where OperationName == "SqlContainersDelete"
| where TimeGenerated >= todatetime('9/3/2020, 5:30:29.300 PM')
| summarize by activityId_g )
| join (
AzureActivity
| parse HTTPRequest with * "clientRequestId\": \"" activityId_g "\"" * 
| summarize by Caller, HTTPRequest, activityId_g)
on activityId_g
| project Caller, activityId_g

Voer een query uit om index- of ttl-updates op te halen. Vervolgens kunt u de uitvoer van deze query vergelijken met een eerdere update om de wijziging in de index of ttl te zien.

AzureDiagnostics
| where Category =="ControlPlaneRequests"
| where  OperationName == "SqlContainersUpdate"
| project resourceDetails_s

output:

{id:skewed,indexingPolicy:{automatic:true,indexingMode:consistent,includedPaths:[{path:/*,indexes:[]}],excludedPaths:[{path:/_etag/?}],compositeIndexes:[],spatialIndexes:[]},partitionKey:{paths:[/pk],kind:Hash},defaultTtl:1000000,uniqueKeyPolicy:{uniqueKeys:[]},conflictResolutionPolicy:{mode:LastWriterWins,conflictResolutionPath:/_ts,conflictResolutionProcedure:}

Delen via