Monitoraggio di Azure cluster dedicati dei log


Quando un'area di lavoro Log Analytics è collegata a un cluster dedicato, i nuovi dati inseriti nell'area di lavoro vengono instradati al nuovo cluster mentre i dati esistenti rimangono nel cluster esistente. Se il cluster dedicato viene crittografato usando chiavi gestite dal cliente(CMK), solo i nuovi dati vengono crittografati con la chiave. Il sistema astrae questa differenza, quindi è possibile eseguire query sull'area di lavoro come di consueto mentre il sistema esegue query tra cluster in background.

Un cluster può essere collegato a un massimo di 1.000 aree di lavoro. Le aree di lavoro collegate si trovano nella stessa area del cluster. Per proteggere il back-end di sistema ed evitare la frammentazione dei dati, un'area di lavoro non può essere collegata a un cluster più di due volte al mese.

Per eseguire l'operazione di collegamento, è necessario disporre delle autorizzazioni di "scrittura" sia per l'area di lavoro che per la risorsa cluster:

  • Nell'area di lavoro: Microsoft.OperationalInsights/workspaces/write
  • Nella risorsa cluster: Microsoft.OperationalInsights/clusters/write

Oltre agli aspetti di fatturazione, l'area di lavoro collegata mantiene le proprie impostazioni, ad esempio la durata della conservazione dei dati.

L'area di lavoro e il cluster possono essere in sottoscrizioni diverse. È possibile che l'area di lavoro e il cluster siano in tenant diversi se Azure Lighthouse viene usato per eseguire il mapping di entrambi a un singolo tenant.

Il collegamento di un'area di lavoro può essere eseguito solo dopo il completamento del provisioning del cluster di Log Analytics.

Avviso

Il collegamento di un'area di lavoro a un cluster richiede la sincronizzazione di più componenti back-end e la protezione dell'idratazione della cache. Poiché il completamento di questa operazione può richiedere fino a due ore, è consigliabile eseguirla in modo asincrono.

Usare i comandi seguenti per collegare un'area di lavoro a un cluster:

CLI

# Find cluster resource ID
az account set --subscription "cluster-subscription-id"
$clusterResourceId = az monitor log-analytics cluster list --resource-group "resource-group-name" --query "[?contains(name, "cluster-name")].[id]" --output tsv

# Link workspace
az account set --subscription "workspace-subscription-id"
az monitor log-analytics workspace linked-service create --no-wait --name cluster --resource-group "resource-group-name" --workspace-name "workspace-name" --write-access-resource-id $clusterResourceId

# Wait for job completion when `--no-wait` was used
$workspaceResourceId = az monitor log-analytics workspace list --resource-group "resource-group-name" --query "[?contains(name, "workspace-name")].[id]" --output tsv
az resource wait --deleted --ids $workspaceResourceId --include-response-body true

PowerShell

Select-AzSubscription "cluster-subscription-id"

