Abilitare il monitoraggio per i cluster Kubernetes

Questo articolo descrive come abilitare il monitoraggio completo dei cluster Kubernetes usando le funzionalità di Monitoraggio di Azure seguenti:

• Prometheus gestito per la raccolta di metriche
• Informazioni dettagliate contenitore per la raccolta di log
• Grafana gestito per la visualizzazione.

Usando il portale di Azure, è possibile abilitare tutte le funzionalità contemporaneamente. È anche possibile abilitarli singolarmente usando l'interfaccia della riga di comando di Azure, il modello di Azure Resource Manager, Terraform o Criteri di Azure. Ognuno di questi metodi è descritto in questo articolo.

Importante

I cluster Kubernetes generano molti dati di log, che possono comportare costi significativi se non si presta attenzione a quali log vengono raccolti. Prima di abilitare il monitoraggio per il cluster, vedere gli articoli seguenti per assicurarsi che l'ambiente sia ottimizzato per i costi e per limitare la raccolta dei log solo ai dati necessari:

• Configurare la raccolta dei dati e l'ottimizzazione dei costi in Container Insights utilizzando la regola di raccolta dati
  Informazioni dettagliate sulla personalizzazione della raccolta di log dopo aver abilitato il monitoraggio, incluso l'uso delle configurazioni di ottimizzazione dei costi predefinite.
• Procedure consigliate per il monitoraggio di Kubernetes con Monitoraggio di Azure
  Procedure consigliate per il monitoraggio dei cluster Kubernetes organizzate in base ai cinque pilastri del framework Azure Well-Architected Framework, inclusa l'ottimizzazione dei costi.
• Ottimizzazione dei costi in Monitoraggio di Azure
  Procedure consigliate per configurare tutte le funzionalità di Monitoraggio di Azure per ottimizzare i costi e limitare la quantità di dati raccolti.

Cluster supportati

Questo articolo fornisce indicazioni sull'onboarding per i tipi di cluster seguenti. Le eventuali differenze nel processo per ogni tipo sono indicate nelle sezioni pertinenti.

• Cluster Azure Kubernetes
• Cluster Kubernetes con abilitazione di Arc

Prerequisiti

Autorizzazioni

• È necessario almeno l'accesso Collaboratore al cluster per l'onboarding.
• È necessario il ruolo Lettore di monitoraggio o Collaboratore al monitoraggio per visualizzare i dati dopo l'abilitazione del monitoraggio.

Prerequisiti di Prometheus gestiti

• Il cluster deve usare l’autenticazione dell'identità gestita.
• I provider di risorse seguenti devono essere registrati nella sottoscrizione del cluster servizio Azure Kubernetes e nell'area di lavoro Monitoraggio di Azure:
  • Microsoft.ContainerService
  • Microsoft.Insights
  • Microsoft.AlertsManagement
  • Microsoft.Monitor
• I provider di risorse seguenti devono essere registrati nella sottoscrizione dell'area di lavoro Grafana:
  • Microsoft.Dashboard

Prerequisiti dei cluster Kubernetes abilitati per Arc

• Prerequisiti per estensioni del cluster Kubernetes abilitate per Azure Arc.
  • Verificare i requisiti del firewall oltre ai requisiti di rete Kubernetes abilitata per Azure Arc.
  • Se in precedenza è stato installato il monitoraggio per il servizio Azure Kubernetes, prima di procedere assicurarsi di aver disabilitato il monitoraggio, per evitare problemi durante l'installazione dell'estensione.
  • Se in precedenza è stato installato il monitoraggio in un cluster usando uno script senza estensioni del cluster, seguire le istruzioni in Disabilitare il monitoraggio del cluster Kubernetes per eliminare questo grafico Helm.

Nota

L'estensione Kubernetes abilitata per Arc di Prometheus gestito non supporta le configurazioni seguenti:

• Distribuzioni di Red Hat Openshift, tra cui Azure Red Hat OpenShift (ARO)
• Nodi di Windows

Aree di lavoro

Nella tabella seguente vengono descritte le aree di lavoro necessarie per supportare Prometheus gestito e Container Insights. È possibile creare ogni area di lavoro come parte del processo di onboarding o usare un'area di lavoro esistente. Vedere Progettare un'architettura dell'area di lavoro Log Analytics per indicazioni sul numero di aree di lavoro da creare e sulla posizione in cui devono essere inserite.

Funzionalità	Area di lavoro	Note
Prometheus gestito	Area di lavoro di Monitoraggio di Azure	L'autorizzazione Contributor è sufficiente per consentire al componente aggiuntivo di inviare dati all'area di lavoro di Monitoraggio di Azure. È necessaria l'autorizzazione a livello di Owner per collegare l'area di lavoro di Monitoraggio di Azure in modo da visualizzare le metriche in Grafana con gestione Azure. Questa operazione è necessaria perché l'utente che esegue il passaggio di onboarding deve essere in grado di assegnare il ruolo Monitoring Reader di identità del sistema Grafana con gestione Azure nell'area di lavoro di Monitoraggio di Azure per eseguire query sulle metriche.
Informazioni dettagliate contenitore	area di lavoro Log Analytics	È possibile collegare un cluster del servizio Azure Kubernetes a un'area di lavoro Log Analytics in una sottoscrizione di Azure diversa nello stesso tenant di Microsoft Entra, ma è necessario usare l'interfaccia della riga di comando di Azure o un modello di Azure Resource Manager. Non è attualmente possibile eseguire questa configurazione con il portale di Azure. Se si connette un cluster del servizio Azure Kubernetes esistente a un'area di lavoro Log Analytics in un'altra sottoscrizione, il provider di risorse Microsoft.ContainerService deve essere registrato nella sottoscrizione con l'area di lavoro Log Analytics. Per maggiori informazioni, consultare la sezione Registrare il provider di risorse. Per un elenco delle coppie di mapping supportate da usare per l'area di lavoro predefinita, vedere Mapping delle aree supportate da Container Insights.
Grafana gestito	Area di lavoro di Grafana con gestione Azure	Collegare l'area di lavoro Grafana all'area di lavoro di Monitoraggio di Azure per rendere disponibili le metriche di Prometheus raccolte dal cluster ai dashboard di Grafana.

