Abilitare il monitoraggio per i cluster Kubernetes

Articolo
03/11/2024

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 sui contenitori per la raccolta di log
Grafana gestita 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 è selettivi sui log raccolti. Prima di abilitare il monitoraggio per il cluster, vedere gli articoli seguenti per assicurarsi che l'ambiente sia ottimizzato per i costi e limitare la raccolta dei log solo ai dati necessari:

Configurare la raccolta dati e l'ottimizzazione dei costi in Informazioni dettagliate sui contenitori usando la regola di raccolta dati
Informazioni dettagliate sulla personalizzazione della raccolta di log dopo aver abilitato il monitoraggio, inclusa 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 organizzati in base ai cinque pilastri di 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.

Prerequisiti

Autorizzazioni

È necessario almeno l'accesso collaboratore al cluster per l'onboarding.
Per visualizzare i dati dopo l'abilitazione del monitoraggio, è necessario il lettore di monitoraggio o il collaboratore al 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 della sottoscrizione dell'area di lavoro Grafana:
- Microsoft.Dashboard

Prerequisiti per i cluster Kubernetes abilitati per Arc

Prerequisiti per le estensioni del cluster Kubernetes abilitate per Azure Arc.
Verificare i requisiti del firewall oltre ai requisiti di rete kubernetes abilitati per Azure Arc.
Se in precedenza è stato installato il monitoraggio per il servizio Azure Kubernetes, assicurarsi di aver disabilitato il monitoraggio prima di procedere 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 riportate in Disabilitare il monitoraggio del cluster Kubernetes per eliminare questo grafico Helm.

Nota

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

Distribuzioni di Red Hat Openshift
Nodi Di Windows

Aree di lavoro

Nella tabella seguente vengono descritte le aree di lavoro necessarie per supportare Le informazioni dettagliate su Prometheus e Contenitore gestite. È 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 posizionate.

Funzionalità	Area di lavoro	Note
Prometheus gestito	Area di lavoro di Monitoraggio di Azure	`Contributor` l'autorizzazione è sufficiente per consentire al componente aggiuntivo di inviare dati all'area di lavoro di Monitoraggio di Azure. È necessaria `Owner` l'autorizzazione a livello per collegare l'area di lavoro di Monitoraggio di Azure per visualizzare le metriche in Grafana gestito di Azure. Questa operazione è necessaria perché l'utente che esegue il passaggio di onboarding deve essere in grado di assegnare il ruolo identità `Monitoring Reader` del sistema Grafana gestito di 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 Informazioni dettagliate sui contenitori.
Grafana gestito	Area di lavoro Grafana gestita di Azure	Collegare l'area di lavoro Grafana all'area di lavoro di Monitoraggio di Azure per rendere disponibili le metriche prometheus raccolte dal cluster ai dashboard di Grafana.

Abilitare Prometheus e Grafana

Usare uno dei metodi seguenti per abilitare la raschiatura delle metriche di Prometheus dal cluster e abilitare Managed Grafana 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 gestita di Azure.

Nota

Se si ha una singola risorsa di Monitoraggio di Azure collegata privata, 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 del servizio Azure Kubernetes. 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 Usare un collegamento privato per l'inserimento dei dati di Prometheus gestito.

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, una con un nome nel formato DefaultAzureMonitorWorkspace-<mapped_region> verrà creata 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-metricsaz 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 metriche che elimina le metriche di Prometheus.

Comandi di esempio

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

### Use existing Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics -n <cluster-name> -g <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 -n <cluster-name> -g <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 -n <cluster-name> -g <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]"

Uno dei comandi può usare i parametri facoltativi seguenti:

