Delen via


Azure Cosmos DB-besturingsvlakbewerkingen controleren

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:

  1. Meld u aan bij Azure Portal en navigeer naar uw Azure Cosmos DB-account.

  2. Open het deelvenster Diagnostische instellingen en geef een naam op voor de logboeken die u wilt maken.

  3. Selecteer ControlPlaneRequests voor logboektype en selecteer de optie Verzenden naar Log Analytics .

  4. 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:

  1. Meld u aan bij het Azure-portaal.

  2. 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:

    Logboeken van besturingsvlak wanneer een VNet wordt toegevoegd

    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:

    Logboeken van besturingsvlak wanneer doorvoer wordt bijgewerkt

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

Volgende stappen