Abilitare Prometheus e Grafana

Usare uno dei metodi seguenti per abilitare lo scorporo delle metriche di Prometheus dal cluster e abilitare Grafana gestito per visualizzare le metriche. Vedere Collegare un'area di lavoro Grafana per le opzioni per connettere l'area di lavoro di Monitoraggio di Azure e l'area di lavoro Grafana con gestione Azure.

Nota

Se si ha una singola risorsa di Monitoraggio di Azure con collegamento privato, l'abilitazione di Prometheus non funzionerà se il cluster del servizio Azure Kubernetes e l'area di lavoro di Monitoraggio di Azure si trovano in aree diverse. La configurazione necessaria per il componente aggiuntivo Prometheus non è disponibile tra aree a causa del vincolo di collegamento privato. Per risolvere questo problema, creare un nuovo controller di dominio nel percorso del cluster del servizio Azure Kubernetes e una nuova associazione DCRA nella stessa area del cluster. Associare il nuovo controller di dominio al cluster del servizio Azure Kubernetes e denominare la nuova associazione (DCRA) come configurationAccessEndpoint. Per istruzioni complete su come configurare i controller di dominio associati all'area di lavoro di Monitoraggio di Azure per l'uso di un collegamento privato per l'inserimento dati, vedere Abilitare un collegamento privato per il monitoraggio di Kubernetes in Monitoraggio di Azure.

CLI

Abilitare con l'interfaccia della riga di comando

Se non si specifica un'area di lavoro di Monitoraggio di Azure esistente nei comandi seguenti, verrà usata l'area di lavoro predefinita per il gruppo di risorse. Se un'area di lavoro predefinita non esiste già nell'area del cluster, ne verrà creata una con un nome nel formato DefaultAzureMonitorWorkspace-<mapped_region> in un gruppo di risorse con il nome DefaultRG-<cluster_region>.

Prerequisiti

• È necessaria la versione dell'interfaccia della riga di comando di Az 2.49.0 o successiva.
• L'estensione aks-preview deve essere disinstallata dai cluster del servizio Azure Kubernetes usando il comando az extension remove --name aks-preview.
• L'estensione k8s-extension deve essere installata usando il comando az extension add --name k8s-extension.
• È necessaria la versione 1.4.1 o successiva dell'estensione k8s.

Cluster del servizio Azure Kubernetes

Usare l'opzione -enable-azure-monitor-metrics az aks create o az aks update (a seconda che si stia creando un nuovo cluster o aggiornando un cluster esistente) per installare il componente aggiuntivo delle metriche che scorpora le metriche Prometheus.

Comandi di esempio

### Use default Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group>

### Use existing Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <azure-monitor-workspace-name-resource-id> --grafana-resource-id  <grafana-workspace-name-resource-id>

### Use optional parameters
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --ksm-metric-labels-allow-list "namespaces=[k8s-label-1,k8s-label-n]" --ksm-metric-annotations-allow-list "pods=[k8s-annotation-1,k8s-annotation-n]"

Cluster con abilitazione di Arc

### Use default Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics

## Use existing Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id>

### Use optional parameters
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id> AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList="pods=[k8s-annotation-1,k8s-annotation-n]" AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist "namespaces=[k8s-label-1,k8s-label-n]"

I comandi possono usare i parametri facoltativi seguenti:

• Servizio Azure Kubernetes: --ksm-metric-annotations-allow-list
  Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList
  Elenco delimitato da virgole delle chiavi di annotazioni Kubernetes usate nella metrica kube_resource_annotations della risorsa. Ad esempio, kube_pod_annotations è la metrica delle annotazioni per la risorsa pod. Per impostazione predefinita, questa metrica contiene solo il nome e le etichette dello spazio dei nomi. Per includere altre annotazioni, specificare un elenco di nomi di risorse nel formato plurale e le chiavi di annotazione Kubernetes che si desidera consentire. È possibile specificare un singolo * per ogni risorsa per consentire qualsiasi annotazione, ma questo approccio ha gravi implicazioni sulle prestazioni. Ad esempio: pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],....
  
• Servizio Azure Kubernetes: --ksm-metric-labels-allow-list
  Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist
  Elenco delimitato da virgole di altre chiavi di etichetta Kubernetes usate nella metrica kube_resource_labels della risorsa kube_resource_labels. Ad esempio, kube_pod_labels è la metrica delle etichette per la risorsa pod. Per impostazione predefinita, questa metrica contiene solo il nome e le etichette dello spazio dei nomi. Per includere più etichette, fornire un elenco di nomi di risorse nel formato plurale e le chiavi di etichetta Kubernetes che si desidera consentire per loro. È possibile specificare un singolo * per ogni risorsa per consentire qualsiasi etichetta, ma questo approccio ha gravi implicazioni sulle prestazioni. Ad esempio: pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],....
  
• Servizio Azure Kubernetes: --enable-windows-recording-rules consente di abilitare i gruppi di regole di registrazione necessari per il corretto funzionamento dei dashboard di Windows.

Azure Resource Manager

Abilitare con i modelli di Resource Manager

Prerequisiti

• È necessario creare già l'area di lavoro di Monitoraggio di Azure e l'istanza di Grafana con gestione Azure.
• Il modello deve essere distribuito nello stesso gruppo di risorse dell'istanza di Grafana con gestione Azure.
• Se l'istanza di Grafana con gestione Azure si trova in una sottoscrizione diversa da quella dell'area di lavoro di Monitoraggio di Azure, registrare la sottoscrizione dell'area di lavoro di Monitoraggio di Azure con il provider di risorse Microsoft.Dashboard seguendo le indicazioni riportate in Registrare il provider di risorse.
• Gli utenti con il ruolo User Access Administrator nella sottoscrizione del cluster del servizio Azure Kubernetes possono abilitare il ruolo Monitoring Reader direttamente distribuendo il modello.

Nota