AKS: --ksm-metric-annotations-allow-list
Arco: --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 le etichette dei nomi e dei nomi. Per includere altre annotazioni, specificare un elenco di nomi di risorse nel formato plurale e chiavi di annotazione Kubernetes che si desidera consentire. È possibile specificare un singolo oggetto * per ogni risorsa per consentire eventuali annotazioni, ma questo ha gravi implicazioni sulle prestazioni. Ad esempio: pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],....
AKS: --ksm-metric-labels-allow-list
Arco: --AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist
Elenco delimitato da virgole di altre chiavi di etichetta Kubernetes usate nella metrica kube_resource_labels della risorsa kube_resource_labels metrica. 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, specificare un elenco di nomi di risorse nel formato plurale e chiavi di etichetta Kubernetes che si vuole consentire a ogni risorsa di consentire l'uso di un'unica * risorsa per consentire qualsiasi etichetta, ma questo 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.

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

Prerequisiti

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

Nota

Attualmente in Bicep non è possibile definire in modo esplicito l'ambito dell'assegnazione Monitoring Reader di ruolo in 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. Non esiste anche alcuna specifica dell'API REST per un'area di lavoro di Monitoraggio di Azure.

Pertanto, l'ambito predefinito per il Monitoring Reader ruolo è nel gruppo di risorse. Il ruolo viene applicato alla stessa area di lavoro di Monitoraggio di Azure in base all'ereditarietà, ovvero il comportamento previsto. Dopo aver distribuito questo modello Bicep, all'istanza di Grafana vengono concesse Monitoring Reader le autorizzazioni 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 gestita di 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 gestita di Azure nella portale di Azure selezionare visualizzazione JSON e copiare il valore del azureMonitorWorkspaceIntegrations quale 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

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
Cluster del servizio Azure Kubernetes Bicep
- 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
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