# Find cluster resource ID
$clusterResourceId = (Get-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name").id

Select-AzSubscription "workspace-subscription-id"

# Link the workspace to the cluster
Set-AzOperationalInsightsLinkedService -ResourceGroupName "resource-group-name" -WorkspaceName "workspace-name" -LinkedServiceName cluster -WriteAccessResourceId $clusterResourceId -AsJob

# Check when the job is done
Get-Job -Command "Set-AzOperationalInsightsLinkedService" | Format-List -Property *

REST API

Usare la chiamata REST seguente per il collegamento a un cluster:

Invia

PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/microsoft.operationalinsights/workspaces/<workspace-name>/linkedservices/cluster?api-version=2021-06-01 
Authorization: Bearer <token>
Content-type: application/json

{
  "properties": {
    "WriteAccessResourceId": "/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/microsoft.operationalinsights/clusters/<cluster-name>"
    }
}

Response.

202 (Accettato) e intestazione.


Quando un cluster è configurato con chiavi gestite dal cliente, i dati inseriti nelle aree di lavoro dopo il completamento dell'operazione di collegamento vengono archiviati crittografati con la chiave gestita. Il completamento dell'operazione di collegamento all'area di lavoro può richiedere fino a 90 minuti ed è possibile controllare lo stato inviando la richiesta Get all'area di lavoro e osservare se la proprietà clusterResourceId è presente nella risposta nelle funzionalità .

CLI

az account set --subscription "workspace-subscription-id"

az monitor log-analytics workspace show --resource-group "resource-group-name" --workspace-name "workspace-name"

PowerShell

Select-AzSubscription "workspace-subscription-id"

Get-AzOperationalInsightsWorkspace -ResourceGroupName "resource-group-name" -Name "workspace-name"

REST API

Chiamare

GET https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/microsoft.operationalinsights/workspaces/<workspace-name>?api-version=2021-06-01
Authorization: Bearer <token>

Response.

{
  "properties": {
    "source": "Azure",
    "customerId": "workspace-name",
    "provisioningState": "Succeeded",
    "sku": {
      "name": "pricing-tier-name",
      "lastSkuUpdate": "Tue, 28 Jan 2020 12:26:30 GMT"
    },
    "retentionInDays": 31,
    "features": {
      "legacy": 0,
      "searchVersion": 1,
      "enableLogAccessUsingOnlyResourcePermissions": true,
      "clusterResourceId": "/subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.OperationalInsights/clusters/cluster-name"
    },
    "workspaceCapping": {
      "dailyQuotaGb": -1.0,
      "quotaNextResetTime": "Tue, 28 Jan 2020 14:00:00 GMT",
      "dataIngestionStatus": "RespectQuota"
    }
  },
  "id": "/subscriptions/subscription-id/resourcegroups/resource-group-name/providers/microsoft.operationalinsights/workspaces/workspace-name",
  "name": "workspace-name",
  "type": "Microsoft.OperationalInsights/workspaces",
  "location": "region"
}

Modificare le proprietà del cluster

Dopo aver creato la risorsa cluster ed eseguito il provisioning completo, è possibile modificare proprietà aggiuntive usando l'interfaccia della riga di comando, PowerShell o l'API REST. Di seguito sono riportate le proprietà aggiuntive che è possibile impostare dopo il provisioning del cluster:

  • keyVaultProperties: contiene la chiave Azure Key Vault con i parametri seguenti: KeyVaultUri, KeyName, KeyVersion. Vedere Aggiornare il cluster con i dettagli dell'identificatore di chiave.
  • Identità: identità usata per eseguire l'autenticazione al Key Vault. Può essere assegnata dal sistema o assegnata dall'utente.
  • billingType: attribuzione della fatturazione per la risorsa cluster e i relativi dati. Include i valori seguenti:
    • Cluster (impostazione predefinita): i costi per il cluster vengono attribuiti alla risorsa cluster.
    • Aree di lavoro: i costi per il cluster vengono attribuiti proporzionalmente alle aree di lavoro nel cluster, con la risorsa cluster che viene fatturata parte dell'utilizzo se il totale dei dati inseriti per il giorno è inferiore al livello di impegno. Per altre informazioni sul modello di determinazione prezzi dei cluster, vedere Cluster dedicati di Log Analytics.

Importante

L'aggiornamento del cluster non deve includere i dettagli dell'identità e dell'identificatore di chiave nella stessa operazione. Se è necessario aggiornare entrambi, l'aggiornamento deve essere in due operazioni consecutive.

Nota

La proprietà billingType non è supportata in PowerShell.

Ottenere tutti i cluster nel gruppo di risorse

CLI

az account set --subscription "cluster-subscription-id"

az monitor log-analytics cluster list --resource-group "resource-group-name"

PowerShell

Select-AzSubscription "cluster-subscription-id"

Get-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name"

REST API

Chiamare

GET https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/clusters?api-version=2021-06-01
Authorization: Bearer <token>

Response.

{
  "value": [
    {
      "identity": {
        "type": "SystemAssigned",
        "tenantId": "tenant-id",
        "principalId": "principal-id"
      },
      "sku": {
        "name": "capacityreservation",
        "capacity": 500
      },
      "properties": {
        "provisioningState": "Succeeded",
        "clusterId": "cluster-id",
        "billingType": "Cluster",
        "lastModifiedDate": "last-modified-date",
        "createdDate": "created-date",
        "isDoubleEncryptionEnabled": false,
        "isAvailabilityZonesEnabled": false,
        "capacityReservationProperties": {
          "lastSkuUpdate": "last-sku-modified-date",
          "minCapacity": 500
        }
      },
      "id": "/subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.OperationalInsights/clusters/cluster-name",
      "name": "cluster-name",
      "type": "Microsoft.OperationalInsights/clusters",
      "location": "cluster-region"
    }
  ]
}

Ottenere tutti i cluster nella sottoscrizione

CLI

az account set --subscription "cluster-subscription-id"

az monitor log-analytics cluster list

PowerShell

Select-AzSubscription "cluster-subscription-id"

Get-AzOperationalInsightsCluster

REST API

Chiamare

GET https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.OperationalInsights/clusters?api-version=2021-06-01
Authorization: Bearer <token>

Response.

Uguale a 'cluster in un gruppo di risorse', ma nell'ambito della sottoscrizione.


Aggiornare il livello di impegno nel cluster

Quando il volume di dati per le aree di lavoro collegate cambia nel tempo e si vuole aggiornare il livello di impegno in modo appropriato. Il livello è specificato in unità di GB e può avere valori di 500, 1000, 2000 o 5000 GB al giorno. Si noti che non è necessario fornire il corpo completo della richiesta REST, ma è necessario includere lo SKU.

CLI

az account set --subscription "cluster-subscription-id"

az monitor log-analytics cluster update --resource-group "resource-group-name" --name "cluster-name"  --sku-capacity 500

PowerShell

Select-AzSubscription "cluster-subscription-id"

Update-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name" -SkuCapacity 500

API REST

Chiamare

PATCH https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.OperationalInsights/clusters/<cluster-name>?api-version=2021-06-01
Authorization: Bearer <token>
Content-type: application/json

{
  "sku": {
    "name": "capacityReservation",
    "Capacity": 2000
  }
}

Aggiornare billingType nel cluster

La proprietà billingType determina l'attribuzione della fatturazione per il cluster e i relativi dati:

  • Cluster (impostazione predefinita): la fatturazione viene attribuita alla risorsa Cluster
  • Aree di lavoro: la fatturazione viene attribuita alle aree di lavoro collegate in modo proporzionale. Quando il volume di dati da tutte le aree di lavoro è inferiore al livello di impegno, il volume rimanente viene attribuita al cluster

REST

Chiamare

PATCH https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.OperationalInsights/clusters/<cluster-name>?api-version=2021-06-01
Authorization: Bearer <token>
Content-type: application/json

{
  "properties": {
    "billingType": "Workspaces",
    }  
}

È possibile scollegare un'area di lavoro da un cluster. Dopo aver scollegato un'area di lavoro dal cluster, i nuovi dati associati a questa area di lavoro non vengono inviati al cluster dedicato. Inoltre, la fatturazione dell'area di lavoro non viene più eseguita tramite il cluster. I dati vecchi dell'area di lavoro non collegata potrebbero essere lasciati nel cluster. Se questi dati vengono crittografati usando chiavi gestite dal cliente, i Key Vault vengono mantenuti. Il sistema estrae questa modifica dagli utenti di Log Analytics. Gli utenti possono semplicemente eseguire query sull'area di lavoro come di consueto. Il sistema esegue query tra cluster nel back-end in base alle esigenze senza alcuna indicazione per gli utenti.

Avviso

È previsto un limite di due operazioni di collegamento per un'area di lavoro specifica entro un mese. Prendere in considerazione e pianificare azioni di scollegamento di conseguenza.

Usare i comandi seguenti per scollegare un'area di lavoro dal cluster:

CLI

az account set --subscription "workspace-subscription-id"

az monitor log-analytics workspace linked-service delete --resource-group "resource-group-name" --workspace-name "workspace-name" --name cluster

PowerShell

Select-AzSubscription "workspace-subscription-id"

# Unlink a workspace from cluster
Remove-AzOperationalInsightsLinkedService -ResourceGroupName "resource-group-name" -WorkspaceName {workspace-name} -LinkedServiceName cluster

Eliminare il cluster

È consigliabile scollegare tutte le aree di lavoro da un cluster dedicato prima di eliminarlo. È necessario disporre delle autorizzazioni di scrittura per la risorsa cluster. Quando si elimina un cluster, si perde l'accesso a tutti i dati inseriti nel cluster dalle aree di lavoro collegate e dalle aree di lavoro collegate in precedenza. Questa operazione non è reversibile. Se si elimina il cluster quando le aree di lavoro sono collegate, queste vengono scollegate automaticamente e i nuovi dati vengono invece inseriti nell'archiviazione di Log Analytics.

Una risorsa cluster eliminata negli ultimi 14 giorni viene mantenuta nello stato di eliminazione soft e il nome rimane riservato. Dopo il periodo di eliminazione temporaneamente, il cluster viene eliminato definitivamente e può essere usato il nome.

Avviso

  • Il ripristino dei cluster eliminati automaticamente non è supportato e non può essere recuperato dopo l'eliminazione.
  • È previsto un limite di 4 cluster per sottoscrizione. Nell'ambito di questa operazione vengono conteggiati sia i cluster attivi che i cluster eliminati automaticamente. I clienti non devono creare procedure ricorrenti che creano ed eliminano cluster. Ha un impatto significativo sui sistemi back-end di Log Analytics.

Usare i comandi seguenti per eliminare un cluster:

CLI

az account set --subscription "cluster-subscription-id"

az monitor log-analytics cluster delete --resource-group "resource-group-name" --name $clusterName

PowerShell

Select-AzSubscription "cluster-subscription-id"

Remove-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name"

REST API

Usare la chiamata REST seguente per eliminare un cluster:

DELETE https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.OperationalInsights/clusters/<cluster-name>?api-version=2021-06-01
Authorization: Bearer <token>

Risposta

200 - OK


Limiti e i vincoli

  • È possibile creare un massimo di due cluster attivi in ogni area e sottoscrizione.

  • È possibile creare un numero massimo di quattro cluster riservati (attivi o eliminati di recente) in ogni area e sottoscrizione.

  • È possibile collegare un massimo di 1.000 aree di lavoro Log Analytics a un cluster.

  • Un massimo di due operazioni di collegamento all'area di lavoro in una determinata area di lavoro è consentita in un periodo di 30 giorni.

  • Lo spostamento di un cluster in un altro gruppo di risorse o sottoscrizione non è attualmente supportato.

  • L'aggiornamento del cluster non deve includere i dettagli dell'identità e dell'identificatore di chiave nella stessa operazione. Nel caso in cui sia necessario aggiornare entrambi, l'aggiornamento deve essere in due operazioni consecutive.

  • Lockbox non è attualmente disponibile in Cina.

  • La crittografia doppia viene configurata automaticamente per i cluster creati a partire da ottobre 2020 nelle aree supportate. È possibile verificare se il cluster è configurato per la crittografia doppia inviando una richiesta GET nel cluster e osservando che il valore è per i cluster con la crittografia isDoubleEncryptionEnabledtrue Doppia abilitata.

    • Se si crea un cluster e viene visualizzato l'errore "region-name doesn't support Double Encryption for clusters", è comunque possibile creare il cluster senza la crittografia Doppia aggiungendo nel corpo della richiesta "properties": {"isDoubleEncryptionEnabled": false} REST.
    • Non è possibile modificare l'impostazione di crittografia doppia dopo la creazione del cluster.

Risoluzione dei problemi

  • Se si verifica un errore di conflitto durante la creazione di un cluster, è possibile che il cluster sia stato eliminato negli ultimi 14 giorni e sia in uno stato di eliminazione soft. Il nome del cluster rimane riservato durante il periodo di eliminazione soft e non è possibile creare un nuovo cluster con tale nome. Il nome viene rilasciato dopo il periodo di eliminazione temporaneamente quando il cluster viene eliminato definitivamente.

  • Se si aggiorna il cluster mentre il cluster è in stato di provisioning o aggiornamento, l'aggiornamento avrà esito negativo.

  • Alcune operazioni sono lunghe e possono richiedere del tempo. Si tratta della creazione del cluster,dell'aggiornamento della chiave del cluster e dell'eliminazione del cluster. È possibile controllare lo stato dell'operazione inviando una richiesta GET al cluster o all'area di lavoro e osservare la risposta. Ad esempio, l'area di lavoro non collegata non includerà clusterResourceId nelle funzionalità.

  • Il collegamento dell'area di lavoro al cluster avrà esito negativo se è collegato a un altro cluster.

messaggi di errore

Creazione del cluster

  • 400 -- Il nome del cluster non è valido. Il nome del cluster può contenere caratteri a-z, A-Z, 0-9 e lunghezza di 3-63.
  • 400 -- Il corpo della richiesta è Null o in formato non valido.
  • 400 -- Il nome dello SKU non è valido. Impostare il nome dello SKU su capacityReservation.
  • 400 -- La capacità è stata fornita ma lo SKU non è capacityReservation. Impostare il nome dello SKU su capacityReservation.
  • 400 -- Capacità mancante nello SKU. Impostare il valore capacity su 500, 1000, 2000 o 5000 GB/giorno.
  • 400 -- La capacità è bloccata per 30 giorni. La riduzione della capacità è consentita 30 giorni dopo l'aggiornamento.
  • 400 -- Non è stato impostato alcun SKU. Impostare il nome dello SKU su capacityReservation e il valore capacity su 500, 1000, 2000 o 5000 GB/giorno.
  • 400 -- Identity è null o vuoto. Impostare Identity con il tipo systemAssigned.
  • 400 -- KeyVaultProperties viene impostato al momento della creazione. Aggiornare KeyVaultProperties dopo la creazione del cluster.
  • 400 -- L'operazione non può essere eseguita ora. L'operazione asincrona è in uno stato diverso da succeeded. Il cluster deve completare l'operazione prima di eseguire qualsiasi operazione di aggiornamento.

Aggiornamento del cluster

  • 400 -- Il cluster è in stato di eliminazione. L'operazione asincrona è in corso. Il cluster deve completare l'operazione prima di eseguire qualsiasi operazione di aggiornamento.
  • 400 -- KeyVaultProperties non è vuoto ma ha un formato non valido. Vedere Aggiornamento dell'identificatore di chiave.
  • 400 -- Non è stato possibile convalidare la chiave Key Vault. Potrebbe essere dovuto alla mancanza di autorizzazioni o a quando la chiave non esiste. Verificare di aver impostato la chiave e i criteri di accesso Key Vault.
  • 400 -- La chiave non è recuperabile. Key Vault deve essere impostato su Eliminazione soft e Protezione dall'eliminazione. Vedere Key Vault documentazione
  • 400 -- L'operazione non può essere eseguita ora. Attendere il completamento dell'operazione asincrona e riprovare.
  • 400 -- Il cluster è in stato di eliminazione. Attendere il completamento dell'operazione asincrona e riprovare.

Ottenere il cluster

  • 404 -- Cluster non trovato. È possibile che il cluster sia stato eliminato. Se si tenta di creare un cluster con tale nome e si verifica un conflitto, il cluster è in modalità di eliminazione soft per 14 giorni. È possibile contattare il supporto tecnico per ripristinarlo o usare un altro nome per creare un nuovo cluster.

Eliminazione del cluster

  • 409 - Non è possibile eliminare un cluster mentre è in stato di provisioning. Attendere il completamento dell'operazione asincrona e riprovare.
  • 404 -- Area di lavoro non trovata. L'area di lavoro specificata non esiste o è stata eliminata.
  • 409 -- Operazione di collegamento o scollegamento dell'area di lavoro in corso.
  • 400 -- Cluster non trovato, il cluster specificato non esiste o è stato eliminato. Se si tenta di creare un cluster con tale nome e si verifica un conflitto, il cluster è in modalità di eliminazione soft per 14 giorni. È possibile contattare il supporto tecnico per recuperarlo.
  • 404 -- Area di lavoro non trovata. L'area di lavoro specificata non esiste o è stata eliminata.
  • 409 -- Operazione di collegamento o scollegamento dell'area di lavoro in corso.

Passaggi successivi

Monitoraggio di Azure log di distribuzione i cluster dedicati sono un'opzione di distribuzione che abilita funzionalità avanzate per i Monitoraggio di Azure log. I clienti possono selezionare quale delle aree di lavoro Log Analytics deve essere ospitata in cluster dedicati.

I cluster dedicati richiedono ai clienti di eseguire il commit di almeno 500 GB di inserimento dati al giorno. È possibile eseguire la migrazione di un'area di lavoro esistente a un cluster dedicato senza perdita di dati o interruzione del servizio.

Funzionalità che richiedono cluster dedicati:

  • Chiavi gestite dal cliente: crittografare i dati del cluster usando le chiavi fornite e controllate dal cliente.
  • Lockbox: controllare che i tecnici del supporto Tecnico Microsoft accedono alle richieste ai dati.
  • Doppia crittografia: protegge da uno scenario in cui uno degli algoritmi o delle chiavi di crittografia può essere compromesso. In questo caso, il livello aggiuntivo di crittografia continua a proteggere i dati.
  • zone di disponibilità: proteggere i dati dagli errori del data center con zone separate fisicamente da posizioni e dotate di alimentazione, raffreddamento e rete indipendenti. La separazione fisica nelle zone e nell'infrastruttura indipendente rende un evento imprevisto molto meno probabile perché l'area di lavoro può basarsi sulle risorse di qualsiasi zona. I cluster dedicati vengono creati con le zone di disponibilità abilitate per la resilienza dei dati nelle aree in cui Azure dispone di zone di disponibilità. La configurazione delle zone di disponibilità nel cluster non può essere modificata dopo la creazione e le impostazioni possono essere verificate nella proprietà del cluster isAvailabilityZonesEnabled . Monitoraggio di Azure zone di disponibilità copre parti più ampie del servizio e, se disponibili nell'area, estende automaticamente Monitoraggio di Azure resilienza.
  • Più aree di lavoro: se un cliente usa più di un'area di lavoro per la produzione, potrebbe essere utile usare un cluster dedicato. Le query tra aree di lavoro verranno eseguite più velocemente se tutte le aree di lavoro si verificano nello stesso cluster. Potrebbe anche essere più conveniente usare un cluster dedicato perché il livello di impegno assegnato tiene conto di tutte le operazioni di inserimento del cluster e si applica a tutte le aree di lavoro, anche se alcune sono piccole e non idonee per lo sconto del livello di impegno.

Gestione

I cluster dedicati vengono gestiti con una risorsa di Azure che rappresenta Monitoraggio di Azure cluster di log. Le operazioni vengono eseguite a livello di codice tramite l'interfacciadella riga di comando, PowerShell o REST.

Dopo aver creato un cluster, le aree di lavoro possono essere collegate e i nuovi dati inseriti vengono archiviati nel cluster. Le aree di lavoro possono essere scollegate da un cluster in qualsiasi momento e i nuovi dati vengono archiviati in cluster di Log Analytics condivisi. L'operazione di collegamento e scollegamento non influisce sulle query e sull'accesso ai dati prima e dopo l'operazione con soggetti alla conservazione nelle aree di lavoro. Il cluster e le aree di lavoro devono essere nella stessa area per consentire il collegamento.

Tutte le operazioni a livello di cluster richiedono Microsoft.OperationalInsights/clusters/write l'autorizzazione azione per il cluster. Questa autorizzazione può essere concessa tramite il proprietario o il collaboratore che contiene l'azione o tramite il ruolo */write Collaboratore Log Analytics che contiene l'azione. Microsoft.OperationalInsights/* Per altre informazioni sulle autorizzazioni di Log Analytics, vedere Gestire l'accessoai dati di log e alle aree di lavoro in Monitoraggio di Azure .

Modello tariffario del cluster

I cluster dedicati di Log Analytics usano un modello tariffario di livello impegno (precedentemente denominato prenotazioni di capacità) di almeno 500 GB al giorno. Qualsiasi utilizzo superiore al livello di livello verrà fatturato alla tariffa effettiva per GB di tale livello di impegno. Le informazioni sui prezzi del piano di impegno sono disponibili nella Monitoraggio di Azure prezzi.

Il livello di impegno del cluster viene configurato a livello di codice con Azure Resource Manager usando il Capacity parametro in Sku . È specificato in unità di GB e può avere valori Capacity di 500, 1000, 2000 o 5000 GB/giorno.

Esistono due modalità di fatturazione per l'utilizzo in un cluster. Possono essere specificati dal billingType parametro durante la configurazione del cluster.

  1. Cluster (impostazione predefinita):la fatturazione per i dati inseriti viene eseguita a livello di cluster. Le quantità di dati inseriti da ogni area di lavoro associata a un cluster vengono aggregate per calcolare la fattura giornaliera per il cluster.

  2. Areedi lavoro: i costi del livello di impegno per il cluster vengono attribuiti proporzionalmente alle aree di lavoro del cluster, dal volume di inserimento dati di ogni area di lavoro (dopo aver preso in conto le allocazioni per nodo da Microsoft Defender per Cloud per ogni area di lavoro). Questi dettagli completi di questo modello tariffario sono illustrati qui.

Se l'area di lavoro usa il piano tariffario Legacy Per Nodo, quando è collegata a un cluster, verrà fatturata in base ai dati inseriti a fronte del livello impegno del cluster e non più per nodo. Le allocazioni di dati per nodo da Microsoft Defender per cloud continueranno a essere applicate.

I dettagli completi relativi alla fatturazione per i cluster dedicati di Log Analytics sono disponibili qui.

Creare un cluster dedicato

Quando si crea un nuovo cluster dedicato, è necessario specificare le proprietà seguenti:

L'account utente che crea i cluster deve avere l'autorizzazione di creazione delle risorse di Azure standard e l'autorizzazione di scrittura del cluster disponendo nelle assegnazioni di ruolo di questa azione specifica Microsoft.Resources/deployments/*Microsoft.OperationalInsights/clusters/write o Microsoft.OperationalInsights/**/write .

Dopo aver creato la risorsa cluster, è possibile modificare proprietà aggiuntive, ad esempio sku,*keyVaultProperties o billingType. Vedere altri dettagli di seguito.

È possibile avere fino a 2 cluster attivi per ogni sottoscrizione per area. Se il cluster viene eliminato, è ancora riservato per 14 giorni. È possibile avere fino a 4 cluster riservati per ogni sottoscrizione per area (attivi o eliminati di recente).

Nota

La creazione del cluster attiva l'allocazione e il provisioning delle risorse. Il completamento di questa operazione può richiedere alcune ore. Il cluster dedicato viene fatturato dopo il provisioning indipendentemente dall'inserimento dei dati ed è consigliabile preparare la distribuzione per velocizzare il provisioning e il collegamento delle aree di lavoro al cluster. Verificare gli elementi seguenti:

  • Viene identificato un elenco dell'area di lavoro iniziale da collegare al cluster
  • Si dispone delle autorizzazioni per la sottoscrizione destinata al cluster e a qualsiasi area di lavoro da collegare

CLI

az account set --subscription "cluster-subscription-id"

az monitor log-analytics cluster create --no-wait --resource-group "resource-group-name" --name "cluster-name" --location "region-name" --sku-capacity "daily-ingestion-gigabyte"

# Wait for job completion when `--no-wait` was used
$clusterResourceId = az monitor log-analytics cluster list --resource-group "resource-group-name" --query "[?contains(name, "cluster-name")].[id]" --output tsv
az resource wait --created --ids $clusterResourceId --include-response-body true

PowerShell

Select-AzSubscription "cluster-subscription-id"

New-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name" -Location "region-name" -SkuCapacity "daily-ingestion-gigabyte" -AsJob

# Check when the job is done when `-AsJob` was used
Get-Job -Command "New-AzOperationalInsightsCluster*" | Format-List -Property *

REST API

Chiamare

PUT https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.OperationalInsights/clusters/<cluster-name>?api-version=2021-06-01
Authorization: Bearer <token>
Content-type: application/json

{
  "identity": {
    "type": "systemAssigned"
    },
  "sku": {
    "name": "capacityReservation",
    "Capacity": 500
    },
  "properties": {
    "billingType": "Cluster",
    },
  "location": "<region>",
}

Response.

Deve essere 202 (accettato) e un'intestazione.

Controllare lo stato del provisioning del cluster

Il provisioning del cluster di Log Analytics richiede un po' di tempo. Usare uno dei metodi seguenti per controllare la proprietà ProvisioningState. Il valore è ProvisioningAccount durante il provisioning e Operazione completata.

CLI

az account set --subscription "cluster-subscription-id"

az monitor log-analytics cluster show --resource-group "resource-group-name" --name "cluster-name"

PowerShell

Select-AzSubscription "cluster-subscription-id"

Get-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name"

REST API

Inviare una richiesta GET sulla risorsa cluster ed esaminare il valore provisioningState. Il valore è ProvisioningAccount durante il provisioning e Operazione completata.

GET https://management.azure.com/subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.OperationalInsights/clusters/cluster-name?api-version=2021-06-01
Authorization: Bearer <token>

Response.

{
  "identity": {
    "type": "SystemAssigned",
    "tenantId": "tenant-id",
    "principalId": "principal-id"
  },
  "sku": {
    "name": "capacityreservation",
    "capacity": 500
  },
  "properties": {
    "provisioningState": "ProvisioningAccount",
    "clusterId": "cluster-id",
    "billingType": "Cluster",
    "lastModifiedDate": "last-modified-date",
    "createdDate": "created-date",
    "isDoubleEncryptionEnabled": false,
    "isAvailabilityZonesEnabled": false,
    "capacityReservationProperties": {
      "lastSkuUpdate": "last-sku-modified-date",
      "minCapacity": 500
    }
  },
  "id": "/subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.OperationalInsights/clusters/cluster-name",
  "name": "cluster-name",
  "type": "Microsoft.OperationalInsights/clusters",
  "location": "cluster-region"
}

Il GUID principalId viene generato dal servizio di identità gestito durante la creazione del cluster.