Attualmente in Bicep non è possibile definire in modo esplicito l'ambito dell'assegnazione di ruolo Monitoring Reader su un parametro stringa "ID risorsa" per un'area di lavoro di Monitoraggio di Azure come in un modello di Resource Manager. Bicep prevede un valore di tipo resource | tenant. Inoltre, non esiste alcuna specifica di API REST per un'area di lavoro di Monitoraggio di Azure.

Pertanto, l'ambito predefinito per il ruolo Monitoring Reader è nel gruppo di risorse. Il ruolo viene applicato alla stessa area di lavoro di Monitoraggio di Azure in base all'ereditarietà, cosa che è il comportamento previsto. Dopo aver distribuito questo modello Bicep, all'istanza di Grafana vengono concesse le autorizzazioni Monitoring Reader per tutte le aree di lavoro di Monitoraggio di Azure in tale gruppo di risorse.

Recuperare i valori obbligatori per la risorsa Grafana

Se l'istanza di Grafana con gestione Azure è già collegata a un'area di lavoro di Monitoraggio di Azure, è necessario includere questo elenco nel modello. Nella pagina Panoramica per l'istanza di Grafana con gestione Azure nel portale di Azure selezionare Visualizzazione JSON e copiare il valore di azureMonitorWorkspaceIntegrations che sarà simile all'esempio seguente. Se non esiste, l'istanza non è stata collegata ad alcuna area di lavoro di Monitoraggio di Azure.

"properties": {
    "grafanaIntegrations": {
        "azureMonitorWorkspaceIntegrations": [
            {
                "azureMonitorWorkspaceResourceId": "full_resource_id_1"
            },
            {
                "azureMonitorWorkspaceResourceId": "full_resource_id_2"
            }
        ]
    }
}

Scaricare e modificare il modello e il file dei parametri

1. Scaricare i file necessari per il tipo di cluster Kubernetes in uso.

   ARM del cluster del servizio Azure Kubernetes

   • File modello: https://aka.ms/azureprometheus-enable-arm-template
   • File di parametri: https://aka.ms/azureprometheus-enable-arm-template-parameters

   Bicep del cluster del servizio Azure Kubernetes

   • File modello: https://aka.ms/azureprometheus-enable-bicep-template
   • File di parametri: https://aka.ms/azureprometheus-enable-bicep-template-parameters
   • Modulo DCRA: https://aka.ms/nested_azuremonitormetrics_dcra_clusterResourceId
   • Modulo profilo: https://aka.ms/nested_azuremonitormetrics_profile_clusterResourceId
   • Modulo di assegnazione di ruolo di Grafana con gestione Azure: https://aka.ms/nested_grafana_amw_role_assignment

   ARM del cluster con abilitazione di Arc

   • File modello: https://aka.ms/azureprometheus-arc-arm-template
   • File di parametri: https://aka.ms/azureprometheus-arc-arm-template-parameters

2. Modificare i valori seguenti nel file di parametri. Per i modelli ARM e Bicep viene usato lo stesso set di valori. Recuperare l'ID risorsa delle risorse dalla Visualizzazione JSON della relativa pagina di Panoramica.

   Parametro	Valore
   azureMonitorWorkspaceResourceId	ID risorsa per l'area di lavoro di Monitoraggio di Azure. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'area di lavoro di Monitoraggio di Azure.
   azureMonitorWorkspaceLocation	Posizione dell'area di lavoro di Monitoraggio di Azure. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'area di lavoro di Monitoraggio di Azure.
   clusterResourceId	ID risorsa per il cluster del servizio Azure Kubernetes. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per il cluster.
   clusterLocation	Posizione del cluster del servizio Azure Kubernetes. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per il cluster.
   metricLabelsAllowlist	Elenco delimitato da virgole delle chiavi delle etichette kubernetes da usare nella metrica delle etichette della risorsa.
   metricAnnotationsAllowList	Elenco delimitato da virgole di altre chiavi di etichetta Kubernetes da usare nella metrica delle annotazioni della risorsa.
   grafanaResourceId	ID risorsa per l'istanza di Grafana gestita. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'istanza di Grafana.
   grafanaLocation	Posizione per l'istanza di Grafana gestita. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'istanza di Grafana.
   grafanaSku	SKU per l'istanza di Grafana gestita. Recuperare dalla Visualizzazione JSON nella pagina Panoramica per l'istanza di Grafana. Usare sku.name.

3. Aprire il file modello e aggiornare la proprietà grafanaIntegrations alla fine del file con i valori recuperati dall'istanza di Grafana. L'aspetto sarà simile agli esempi seguenti. In questi esempi full_resource_id_1 e full_resource_id_2 erano già presenti nel codice JSON della risorsa Grafana con gestione Azure. La voce azureMonitorWorkspaceResourceId finale è già presente nel modello e viene usata per il collegamento all'ID risorsa dell'area di lavoro di Monitoraggio di Azure fornito nel file dei parametri.

   ARM

   {
       "type": "Microsoft.Dashboard/grafana",
       "apiVersion": "2022-08-01",
       "name": "[split(parameters('grafanaResourceId'),'/')[8]]",
       "sku": {
           "name": "[parameters('grafanaSku')]"
       },
       "location": "[parameters('grafanaLocation')]",
       "properties": {
           "grafanaIntegrations": {
           "azureMonitorWorkspaceIntegrations": [
               {
                   "azureMonitorWorkspaceResourceId": "full_resource_id_1"
               },
               {
                   "azureMonitorWorkspaceResourceId": "full_resource_id_2"
               },
               {
                   "azureMonitorWorkspaceResourceId": "[parameters('azureMonitorWorkspaceResourceId')]"
               }
           ]
           }
       }
   }
   

   Bicep

       resource grafanaResourceId_8 'Microsoft.Dashboard/grafana@2022-08-01' = {
           name: split(grafanaResourceId, '/')[8]
           sku: {
               name: grafanaSku
           }
           identity: {
               type: 'SystemAssigned'
           }
           location: grafanaLocation
           properties: {
               grafanaIntegrations: {
                   azureMonitorWorkspaceIntegrations: [
                       {
                           azureMonitorWorkspaceResourceId: 'full_resource_id_1'
                       }
                       {
                           azureMonitorWorkspaceResourceId: 'full_resource_id_2'
                       }
                       {
                           azureMonitorWorkspaceResourceId: azureMonitorWorkspaceResourceId
                       }
                   ]
               }
           }
       }
   