Modificare i valori seguenti nel file di parametri. Lo stesso set di valori viene usato per i modelli ARM e Bicep. Recuperare l'ID risorsa delle risorse dalla visualizzazione JSON della relativa pagina 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 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 monitoraggio di Azure.
`clusterResourceId`	ID risorsa per il cluster del servizio Azure Kubernetes. Recuperare dalla visualizzazione JSON nella pagina Panoramica del cluster.
`clusterLocation`	Posizione del cluster del servizio Azure Kubernetes. Recuperare dalla visualizzazione JSON nella pagina Panoramica del 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`	Percorso 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 il sku.name.

Aprire il file modello e aggiornare la grafanaIntegrations proprietà 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 erano full_resource_id_2 già presenti nella risorsa Grafana gestita di Azure JSON. La voce finale azureMonitorWorkspaceResourceId è 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
                    }
                ]
            }
        }
    }

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.

Prerequisiti

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

Recuperare i valori necessari per una risorsa Grafana

Nella pagina Panoramica per l'istanza di Grafana gestita di Azure nella portale di Azure selezionare visualizzazione JSON.

Se si usa un'istanza di Grafana gestita di Azure esistente già collegata a un'area di lavoro di Monitoraggio di Azure, è necessario l'elenco delle integrazioni di Grafana. Copiare il valore del azureMonitorWorkspaceIntegrations campo. Se non esiste, l'istanza non è stata collegata ad alcuna area di lavoro di Monitoraggio di Azure. Aggiornare il azure_monitor_workspace_integrations blocco 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:

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

Nota: passare le variabili per annotations_allowed e labels_allowed le chiavi in main.tf solo quando questi valori esistono. Si tratta di blocchi 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 ruolo "User Access Amministrazione istrator" nella sottoscrizione del cluster del servizio Azure Kubernetes possono abilitare direttamente il ruolo "Lettore di monitoraggio" distribuendo il modello. Modificare il parametro grafanaSku se si usa uno SKU non standard ed eseguire infine questo modello nel gruppo di risorse della risorsa Grafana.

Scaricare Criteri di Azure file di modello e parametri.
- File modello: https://aka.ms/AddonPolicyMetricsProfile
- File di parametri: https://aka.ms/AddonPolicyMetricsProfile.parameters
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
Dopo aver creato la definizione dei criteri, nella portale di Azure selezionare Criteri e quindi Definizioni. Selezionare la definizione di criteri creata.
Selezionare Assegna e immettere i dettagli nella scheda Parametri . Selezionare Rivedi e crea.
Se si desidera applicare i criteri a un cluster esistente, creare un'attività di correzione per tale risorsa cluster da Assegnazione 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 Informazioni dettagliate sui contenitori

Usare uno dei metodi seguenti per abilitare informazioni dettagliate sui contenitori nel cluster. Al termine, vedere Configurare la raccolta dati dell'agente per Informazioni dettagliate sui contenitori per personalizzare la configurazione per assicurarsi di non raccogliere più dati di quanto necessario.

Usare uno dei comandi seguenti per abilitare il monitoraggio dei cluster abilitati per il servizio Azure Kubernetes e 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 è l'impostazione predefinita nella versione k8s-extension 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 in ContainerLogV2 usando ConfigMap.

Cluster del servizio Azure Kubernetes

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

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

Esempio

az aks enable-addons -a monitoring -n "my-cluster" -g "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>

Per le impostazioni di configurazione disponibili, vedere la sezione richieste di risorse e limiti del grafico Helm.

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 amalogs.ignoreExtensionProxySettings=truedi configurazione .

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) o 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>

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 un modello

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
Cluster del servizio Azure Kubernetes Bicep
- File modello (Syslog): https://aka.ms/enable-monitoring-msi-syslog-bicep-template
- File di parametri (nessun syslog): https://aka.ms/enable-monitoring-msi-syslog-bicep-parameters
- File modello (nessun syslog): https://aka.ms/enable-monitoring-msi-bicep-template
- File di parametri (nessun 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

Parametro	Descrizione
AKS: `aksResourceId` Arco: `clusterResourceId`	ID risorsa del cluster.
AKS: `aksResourceLocation` Arco: `clusterRegion`	Località del cluster.
AKS: `workspaceResourceId` Arco: `workspaceResourceId`	ID risorsa dell'area di lavoro Log Analytics.
Arco: `workspaceRegion`	Area dell'area di lavoro Log Analytics.
Arco: `workspaceDomain`	Dominio dell'area di lavoro Log Analytics. `opinsights.azure.com` per il cloud pubblico di Azure `opinsights.azure.us` per AzureUSGovernment.
AKS: `resourceTagValues`	Valori di tag specificati per la regola DCR (Container Insights Data Collection) esistente del cluster e il nome del controller di dominio. Il nome sarà `MSCI-<clusterName>-<clusterRegion>` e questa risorsa creata in un gruppo di risorse cluster del servizio Azure Kubernetes. Per la prima volta l'onboarding, è possibile impostare valori di tag arbitrari.

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.

Nuovo cluster del servizio Azure Kubernetes

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
Modificare la azurerm_kubernetes_cluster risorsa in main.tf in base alle impostazioni del cluster.

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`	Trovare la corrispondenza con i valori di tag esistenti specificati per la regola DCR (Container Insights Extension Data Collection) esistente del cluster e il nome del record di controllo di dominio. Il nome corrisponde `MSCI-<clusterName>-<clusterRegion>` e questa risorsa viene creata nello stesso gruppo di risorse dei cluster del servizio Azure Kubernetes. Per la prima volta l'onboarding, è possibile impostare i valori arbitrari dei tag.
`enabledContainerLogV2`	Impostare questo valore del parametro su true per usare il valore predefinito ContainerLogV2 consigliato.
Parametri di ottimizzazione dei costi	Fare riferimento ai parametri di raccolta dati

Eseguire terraform init -upgrade per inizializzare la distribuzione di Terraform.
Eseguire terraform plan -out main.tfplan per inizializzare la distribuzione di Terraform.
Eseguire terraform apply main.tfplan per applicare il piano di esecuzione all'infrastruttura cloud.

Cluster del servizio Azure Kubernetes esistente

Importare prima la risorsa cluster esistente con il comando : terraform import azurerm_kubernetes_cluster.k8s <aksResourceId>

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
  }

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

Suggerimento

Modificare il main.tf file in modo appropriato prima di eseguire il modello terraform
I dati inizieranno a fluire dopo 10 minuti perché il cluster deve essere pronto per primo
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