4. Distribuire il modello con il file di parametri usando qualsiasi metodo valido per la distribuzione di modelli di Resource Manager. Per esempi di metodi diversi, vedere Distribuire i modelli di esempio.

Terraform

Abilitare con Terraform

Prerequisiti

• È necessario creare già l'area di lavoro di Monitoraggio di Azure e l'area di lavoro di Grafana con gestione Azure.
• Il modello deve essere distribuito nello stesso gruppo di risorse dell'area di lavoro di Grafana con gestione Azure.
• Gli utenti con il ruolo Amministratore accesso utente nella sottoscrizione del cluster del servizio Azure Kubernetes possono abilitare il ruolo Lettore monitoraggio direttamente distribuendo il modello.
• Se l'istanza di Grafana con gestione Azure si trova in una sottoscrizione diversa da quella dell'area di lavoro di Monitoraggio di Azure, registrare la sottoscrizione dell'area di lavoro di Monitoraggio di Azure con il provider di risorse Microsoft.Dashboard seguendo questa documentazione.

Recuperare i valori obbligatori per una risorsa Grafana

Nella pagina Panoramica per l'istanza di Grafana con gestione Azure nel portale di Azure selezionare Visualizzazione JSON.

Se si usa un'istanza di Grafana con gestione Azure esistente già collegata a un'area di lavoro di Monitoraggio di Azure, è necessario l'elenco delle integrazioni di Grafana. Copiare il valore del campo azureMonitorWorkspaceIntegrations. Se non esiste, l'istanza non è stata collegata ad alcuna area di lavoro di Monitoraggio di Azure. Aggiornare il blocco azure_monitor_workspace_integrations in main.tf con l'elenco delle integrazioni di Grafana.

  azure_monitor_workspace_integrations {
    resource_id  = var.monitor_workspace_id[var.monitor_workspace_id1, var.monitor_workspace_id2]
  }

Scaricare e modificare i modelli

Se si distribuisce un nuovo cluster del servizio Azure Kubernetes usando Terraform con il componente aggiuntivo Prometheus gestito abilitato, seguire questa procedura:

1. Scaricare tutti i file in AddonTerraformTemplate.
2. Modificare le variabili nel file variables.tf con i valori dei parametri corretti.
3. Eseguire terraform init -upgrade per inizializzare la distribuzione di Terraform.
4. Eseguire terraform plan -out main.tfplan per inizializzare la distribuzione di Terraform.
5. Eseguire terraform apply main.tfplan per applicare il piano di esecuzione all'infrastruttura cloud.

Nota: passare le variabili per le chiavi annotations_allowed e labels_allowed in main.tf solo quando tali valori esistono. Questi blocchi sono facoltativi.

Nota

Modificare il file main.tf in modo appropriato prima di eseguire il modello terraform. Aggiungere tutti i valori di azure_monitor_workspace_integrations esistenti alla risorsa Grafana prima di eseguire il modello. In caso contrario, i valori meno recenti vengono eliminati e sostituiti con ciò che è presente nel modello durante la distribuzione. Gli utenti con il ruolo Amministratore accesso utente nella sottoscrizione del cluster del servizio Azure Kubernetes possono abilitare il ruolo Lettore monitoraggio direttamente distribuendo il modello. Modificare il parametro grafanaSku se si usa un SKU non standard ed eseguire infine questo modello nel gruppo di risorse della risorsa Grafana.

Criteri di Azure

Eseguire l'abilitazione con Criteri di Azure

1. Scaricare il modello e i file dei parametri di Criteri di Azure.

   • File modello: https://aka.ms/AddonPolicyMetricsProfile
   • File di parametri: https://aka.ms/AddonPolicyMetricsProfile.parameters

2. Creare la definizione dei criteri usando il comando dell'interfaccia della riga di comando seguente:

   az policy definition create --name "Prometheus Metrics addon" --display-name "Prometheus Metrics addon" --mode Indexed --metadata version=1.0.0 category=Kubernetes --rules AddonPolicyMetricsProfile.rules.json --params AddonPolicyMetricsProfile.parameters.json

3. Dopo aver creato la definizione dei criteri, nel portale di Azure selezionare Criteri e quindi Definizioni. Selezionare la definizione di criteri creata.

4. Selezionare Assegna e immettere i dettagli nella scheda Parametri. Selezionare Rivedi e crea.

5. Se si desidera applicare i criteri a un cluster esistente, creare un'Attività di correzione per tale risorsa cluster da Assegnazione di criteri.

Dopo aver assegnato i criteri alla sottoscrizione, ogni volta che si crea un nuovo cluster senza Prometheus abilitato, i criteri verranno eseguiti e distribuiti per abilitare il monitoraggio di Prometheus.

Abilitare Container Insights

Usare uno dei metodi seguenti per abilitare Container Insights nel cluster. Una volta completata l’operazione, vedere Configurare la raccolta dati dell'agente per informazioni dettagliate sui contenitori per personalizzare la configurazione e assicurarsi di non raccogliere più dati di quanto necessario.

CLI

Usare uno dei comandi seguenti per abilitare il monitoraggio dei cluster del servizio Azure Kubernetes e abilitati per Arc. Se non si specifica un'area di lavoro Log Analytics esistente, verrà usata l'area di lavoro predefinita per il gruppo di risorse. Se un'area di lavoro predefinita non esiste già nell'area del cluster, ne verrà creata una con un nome nel formato DefaultWorkspace-<GUID>-<Region>.

Prerequisiti