Portale di Azure

Nella scheda Definizioni del menu Criteri della portale di Azure creare una definizione di criteri con i dettagli seguenti.
- Percorso di definizione: sottoscrizione di Azure in cui deve essere archiviata la definizione dei criteri.
- Nome: Servizio Azure Kubernetes-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.
Selezionare la nuova definizione del servizio Azure Kubernetes Monitoring Addon (Componente aggiuntivo per il monitoraggio del servizio Azure Kubernetes).
Selezionare Assegna e specificare un ambito in cui devono essere assegnati i criteri.
Selezionare Avanti e specificare l'ID risorsa dell'area di lavoro Log Analytics.
Creare un'attività di correzione se si vuole applicare i criteri ai cluster del servizio Azure Kubernetes esistenti nell'ambito selezionato.
Selezionare Rivedi e crea per creare l'assegnazione dei criteri.

Interfaccia della riga di comando di Azure

Scaricare Criteri di Azure file di modello e parametri.
- File modello: https://aka.ms/enable-monitoring-msi-azure-policy-template
- File di parametri: https://aka.ms/enable-monitoring-msi-azure-policy-parameters

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

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>\" } }"

Abilitare il monitoraggio completo con portale di Azure

Usando il portale di Azure, è possibile abilitare contemporaneamente le informazioni dettagliate su Prometheus gestito e contenitore.

Nota

Se si vuole abilitare Managed Prometheus senza Informazioni dettagliate sui contenitori, abilitarlo dall'area di lavoro di Monitoraggio di Azure come descritto di seguito.

Nuovo cluster del servizio Azure Kubernetes (Prometheus e Informazioni dettagliate sui contenitori)

Quando si crea un nuovo cluster del servizio Azure Kubernetes nella portale di Azure, è possibile abilitare Prometheus, Informazioni dettagliate sui contenitori e Grafana dalla scheda Integrazioni. Nella sezione Monitoraggio di Azure selezionare Configurazione predefinita o Configurazione personalizzata se si desidera specificare le aree di lavoro da usare. È possibile eseguire una configurazione aggiuntiva dopo la creazione del cluster.

Cluster esistente (Prometheus e Informazioni dettagliate sui contenitori)

Questa opzione abilita informazioni dettagliate sui contenitori e facoltativamente Prometheus e Grafana in un cluster del servizio Azure Kubernetes esistente.

Selezionare Insights dal menu del cluster OPPURE selezionare Contenitori dal menu Monitoraggio , scheda Cluster non monitorati e fare clic su Abilita accanto a un cluster.
1. Se Le informazioni dettagliate sui contenitori non sono abilitate per il cluster, viene visualizzata una schermata che identifica le funzionalità abilitate. Fare clic su Configura monitoraggio.
1. Se Le informazioni dettagliate sui contenitori sono già state abilitate nel cluster, selezionare il pulsante Monitoraggio Impostazioni per modificare la configurazione.
Le informazioni dettagliate sui contenitori verranno abilitate. Selezionare le caselle di controllo abilita le metriche di Prometheus e Abilita Grafana se si vuole abilitarle anche per il cluster. Se si dispone di un'area di lavoro di Monitoraggio di Azure esistente e di un'area di lavoro Grafana, vengono selezionate automaticamente.
Fare clic su Impostazioni avanzate per selezionare aree di lavoro alternative o crearne di nuove. L'impostazione Impostazioni predefinite 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 Informazioni dettagliate sui contenitori .
Fare clic su Configura per salvare la configurazione.

Cluster esistente (solo Prometheus)

Questa opzione abilita le metriche di Prometheus in un cluster senza abilitare Informazioni dettagliate sui contenitori.

Aprire il menu Aree di lavoro di Monitoraggio di Azure nella portale di Azure e selezionare l'area di lavoro.
Selezionare Cluster monitorati nella sezione Managed Prometheus (Prometheus gestito) per visualizzare un elenco di cluster del servizio Azure Kubernetes.
Selezionare Configura accanto al cluster da abilitare.