• Interfaccia della riga di comando di Azure versione 2.43.0 o successiva
• L'autenticazione dell'identità gestita è predefinita nell'interfaccia della riga di comando versione 2.49.0 o successiva.
• Estensione Azure k8s versione 1.3.7 o successiva
• L'autenticazione dell'identità gestita è predefinita in k8s-extension versione 1.43.0 o successiva.
• L'autenticazione dell'identità gestita non è supportata per i cluster Kubernetes abilitati per Arc con nodi ARO (Azure Red Hat Openshift) o Windows. Usare l'autenticazione legacy.
• Per l'interfaccia della riga di comando versione 2.54.0 o successiva, lo schema di registrazione verrà configurato per ContainerLogV2 usando ConfigMap.

Nota

È possibile abilitare lo schema ContainerLogV2 per un cluster usando la regola di raccolta dati del cluster o ConfigMap. Se entrambe le impostazioni sono abilitate, ConfigMap avrà la precedenza. I log stdout e stderr verranno inseriti nella tabella ContainerLog solo quando sia DCR che ConfigMap vengono esplicitamente disattivati.

Cluster del servizio Azure Kubernetes

### Use default Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name>

### Use existing Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id>

### Use legacy authentication
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id> --enable-msi-auth-for-monitoring false

Esempio

az aks enable-addons --addon monitoring --name "my-cluster" --resource-group "my-resource-group" --workspace-resource-id "/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Cluster con abilitazione di Arc

### Use default Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers

### Use existing Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID=<workspace-resource-id>

### Use managed identity authentication (default as k8s-extension version 1.43.0)
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=true

### Use advanced configuration settings
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings  amalogs.resources.daemonset.limits.cpu=150m amalogs.resources.daemonset.limits.memory=600Mi amalogs.resources.deployment.limits.cpu=1 amalogs.resources.deployment.limits.memory=750Mi

### With custom mount path for container stdout & stderr logs
### Custom mount path not required for Azure Stack Edge version > 2318. Custom mount path must be /home/data/docker for Azure Stack Edge cluster with version <= 2318
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.logsettings.custommountpath=<customMountPath>

Vedere la sezione Richieste di risorse e limiti del grafico Helm per le impostazioni di configurazione disponibili.

Esempio

az k8s-extension create --name azuremonitor-containers --cluster-name "my-cluster" --resource-group "my-resource-group" --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID="/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Cluster abilitato per Arc con proxy di inoltro

Se il cluster è configurato con un proxy di inoltro, le impostazioni proxy vengono applicate automaticamente all'estensione. Nel caso di un cluster con AMPLS + proxy, la configurazione proxy deve essere ignorata. Eseguire l'onboarding dell'estensione con l'impostazione di configurazione amalogs.ignoreExtensionProxySettings=true.

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.ignoreExtensionProxySettings=true

Cluster abilitato per Arc con nodi ARO o OpenShift o Windows

L'autenticazione dell'identità gestita non è supportata per i cluster Kubernetes abilitati per Arc con nodi ARO (Azure Red Hat OpenShift), OpenShift o Windows. Usare l'autenticazione legacy specificando amalogs.useAADAuth=false come nell'esempio seguente.

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=false

Eliminare l'istanza dell'estensione

Il comando seguente elimina solo l'istanza dell'estensione, ma non elimina l'area di lavoro Log Analytics. I dati nella risorsa di Log Analytics sono rimasti intatti.

az k8s-extension delete --name azuremonitor-containers --cluster-type connectedClusters --cluster-name <cluster-name> --resource-group <resource-group>

Azure Resource Manager

Entrambi i modelli ARM e Bicep sono disponibili in questa sezione.

Prerequisiti

• Il modello deve essere distribuito nello stesso gruppo di risorse del cluster.

Scaricare e installare il modello

1. Scaricare e modificare il modello e il file dei parametri

   ARM del cluster del servizio Azure Kubernetes

   • File modello: https://aka.ms/aks-enable-monitoring-msi-onboarding-template-file
   • File di parametri: https://aka.ms/aks-enable-monitoring-msi-onboarding-template-parameter-file

   Bicep del cluster del servizio Azure Kubernetes

   • File modello (Syslog): https://aka.ms/enable-monitoring-msi-syslog-bicep-template
   • File di parametri (senza Syslog): https://aka.ms/enable-monitoring-msi-syslog-bicep-parameters
   • File modello (senza Syslog): https://aka.ms/enable-monitoring-msi-bicep-template
   • File di parametri (senza Syslog): https://aka.ms/enable-monitoring-msi-bicep-parameters

   ARM del cluster con abilitazione di Arc

   • File modello: https://aka.ms/arc-k8s-azmon-extension-msi-arm-template
   • File di parametri: https://aka.ms/arc-k8s-azmon-extension-msi-arm-template-params
   • File modello (autenticazione legacy): https://aka.ms/arc-k8s-azmon-extension-arm-template
   • File di parametri (autenticazione legacy): https://aka.ms/arc-k8s-azmon-extension-arm-template-params

2. Modificare i valori seguenti nel file di parametri. Per i modelli ARM e Bicep viene usato lo stesso set di valori. Recuperare l'ID risorsa delle risorse dalla Visualizzazione JSON della relativa pagina di Panoramica.

   Parametro	Descrizione
   Servizio Azure Kubernetes: aksResourceId Arc: clusterResourceId	ID risorsa del cluster.
   Servizio Azure Kubernetes: aksResourceLocation Arc: clusterRegion	Località del cluster.
   Servizio Azure Kubernetes: workspaceResourceId Arc: workspaceResourceId	ID risorsa dell'area di lavoro Log Analytics.
   Arc: workspaceRegion	Area dell'area di lavoro Log Analytics.
   Arc: workspaceDomain	Dominio dell'area di lavoro Log Analytics. opinsights.azure.com per cloud pubblico di Azure opinsights.azure.us per AzureUSGovernment.
   Servizio Azure Kubernetes: resourceTagValues	Valori di tag specificati per la regola di raccolta dati (DCR) dell’estensione Dati analitici sui contenitori esistente del cluster e nome della regola. Il nome sarà MSCI-<clusterName>-<clusterRegion> e questa risorsa creata in un gruppo di risorse cluster del servizio Azure Kubernetes. Per il primo onboarding, è possibile impostare valori di tag arbitrari.