Cluster esistente (aggiungere Prometheus)

Selezionare Contenitori dal menu Monitoraggio, scheda Cluster monitorati e fare clic su Configura accanto a un cluster nella colonna Prometheus gestito.

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. Questo 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 addon Managed Prometheus (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.

Installare manualmente Windows-Exporter nei nodi del servizio Azure Kubernetes per accedere alle metriche di Windows. Abilitare gli agenti di raccolta seguenti:
- [defaults]
- container
- memory
- process
- cpu_info
Per altri agenti di raccolta, vedere Prometheus exporter for Windows metrics (Utilità di esportazione Prometheus per le metriche di Windows).

Distribuire il file YAML windows-exporter-daemonset:
```
    kubectl apply -f windows-exporter-daemonset.yaml
```
Applicare ama-metrics-settings-configmap al cluster. Impostare i windowsexporter valori booleani e windowskubeproxy su true. Per altre informazioni, vedere Configmap delle impostazioni del componente aggiuntivo Metriche.
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 su enableWindowsRecordingRulestrue nel file dei parametri.
- Se il cluster è già stato eseguito l'onboarding, usare questo modello di Resource Manager e questo file di parametri per creare i gruppi di regole.

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 Informazioni dettagliate contenitore

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 aks show comando 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 -g <resourceGroupofAKSCluster> -n <nameofAksCluster>

Il comando restituirà informazioni in formato JSON sulla soluzione. La addonProfiles sezione 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 geografica/Località	Descrizione
`MSCI-<aksclusterregion>-<clustername>`	Regola di raccolta dati	Uguale al cluster	Uguale all'area di lavoro Log Analytics	Questa regola di raccolta dati è per la 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 dati	Uguale al cluster	Uguale all'area di lavoro di Monitoraggio di Azure	Questa regola di raccolta dati è per la raccolta di metriche prometheus per componente aggiuntivo delle metriche, che ha scelto l'area di lavoro monitoraggio di Azure come destinazione ed è associata anche alla risorsa cluster del servizio Azure Kubernetes
`MSPROM-<aksclusterregion>-<clustername>`	Endpoint raccolta dati	Uguale al cluster	Uguale all'area di lavoro di 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 geografica/Località	Descrizione
`<azuremonitor-workspace-name>`	Regola di raccolta dati	<MA_azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed	Uguale all'area di lavoro di 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 di 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 Working Set è 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 Informazioni dettagliate sui contenitori 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 in uscita nella rete virtuale del cluster.

Passaggi successivi

Se si verificano problemi durante il tentativo di onboarding della soluzione, vedere la guida alla risoluzione dei problemi.
Con il monitoraggio abilitato per raccogliere l'integrità e l'utilizzo delle risorse del cluster e dei carichi di lavoro del servizio Azure Kubernetes in esecuzione, informazioni su come usare Informazioni dettagliate sui contenitori .

Abilitare il monitoraggio per i cluster Kubernetes

Cluster supportati

Prerequisiti

Aree di lavoro

Abilitare Prometheus e Grafana

Prerequisiti

Cluster del servizio Azure Kubernetes

Cluster con abilitazione di Arc

Abilitare Informazioni dettagliate sui contenitori

Prerequisiti

Cluster del servizio Azure Kubernetes

Cluster con abilitazione di Arc

Abilitare il monitoraggio completo con portale di Azure

Nuovo cluster del servizio Azure Kubernetes (Prometheus e Informazioni dettagliate sui contenitori)

Cluster esistente (Prometheus e Informazioni dettagliate sui contenitori)

Cluster esistente (solo Prometheus)

Cluster esistente (aggiungere Prometheus)

Abilitare la raccolta delle metriche di Windows (anteprima)

Verificare la distribuzione

Prometheus gestito

Informazioni dettagliate contenitore

Risorse di cui è stato effettuato il provisioning

Differenze tra cluster Windows e Linux

Passaggi successivi

Risorse aggiuntive