3. Distribuire il modello con il file di parametri usando qualsiasi metodo valido per la distribuzione di modelli di Resource Manager. Per esempi di metodi diversi, vedere Distribuire i modelli di esempio.

Terraform

Nuovo cluster del servizio Azure Kubernetes

1. Scaricare il file modello Terraform a seconda che si voglia abilitare la raccolta Syslog.

   Syslog

   • https://aka.ms/enable-monitoring-msi-syslog-terraform

   Nessun syslog

   • https://aka.ms/enable-monitoring-msi-terraform

2. Modificare la risorsa azurerm_kubernetes_cluster in main.tf in base alle impostazioni del cluster.

3. Aggiornare i parametri in variables.tf per sostituire i valori in "<>"

   Parametro	Descrizione
   aks_resource_group_name	Usare i valori nella pagina Panoramica del servizio Azure Kubernetes per il gruppo di risorse.
   resource_group_location	Usare i valori nella pagina Panoramica del servizio Azure Kubernetes per il gruppo di risorse.
   cluster_name	Definire il nome del cluster da creare.
   workspace_resource_id	Usare l'ID risorsa dell'area di lavoro Log Analytics.
   workspace_region	Usare la posizione dell'area di lavoro Log Analytics.
   resource_tag_values	Abbinare i valori di tag specificati esistenti per la regola di raccolta dati (DCR) dell'estensione Dati analitici sui contenitori esistente del cluster e il nome della regola. Il nome corrisponderà a MSCI-<clusterName>-<clusterRegion> e questa risorsa verrà creata nello stesso gruppo di risorse dei cluster del servizio Azure Kubernetes. Per il primo onboarding, è possibile impostare valori di tag arbitrari.
   enabledContainerLogV2	Impostare questo valore del parametro su true per usare il valore predefinito ContainerLogV2 consigliato.
   Parametri di ottimizzazione dei costi	Fare riferimento a Parametri di raccolta dati

4. Eseguire terraform init -upgrade per inizializzare la distribuzione di Terraform.

5. Eseguire terraform plan -out main.tfplan per inizializzare la distribuzione di Terraform.

6. Eseguire terraform apply main.tfplan per applicare il piano di esecuzione all'infrastruttura cloud.

Cluster del servizio Azure Kubernetes

1. Importare prima la risorsa cluster esistente con il comando: terraform import azurerm_kubernetes_cluster.k8s <aksResourceId>
2. Aggiungere il profilo del componente aggiuntivo oms_agent alla risorsa azurerm_kubernetes_cluster esistente.

   oms_agent {
       log_analytics_workspace_id = var.workspace_resource_id
       msi_auth_for_monitoring_enabled = true
     }
   

3. Copiare le risorse DCR e DCRA dai modelli Terraform
4. Eseguire terraform plan -out main.tfplan e assicurarsi che la modifica stia aggiungendo la proprietà oms_agent. Nota: se la risorsa azurerm_kubernetes_cluster definita è diversa durante il piano terraform, il cluster esistente verrà eliminato e ricreato.
5. Eseguire terraform apply main.tfplan per applicare il piano di esecuzione all'infrastruttura cloud.

Suggerimento

• Modificare il file main.tf in modo appropriato prima di eseguire il modello terraform
• I dati inizieranno a fluire dopo 10 minuti perché il cluster deve essere prima predisposto
• WorkspaceID deve corrispondere al formato /subscriptions/12345678-1234-9876-4563-123456789012/resourceGroups/example-resource-group/providers/Microsoft.OperationalInsights/workspaces/workspaceValue
• Se il gruppo di risorse esiste già, eseguire terraform import azurerm_resource_group.rg /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group_Name> prima del piano terraform

Criteri di Azure

Portale di Azure

1. Nella scheda Definizioni del menu Criteri nel portale di Azure creare una definizione di criteri con i dettagli seguenti.

   • Percorso definizione: sottoscrizione di Azure in cui deve essere archiviata la definizione dei criteri.
   • Nome: AKS-Monitoring-Addon
   • Descrizione: criteri personalizzati di Azure per abilitare il componente aggiuntivo di monitoraggio nei cluster Azure Kubernetes.
   • Categoria: selezionare Usa esistente e quindi Kubernetes dall'elenco a discesa.
   • Regola dei criteri: sostituire il codice JSON di esempio esistente con il contenuto di https://aka.ms/aks-enable-monitoring-custom-policy.

2. Selezionare la nuova definizione di criteri Componente aggiuntivo per il monitoraggio del servizio Azure Kubernetes.

3. Selezionare Assegna e specificare un Ambito in cui assegnare i criteri.

4. Selezionare Avanti e specificare l'ID risorsa dell'area di lavoro Log Analytics.

5. Creare un'attività di correzione se si vogliono applicare i criteri ai cluster del servizio Azure Kubernetes esistenti nell'ambito selezionato.

6. Selezionare Rivedi e crea per creare l'assegnazione dei criteri.

Interfaccia della riga di comando di Azure

1. Scaricare il modello e i file dei parametri di Criteri di Azure.

   • File modello: https://aka.ms/enable-monitoring-msi-azure-policy-template
   • File di parametri: https://aka.ms/enable-monitoring-msi-azure-policy-parameters

2. Creare la definizione dei criteri usando il comando dell'interfaccia della riga di comando seguente:

   az policy definition create --name "AKS-Monitoring-Addon-MSI" --display-name "AKS-Monitoring-Addon-MSI" --mode Indexed --metadata version=1.0.0 category=Kubernetes --rules azure-policy.rules.json --params azure-policy.parameters.json
   

3. Creare la definizione dei criteri usando il comando dell'interfaccia della riga di comando seguente:

   az policy assignment create --name aks-monitoring-addon --policy "AKS-Monitoring-Addon-MSI" --assign-identity --identity-scope /subscriptions/<subscriptionId> --role Contributor --scope /subscriptions/<subscriptionId> --location <location> --role Contributor --scope /subscriptions/<subscriptionId> -p "{ \"workspaceResourceId\": { \"value\":  \"/subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/microsoft.operationalinsights/workspaces/<workspaceName>\" } }"
   

Dopo aver assegnato i criteri alla sottoscrizione, ogni volta che si crea un nuovo cluster senza Prometheus abilitato, i criteri verranno eseguiti e distribuiti per abilitare il monitoraggio di Prometheus.

Abilitare il monitoraggio completo con il portale di Azure

Nuovo cluster del servizio Azure Kubernetes (Prometheus, Container Insights e Grafana)

Quando si crea un nuovo cluster del servizio Azure Kubernetes nel portale di Azure, è possibile abilitare Prometheus, Container Insights e Grafana dalla scheda Monitoraggio. Assicurarsi di aver selezionato le caselle Abilitare log contenitori, Abilitare le metriche di Prometheus e Abilitare Grafana.

Cluster esistente (Prometheus, Container Insights e Grafana)

1. Passare al cluster del servizio Azure Kubernetes nel portale di Azure.
2. Nel menu di servizio, in Monitoraggio, selezionare Informazioni dettagliate>Configurare monitoraggio.
3. Le informazioni dettagliate sui contenitori sono già abilitate. Selezionare le caselle Abilitare le metriche di Prometheus e Abilitare Grafana. Se si dispone di un'area di lavoro di Monitoraggio di Azure esistente e di un'area di lavoro Grafana, vengono selezionate automaticamente.
4. Selezionare Impostazioni avanzate per selezionare aree di lavoro alternative o crearne di nuove. L'impostazione Preimpostazioni costi consente di modificare i dettagli predefiniti della raccolta per ridurre i costi di monitoraggio. Per informazioni dettagliate, vedere Abilitare le impostazioni di ottimizzazione dei costi in Container Insights.
5. Seleziona Configura.

Cluster esistente (solo Prometheus)

1. Passare al cluster del servizio Azure Kubernetes nel portale di Azure.
2. Nel menu di servizio, in Monitoraggio, selezionare Informazioni dettagliate>Configurare monitoraggio.
3. Selezionare la casella Abilitare le metriche di Prometheus.
4. Selezionare Impostazioni avanzate per selezionare aree di lavoro alternative o crearne di nuove. L'impostazione Preimpostazioni costi consente di modificare i dettagli predefiniti della raccolta per ridurre i costi di monitoraggio.
5. Seleziona Configura.

Abilitare la raccolta delle metriche di Windows (anteprima)

Nota

Non esiste alcun limite di CPU/memoria in windows-exporter-daemonset.yaml, quindi potrebbe eseguire il over-provisioning dei nodi Di Windows
Per altri dettagli, vedere Prenotazione delle risorse

Durante la distribuzione dei carichi di lavoro, impostare i limiti di memoria delle risorse e CPU per i contenitori. Ciò sottrae anche da NodeAllocatable e consente all'utilità di pianificazione a livello di cluster di determinare quali pod inserire nei nodi. La pianificazione dei pod senza limiti può eseguire il provisioning eccessivo dei nodi Windows e in casi estremi può causare la mancata integrità dei nodi.

A partire dalla versione 6.4.0-main-02-22-2023-3ee44b9e del contenitore del componente aggiuntivo Prometheus gestito (prometheus_collector), la raccolta di metriche di Windows è stata abilitata per i cluster del servizio Azure Kubernetes. L'onboarding nel componente aggiuntivo Metriche di Monitoraggio di Azure consente ai pod Windows DaemonSet di avviare l'esecuzione nei pool di nodi. Sono supportati sia Windows Server 2019 che Windows Server 2022. Seguire questa procedura per abilitare i pod per raccogliere le metriche dai pool di nodi di Windows.

1. Installare manualmente Windows-Exporter nei nodi del servizio Azure Kubernetes per accedere alle metriche di Windows distribuendo il file YAML windows-exporter-daemonset. Abilitare i raccoglitori seguenti:

   • [defaults]
   • container
   • memory
   • process
   • cpu_info

   Per altri agenti di raccolta, vedere Utilità di esportazione Prometheus per le metriche di Windows.

   Distribuire il file YAML windows-exporter-daemonset. Si noti che, se nel nodo sono presenti taint applicati, sarà necessario applicare le tolleranze appropriate.

       kubectl apply -f windows-exporter-daemonset.yaml
   

2. Applicare ama-metrics-settings-configmap al cluster. Impostare i valori booleani windowsexporter e windowskubeproxy su true. Per altre informazioni, vedere Configmap delle impostazioni del componente aggiuntivo Metriche.

3. Abilitare le regole di registrazione necessarie per i dashboard predefiniti:

   • Se si esegue l'onboarding usando l'interfaccia della riga di comando, includere l'opzione --enable-windows-recording-rules.
   • Se si esegue l'onboarding usando un modello di Resource Manager, Bicep o Criteri di Azure, impostare enableWindowsRecordingRules su true nel file dei parametri.
   • Se il cluster è già stato sottoposto a onboarding, usare questo modello di Resource Manager e questo file di parametri per creare i gruppi di regole. Verranno aggiunte le regole di registrazione necessarie. Non si tratta di un'operazione ARM nel cluster e non influisce sullo stato di monitoraggio corrente del cluster.

Verificare la distribuzione

Usare lo strumento da riga di comando kubectl per verificare che l'agente sia distribuito correttamente.

Prometheus gestito

Verificare che il DaemonSet sia stato distribuito correttamente nei pool di nodi Linux

kubectl get ds ama-metrics-node --namespace=kube-system

Il numero di pod deve essere uguale al numero di nodi Linux nel cluster. Il risultato dovrebbe essere simile all'esempio seguente:

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-node   1         1         1       1            1           <none>          10h

Verificare che i nodi Windows siano stati distribuiti correttamente

kubectl get ds ama-metrics-win-node --namespace=kube-system

Il numero di pod deve essere uguale al numero di nodi Windows nel cluster. Il risultato dovrebbe essere simile all'esempio seguente:

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME                   DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-win-node   3         3         3       3            3           <none>          10h

Verificare che i due ReplicaSet siano stati distribuiti per Prometheus

kubectl get rs --namespace=kube-system

Il risultato dovrebbe essere simile all'esempio seguente:

User@aksuser:~$kubectl get rs --namespace=kube-system
NAME                            DESIRED   CURRENT   READY   AGE
ama-metrics-5c974985b8          1         1         1       11h
ama-metrics-ksm-5fcf8dffcd      1         1         1       11h

Informazioni dettagliate contenitore

Verificare che i DaemonSet siano stati distribuiti correttamente nei pool di nodi Linux

kubectl get ds ama-logs --namespace=kube-system

Il numero di pod deve essere uguale al numero di nodi Linux nel cluster. Il risultato dovrebbe essere simile all'esempio seguente:

User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-logs   2         2         2         2            2           <none>          1d

Verificare che i nodi Windows siano stati distribuiti correttamente

kubectl get ds ama-logs-windows --namespace=kube-system

Il numero di pod deve essere uguale al numero di nodi Windows nel cluster. Il risultato dovrebbe essere simile all'esempio seguente:

User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR     AGE
ama-logs-windows           2         2         2         2            2       <none>            1d

Verificare la distribuzione della soluzione Container Insights

kubectl get deployment ama-logs-rs --namespace=kube-system

Il risultato dovrebbe essere simile all'esempio seguente:

User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
ama-logs-rs   1/1     1            1           24d

Visualizzare la configurazione con l'interfaccia della riga di comando

Usare il comando aks show per verificare se la soluzione è abilitata, l'ID risorsa dell'area di lavoro Log Analytics e le informazioni di riepilogo sul cluster.

az aks show --resource-group <resourceGroupofAKSCluster> --name <nameofAksCluster>

Il comando restituirà informazioni in formato JSON sulla soluzione. La sezione addonProfiles deve includere informazioni su omsagent come nell'esempio seguente:

"addonProfiles": {
    "omsagent": {
        "config": {
            "logAnalyticsWorkspaceResourceID": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
            "useAADAuth": "true"
        },
        "enabled": true,
        "identity": null
    },
}

Risorse di cui è stato effettuato il provisioning

Quando si abilita il monitoraggio, nella sottoscrizione vengono create le risorse seguenti:

Nome della risorsa	Tipo di risorsa	Gruppo di risorse	Area/Posizione	Descrizione
MSCI-<aksclusterregion>-<clustername>	Regola di raccolta dei dati	Uguale al cluster	Uguale all'area di lavoro Log Analytics	Questa regola di raccolta dati si applica alla raccolta di log da parte dell'agente di Monitoraggio di Azure, che usa l'area di lavoro Log Analytics come destinazione ed è associata alla risorsa cluster del servizio Azure Kubernetes.
MSPROM-<aksclusterregion>-<clustername>	Regola di raccolta dei dati	Uguale al cluster	Uguale all'area di lavoro Monitoraggio di Azure	Questa regola di raccolta dati si applica alla raccolta di metriche Prometheus in base al componente aggiuntivo delle metriche, che dispone dell'area di lavoro monitoraggio di Azure scelta come destinazione ed è associata anche alla risorsa cluster del servizio Azure Kubernetes
MSPROM-<aksclusterregion>-<clustername>	Endpoint di raccolta dati	Uguale al cluster	Uguale all'area di lavoro Monitoraggio di Azure	Questo endpoint di raccolta dati viene usato dalla regola di raccolta dati precedente per l'inserimento di metriche Prometheus dal componente aggiuntivo per le metriche

Quando si crea una nuova area di lavoro di Monitoraggio di Azure, vengono create le risorse aggiuntive seguenti come parte di essa

Nome della risorsa	Tipo di risorsa	Gruppo di risorse	Area/Posizione	Descrizione
<azuremonitor-workspace-name>	Regola di raccolta dei dati	MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed	Uguale all'area di lavoro Monitoraggio di Azure	DCR creato quando si usa il server OSS Prometheus per scrivere in remoto nell'area di lavoro di Monitoraggio di Azure.
<azuremonitor-workspace-name>	Endpoint di raccolta dati	MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed	Uguale all'area di lavoro Monitoraggio di Azure	DCE creato quando si usa il server OSS Prometheus per scrivere in remoto nell'area di lavoro di Monitoraggio di Azure.

Differenze tra cluster Windows e Linux

Le principali differenze nel monitoraggio di un cluster Windows Server rispetto a un cluster Linux includono:

• Windows non dispone di una metrica RSS Memoria. Di conseguenza, non è disponibile per nodi e contenitori di Windows. La metrica Set di lavoro è disponibile.
• Le informazioni sulla capacità di archiviazione su disco non sono disponibili per i nodi Windows.
• Vengono monitorati solo gli ambienti pod, non gli ambienti Docker.
• Con la versione di anteprima sono supportati un massimo di 30 contenitori di Windows Server. Questa limitazione non si applica ai contenitori Linux.

Nota

Il supporto di Container Insights per il sistema operativo Windows Server 2022 è disponibile in anteprima.

L'agente Linux in contenitori (pod replicaset) effettua chiamate API a tutti i nodi Windows sulla porta sicura Kubelet (10250) all'interno del cluster per raccogliere le metriche correlate alle prestazioni del nodo e del contenitore. La porta sicura Kubelet (:10250) deve essere aperta nella rete virtuale del cluster per la raccolta di metriche correlate alle prestazioni del contenitore e del nodo Windows in ingresso e in uscita.

Se si dispone di un cluster Kubernetes con nodi Windows, esaminare e configurare il gruppo di sicurezza di rete e i criteri di rete per assicurarsi che la porta sicura Kubelet (:10250) sia aperta sia per la rete virtuale in ingresso che per quella in uscita nella rete virtuale del cluster.

Passaggi successivi

• Se si verificano problemi durante il tentativo di onboarding della soluzione, esaminare la Guida per la risoluzione dei problemi.
• Una volta abilitato il monitoraggio per rilevare l'integrità e l'utilizzo delle risorse del cluster e dei carichi di lavoro del servizio Azure Kubernetes in esecuzione, è possibile trovare informazioni su come usare Dati analitici sui contenitori.