Usare l'estensione Diagnostica per Linux 4.0 per monitorare le metriche e i log

Questo articolo descrive le versioni più recenti dell'estensione diagnostica Linux (LAD).

L'estensione Diagnostica per Linux consente di monitorare l'integrità delle macchine virtuali Linux in Microsoft Azure. Questo servizio offre le funzionalità seguenti:

Questa estensione funziona con entrambi i modelli di distribuzione di Azure: Azure Resource Manager e versione classica.

Prerequisiti

• Agente Linux di Azure 2.2.0 o versione successiva. La maggior parte delle immagini della raccolta Linux di macchine virtuali di Azure include la versione 2.2.7 o successive. Eseguire /usr/sbin/waagent -version per verificare la versione installata nella macchina virtuale. Se la macchina virtuale esegue una versione precedente dell'agente guest, aggiornare l'agente Linux.
• Interfaccia della riga di comando di Azure. Configurare l'ambiente dell'interfaccia della riga di comando di Azure nella macchina virtuale.
• Il comando wget. Se non è già disponibile, installarlo usando la gestione pacchetti corrispondente.
• Una sottoscrizione di Azure e un account di archiviazione per utilizzo generico per archiviare i dati. Gli account di archiviazione per utilizzo generico supportano l'archiviazione tabelle, necessaria. Un account di archiviazione BLOB non funziona.
• Python 2.

Distribuzioni Linux supportate

Vedere Sistemi operativi dell'agente supportati.

Requisito di Python

L'estensione di diagnostica per Linux richiede Python 2. Se la macchina virtuale usa una distribuzione che non include Python 2, installarla.

Per installare Python 2, eseguire uno dei comandi di esempio seguenti:

• Red Hat, CentOS, Oracle: yum install -y python2
• Ubuntu, Debian: apt-get install -y python2
• SUSE: zypper install -y python2

Il python2 file eseguibile deve essere sottoposto a alias a python.

1. Eseguire il comando seguente per rimuovere eventuali alias esistenti.

   sudo update-alternatives --remove-all python
   

2. Eseguire il comando seguente per creare il nuovo alias.

   sudo update-alternatives --install /usr/bin/python python /usr/bin/python2 1
   

Installare l'estensione

È possibile abilitare questa estensione per la VM e il Set di scalabilità di macchine virtuali usando i cmdlet di Azure PowerShell, gli script dell'interfaccia della riga di comando di Azure, i modelli di Azure Resource Manager (modelli di ARM) o il portale di Azure. Per altre informazioni, vedere Estensioni e funzionalità della macchina virtuale per Linux.

Usare le istruzioni di installazione e la configurazione di esempio scaricabile per configurare LAD 4.0 per:

• Acquisire e archiviare le stesse metriche fornite da LAD versioni 2.3 e 3.x.
• Inviare le metriche al sink di Monitoraggio di Azure insieme al normale sink ad Archiviazione di Azure. Questa funzionalità è una novità di LAD 4.0.
• Acquisire un insieme utile di metriche File system, come in LAD 3.0.
• Acquisire la raccolta di SysLog predefinita abilitata da LAD 2.3.
• Abilitare l'esperienza del portale di Azure per la creazione di grafici e avvisi relativi alle metriche della VM.

La configurazione scaricabile è solo un esempio. Modificarlo per adeguarlo alle proprie esigenze.

Installazione

È possibile installare e configurare LAD 4.0 nell'interfaccia della riga di comando di Azure o in Azure PowerShell.

az vm extension set --publisher Microsoft.Azure.Diagnostics \
  --name LinuxDiagnostic --version 4.0 --resource-group <resource_group_name> \
  --vm-name <vm_name> --protected-settings ProtectedSettings.json \
  --settings PublicSettings.json

Set-AzVMExtension -ResourceGroupName <resource_group_name> -VMName <vm_name> `
  -Location <vm_location> -ExtensionType LinuxDiagnostic `
  -Publisher Microsoft.Azure.Diagnostics -Name LinuxDiagnostic `
  -SettingString $publicSettings -ProtectedSettingString $protectedSettings `
  -TypeHandlerVersion 4.0

Abilitare l'aggiornamento automatico

È consigliabile abilitare l'aggiornamento automatico dell'agente abilitando la funzionalità Aggiornamento automatico dell'estensione:

az vm extension set --publisher Microsoft.Azure.Diagnostics --name LinuxDiagnostic \
  --version 4.0 --resource-group <resource_group_name> --vm-name <vm_name> \
  --protected-settings ProtectedSettings.json --settings PublicSettings.json \
  --enable-auto-upgrade true

Set-AzVMExtension -ResourceGroupName <resource_group_name> -VMName <vm_name> `
  -Location <vm_location> -ExtensionType LinuxDiagnostic `
  -Publisher Microsoft.Azure.Diagnostics -Name LinuxDiagnostic `
  -SettingString $publicSettings -ProtectedSettingString $protectedSettings `
  -TypeHandlerVersion 4.0 -EnableAutomaticUpgrade $true

Installazione di esempio

In questi esempi, la configurazione di esempio raccoglie un set di dati standard e li invia all'archiviazione tabelle. L'URL per la configurazione di esempio e il relativo contenuto possono cambiare.

Nella maggior parte dei casi, è bene scaricare una copia del file JSON delle impostazioni del portale e personalizzarla in base alle proprie esigenze. Usare i modelli o la propria automazione per usare una versione personalizzata del file di configurazione anziché scaricarla dall'URL ogni volta.

Quando si abilita il nuovo sink di Monitoraggio di Azure, le VM devono avere l'identità assegnata dal sistema abilitata per generare token di autenticazione msi (Managed Service Identity). È possibile aggiungere queste impostazioni durante o dopo la creazione della VM. Per istruzioni per il portale di Azure, l'interfaccia della riga di comando di Azure, PowerShell e Azure Resource Manager, vedere Configurare le identità gestite.

# Set your Azure VM diagnostic variables.
my_subscription_id=<your_azure_subscription_id>
my_resource_group=<your_azure_resource_group_name_containing_your_azure_linux_vm>
my_linux_vm=<your_azure_linux_vm_name>
my_diagnostic_storage_account=<your_azure_storage_account_for_storing_vm_diagnostic_data>

# Login to Azure before you do anything else.
az login

# Select the subscription that contains the storage account.
az account set --subscription $my_subscription_id

# Enable system-assigned identity on the existing VM.
az vm identity assign --resource-group $my_resource_group --name $my_linux_vm

# Download the sample public settings. You could instead use curl or any web browser.
wget https://raw.githubusercontent.com/Azure/azure-linux-extensions/master/Diagnostic/tests/lad_2_3_compatible_portal_pub_settings.json -O portal_public_settings.json

# Build the VM resource ID. Replace the storage account name and resource ID in the public settings.
my_vm_resource_id=$(az vm show --resource-group $my_resource_group \
  --name $my_linux_vm --query "id" -o tsv)
sed -i "s#__DIAGNOSTIC_STORAGE_ACCOUNT__#$my_diagnostic_storage_account#g" portal_public_settings.json
sed -i "s#__VM_RESOURCE_ID__#$my_vm_resource_id#g" portal_public_settings.json

# Build the protected settings (storage account SAS token).
my_diagnostic_storage_account_sastoken=$(az storage account generate-sas \
  --account-name $my_diagnostic_storage_account --expiry 2037-12-31T23:59:00Z \
  --permissions wlacu --resource-types co --services bt -o tsv)
my_lad_protected_settings="{'storageAccountName': '$my_diagnostic_storage_account', \
  'storageAccountSasToken': '$my_diagnostic_storage_account_sastoken'}"

# Finally, tell Azure to install and enable the extension.
az vm extension set --publisher Microsoft.Azure.Diagnostics --name LinuxDiagnostic \
  --version 4.0 --resource-group $my_resource_group --vm-name $my_linux_vm \
  --protected-settings "${my_lad_protected_settings}" --settings portal_public_settings.json

$storageAccountName = "yourStorageAccountName"
$storageAccountResourceGroup = "yourStorageAccountResourceGroupName"
$vmName = "yourVMName"
$VMresourceGroup = "yourVMResourceGroupName"

# Get the VM object
$vm = Get-AzVM -Name $vmName -ResourceGroupName $VMresourceGroup

# Enable system-assigned identity on an existing VM
Update-AzVM -ResourceGroupName $VMresourceGroup -VM $vm -IdentityType SystemAssigned

# Get the public settings template from GitHub and update the templated values for the storage account and resource ID
$publicSettings = (Invoke-WebRequest -Uri https://raw.githubusercontent.com/Azure/azure-linux-extensions/master/Diagnostic/tests/lad_2_3_compatible_portal_pub_settings.json).Content
$publicSettings = $publicSettings.Replace('__DIAGNOSTIC_STORAGE_ACCOUNT__', $storageAccountName)
$publicSettings = $publicSettings.Replace('__VM_RESOURCE_ID__', $vm.Id)

# If you have your own customized public settings, you can inline those rather than using the preceding template: $publicSettings = '{"ladCfg":  { ... },}'

# Generate a SAS token for the agent to use to authenticate with the storage account
$sasToken = New-AzStorageAccountSASToken -Service Blob,Table `
  -ResourceType Service,Container,Object -Permission "racwdlup" `
  -Context (Get-AzStorageAccount -ResourceGroupName $storageAccountResourceGroup `
  -AccountName $storageAccountName).Context -ExpiryTime $([System.DateTime]::Now.AddYears(10))

# Build the protected settings (storage account SAS token)
$protectedSettings="{'storageAccountName': '$storageAccountName', `
  'storageAccountSasToken': '$sasToken'}"

# Finally, install the extension with the settings you built
Set-AzVMExtension -ResourceGroupName $VMresourceGroup -VMName $vmName `
  -Location $vm.Location -ExtensionType LinuxDiagnostic `
  -Publisher Microsoft.Azure.Diagnostics -Name LinuxDiagnostic `
  -SettingString $publicSettings -ProtectedSettingString $protectedSettings `
  -TypeHandlerVersion 4.0

Esempio di installazione per i Set di scalabilità di macchine virtuali - Interfaccia della riga di comando di Azure

# Set your Azure virtual machine scale set diagnostic variables.
my_subscription_id=<your_azure_subscription_id>
my_resource_group=<your_azure_resource_group_name_containing_your_azure_linux_vm>
my_linux_vmss=<your_azure_linux_vmss_name>
my_diagnostic_storage_account=<your_azure_storage_account_for_storing_vm_diagnostic_data>

# Login to Azure before you do anything else.
az login

# Select the subscription that contains the storage account.
az account set --subscription $my_subscription_id

# Enable system-assigned identity on the existing virtual machine scale set.
az vmss identity assign --resource-group $my_resource_group --name $my_linux_vmss

# Download the sample public settings. You could also use curl or any web browser.
wget https://raw.githubusercontent.com/Azure/azure-linux-extensions/master/Diagnostic/tests/lad_2_3_compatible_portal_pub_settings.json -O portal_public_settings.json

# Build the virtual machine scale set resource ID. Replace the storage account name and resource ID in the public settings.
my_vmss_resource_id=$(az vmss show --resource-group $my_resource_group \
  --name $my_linux_vmss --query "id" -o tsv)
sed -i "s#__DIAGNOSTIC_STORAGE_ACCOUNT__#$my_diagnostic_storage_account#g" portal_public_settings.json
sed -i "s#__VM_RESOURCE_ID__#$my_vmss_resource_id#g" portal_public_settings.json

# Build the protected settings (storage account SAS token).
my_diagnostic_storage_account_sastoken=$(az storage account generate-sas \
  --account-name $my_diagnostic_storage_account --expiry 2037-12-31T23:59:00Z \
  --permissions wlacu --resource-types co --services bt -o tsv)
my_lad_protected_settings="{'storageAccountName': '$my_diagnostic_storage_account', 'storageAccountSasToken': '$my_diagnostic_storage_account_sastoken'}"

# Finally, tell Azure to install and enable the extension.
az vmss extension set --publisher Microsoft.Azure.Diagnostics --name LinuxDiagnostic
  --version 4.0 --resource-group $my_resource_group --vmss-name $my_linux_vmss \
  --protected-settings "${my_lad_protected_settings}" --settings portal_public_settings.json

Aggiornare le impostazioni dell'estensione

Dopo aver modificato le impostazioni protette o pubbliche, eseguire lo stesso comando per distribuirle nella macchina virtuale. Se sono state modificate impostazioni, gli aggiornamenti vengono inviati all'estensione. LAD ricarica la configurazione e si riavvia.

Eseguire la migrazione dalle versioni precedenti dell'estensione

La versione più recente dell'estensione è 4.0, attualmente disponibile in anteprima pubblica. Le versioni precedenti di 3.x sono ancora supportate. Le versioni 2.x sono deprecate dal 31 luglio 2018.

Quando si installa la nuova estensione, abilitare gli aggiornamenti automatici delle versioni secondarie:

• Nelle VM con il modello di distribuzione Azure Resource Manager, includere "autoUpgradeMinorVersion": true nel modello di distribuzione della VM.
• Nelle VM del modello di distribuzione classica specificare la versione 4.* se si installa l'estensione tramite l'interfaccia della riga di comando di Azure o PowerShell.

È possibile usare lo stesso account di archiviazione usato per LAD 3.x.

Impostazioni protette

Questo set di informazioni per la configurazione contiene informazioni riservate che devono essere protette dalla visualizzazione pubblica. Contiene, ad esempio, le credenziali di archiviazione. Le impostazioni vengono trasmesse all'estensione, che le archivia in formato crittografato.

{
    "storageAccountName" : "the storage account to receive data",
    "storageAccountEndPoint": "the hostname suffix for the cloud for this account",
    "storageAccountSasToken": "SAS access token",
    "mdsdHttpProxy": "HTTP proxy settings",
    "sinksConfig": { ... }
}

Per ottenere un token SAS all'interno di un modello di ARM, usare la funzione listAccountSas. Per un modello di esempio, vedere l'esempio di funzione list.

È possibile costruire il token di firma di accesso condiviso necessario tramite il portale di Azure:

1. Selezionare l'account di archiviazione generico che in cui si desidera che l'estensione scriva.
2. Nel menu a sinistra, in Sicurezza + Networkingselezionare Firma di accesso condiviso.
3. Effettuare le selezioni come descritto in precedenza.
4. Selezionare Genera firma di accesso condiviso e stringa di connessione.

Copiare la firma di accesso condiviso generata nel campo storageAccountSasToken. Rimuovere il punto interrogativo iniziale (?).

sinksConfig

"sinksConfig": {
    "sink": [
        {
            "name": "sinkname",
            "type": "sinktype",
            ...
        },
        ...
    ]
},

La sezione facoltativa sinksConfig definisce più destinazioni a cui l'estensione invia informazioni raccolte. L'array "sink" contiene un oggetto per ogni sink di dati aggiuntivo. L'attributo "type" determina gli altri attributi dell'oggetto.

L'estensione di diagnostica Linux 4.0 supporta due tipi di sink protetti: EventHub e JsonBlob.

Sink EventHub

"sink": [
    {
        "name": "sinkname",
        "type": "EventHub",
        "sasURL": "https SAS URL"
    },
    ...
]

La voce "sasURL" contiene l'URL completo, incluso il token di firma di accesso condiviso, per l'hub eventi in cui devono essere pubblicati i dati. LAD richiede una firma di accesso condiviso per denominare un criterio che abilita l'attestazione di invio. Ecco un esempio:

• Creare uno spazio dei nomi dell'Hub eventi denominato contosohub.
• Creare un hub eventi nello spazio dei nomi denominato syslogmsgs.
• Creare un criterio di accesso condiviso nell'hub eventi denominato writer che consenta l'attestazione di trasmissione.

Se si crea una SAS valida fino alla mezzanotte UTC del 1° gennaio 2018, il valore sasURL potrebbe essere simile all'esempio seguente.

https://contosohub.servicebus.windows.net/syslogmsgs?sr=contosohub.servicebus.windows.net%2fsyslogmsgs&sig=xxxxxxxxxxxxxxxxxxxxxxxxx&se=1514764800&skn=writer

Per altre informazioni sulla generazione e il recupero di informazioni sui token SAS per Hub eventi, vedere Generare un token SAS.

Sink JsonBlob

"sink": [
    {
        "name": "sinkname",
        "type": "JsonBlob"
    },
    ...
]

I dati indirizzati a un sink JsonBlob vengono memorizzati nei BLOB dell'Archiviazione di Azure. Ogni istanza di LAD crea un BLOB all'ora per ogni nome di sink. Ciascun BLOB contiene sempre un array JSON sintatticamente valida degli oggetti. Le nuove voci vengono aggiunte in modo atomico alla matrice.

I BLOB vengono archiviati in un contenitore con lo stesso nome del sink. Le regole di Archiviazione di Azure per i nomi dei contenitori BLOB si applicano ai nomi dei sink JsonBlob. I nomi devono avere una lunghezza compresa tra 3 e 63 caratteri ASCII alfanumerici o trattini.

Impostazioni pubbliche

La struttura delle impostazioni pubbliche contiene vari blocchi di impostazioni che controllano le informazioni raccolte dall'estensione. Ogni impostazione, ad eccezione di ladCfg, è facoltativa. Se si specifica la raccolta di metriche o syslog in ladCfg, è anche necessario specificare StorageAccount. È necessario specificare l'elemento sinksConfig per abilitare il sink di Monitoraggio di Azure per le metriche da LAD 4.0.

{
    "ladCfg":  { ... },
    "fileLogs": { ... },
    "StorageAccount": "the storage account to receive data",
    "sinksConfig": { ... },
    "mdsdHttpProxy" : ""
}

Le sezioni seguenti forniscono informazioni dettagliate sugli elementi rimanenti.

ladCfg

"ladCfg": {
    "diagnosticMonitorConfiguration": {
        "eventVolume": "Medium",
        "metrics": { ... },
        "performanceCounters": { ... },
        "syslogEvents": { ... }
    },
    "sampleRateInSeconds": 15
}

La struttura ladCfg controlla la raccolta di metriche e log per l'invio al servizio Metriche di Monitoraggio di Azure e ad altri dati sink. Specificare performanceCounters o syslogEvents o entrambi. Specificare anche la struttura metrics.

Se non si desidera abilitare la raccolta di metriche o syslog, specificare una struttura vuota per l'elemento ladCfg :

"ladCfg": {
    "diagnosticMonitorConfiguration": {}
}

Metriche

"metrics": {
    "resourceId": "/subscriptions/...",
    "metricAggregation" : [
        { "scheduledTransferPeriod" : "PT1H" },
        { "scheduledTransferPeriod" : "PT5M" }
    ]
}

Gli esempi delle metriche specificate nella sezione performanceCounters vengono raccolti ogni 15 secondi o alla frequenza di esempio definita in modo esplicito per il contatore. Se vengono visualizzate più frequenze scheduledTransferPeriod, come illustrato nell'esempio, ogni aggregazione viene calcolata in modo indipendente.

performanceCounters

"performanceCounters": {
    "sinks": "",
    "performanceCounterConfiguration": [
        {
            "type": "builtin",
            "class": "Processor",
            "counter": "PercentIdleTime",
            "counterSpecifier": "/builtin/Processor/PercentIdleTime",
            "condition": "IsAggregate=TRUE",
            "sampleRate": "PT15S",
            "unit": "Percent",
            "annotation": [
                {
                    "displayName" : "cpu idle time",
                    "locale" : "en-us"
                }
            ]
        }
    ]
}

La sezione facoltativa performanceCounters consente di controllare la raccolta delle metriche. Gli esempi non elaborati vengono aggregati per ogni scheduledTransferPeriod al fine di produrre questi valori:

• Media
• Minimo
• Massimo
• Ultimo valore raccolto
• Numero di esempi non elaborati usati per calcolare l'aggregazione

counterSpecifier è un identificatore arbitrario. Gli utenti di metriche, quali le funzionalità dei grafici del portale di Azure e gli avvisi, usano counterSpecifier come la chiave che identifica una metrica o un'istanza di una metrica.

Per le metriche builtin, è consigliabile usare i valori counterSpecifier che iniziano con /builtin/. Per raccogliere un'istanza specifica di una metrica, allegare l'identificatore dell'istanza al valore counterSpecifier. Di seguito sono riportati alcuni esempi.

• /builtin/Processor/PercentIdleTime. Tempo di inattività medio calcolato per tutte le CPU virtuali
• /builtin/Disk/FreeSpace(/mnt). Spazio disponibile per il file system /mnt
• /builtin/Disk/FreeSpace. Spazio libero medio calcolato per tutti i file system montati

LAD e il portale di Azure non prevedono che il valore counterSpecifier corrisponda a qualsiasi criterio. Essere coerenti nel modo in cui si creano valori counterSpecifier.

Quando si specifica performanceCounters, LAD scrive sempre i dati in una tabella in Archiviazione di Azure. Gli stessi dati possono essere scritti in BLOB JSON o in Hub eventi o in entrambi. Non è possibile disabilitare l'archiviazione dei dati in una tabella.

Tutte le istanze di LAD che usano lo stesso nome ed endpoint per l'account di archiviazione aggiungono le metriche e i log alla stessa tabella. Se troppe VM scrivono nella stessa partizione di tabella, Azure può limitare le scritture per tale partizione.

L'impostazione eventVolume fa in modo che le voci si diffondano tra 1 (piccola), 10 (medie) o 100 (grandi) partizioni differenti. In genere, le partizioni medie sono sufficienti per evitare la limitazione delle richieste di traffico.

La funzionalità Metriche di Monitoraggio di Azure del portale di Azure usa i dati in questa tabella per creare grafici o per attivare gli avvisi. Il nome della tabella è la concatenazione delle stringhe seguenti:

• WADMetrics
• "scheduledTransferPeriod" per i valori aggregati inseriti nella tabella
• P10DV2S
• Una data nel formato AAAAMMGG, che cambia ogni 10 giorni

Gli esempi includono WADMetricsPT1HP10DV2S20170410 e WADMetricsPT1MP10DV2S20170609.

syslogEvents

"syslogEvents": {
    "sinks": "",
    "syslogEventConfiguration": {
        "facilityName1": "minSeverity",
        "facilityName2": "minSeverity",
        ...
    }
}

La sezione facoltativa syslogEvents consente di controllare la raccolta degli eventi di SysLog. Se la sezione viene omessa, gli eventi di SysLog non vengono acquisiti.

La raccolta syslogEventConfiguration ha una voce per ogni struttura di interesse di SysLog. Se minSeverity è "NONE" per una particolare struttura o se tale struttura non viene visualizzata nell'elemento, non viene acquisito alcun evento da tale struttura.

Quando si specifica syslogEvents, LAD scrive sempre i dati in una tabella di Archiviazione di Azure denominata LinuxSyslogVer2v0. Gli stessi dati possono essere scritti in BLOB JSON o in Hub eventi o in entrambi. Non è possibile disabilitare l'archiviazione dei dati in una tabella.

sinksConfig

La sezione sinksConfig pubblica facoltativa consente l'invio di metriche al sink di Monitoraggio di Azure oltre all'account di archiviazione e alla visualizzazione metriche guest predefinite.

  "sinksConfig": {
    "sink": [
      {
        "name": "AzMonSink",
        "type": "AzMonSink",
        "AzureMonitor": {}
      }
    ]
  },

fileLogs

La sezione fileLogs controlla l'acquisizione dei file di log. LAD acquisisce nuove righe di testo mentre vengono scritte nel file. Le scrive in righe di tabella e in tutti i sink specificati, ad esempio JsonBlob e EventHub.

"fileLogs": [
    {
        "file": "/var/log/mydaemonlog",
        "table": "MyDaemonEvents",
        "sinks": ""
    }
]

È necessario specificare "table" o "sinks" o entrambi.

Metriche supportate dal provider Builtin

Le metriche predefinite supportate da LAD vengono aggregate in tutti i file system, i dischi o i nomi. Per le metriche non aggregate, vedere il supporto delle metriche sink di Monitoraggio di Azure più recente.

Il provider di metriche builtin è un'origine di metriche più interessante per molti utenti. Queste metriche sono suddivise in cinque grandi categorie:

• Processore
• Memoria
• Network
• File system
• Disco

Metriche Builtin per la classe Processore

La classe di metriche Processore offre informazioni sull'uso del processore nella macchina virtuale. Quando le percentuali vengono aggregate, il risultato è la media tra tutte le CPU.

In una VM a due vCPU, se una vCPU è per il 100% occupata e l'altra è per il 100% inattiva, il PercentIdleTime segnalato è 50. Se ogni vCPU è occupata per il 50% per lo stesso periodo, anche il risultato segnalato è 50. In una VM a quattro vCPU, quando una vCPU è per il 100% occupata e le altre sono inattive, il PercentIdleTime segnalato è 75.

La somma dei primi quattro contatori deve essere 100 percento. Anche la somma degli ultimi tre contatori deve essere 100 percento. Questi tre contatori suddividono la somma di PercentProcessorTime, PercentIOWaitTime e PercentInterruptTime.

Metriche Builtin per la classe Memoria

La classe di memoria delle metriche contiene informazioni sull'uso della memoria, il paging e lo scambio.

Questa classe di metriche ha una sola istanza. L'attributo "condition" non presenta impostazioni utili e deve essere omesso.

Metriche Builtin per la classe Rete

La classe di metriche Rete contiene informazioni sulle attività di rete su un interfacce di rete singole sin dall'avvio.

LAD non espone le metriche della larghezza di banda. È possibile ottenere queste metriche dalle metriche host.

Metriche Builtin per la classe File system

La classe di metriche File system contiene informazioni sull'uso del File system. I valori assoluti e in percentuale vengono segnalati come sarebbero visualizzati da un utente normale, non radice.

Metriche Builtin per la classe Disco

La classe di metriche Disco contiene informazioni sull'uso del dispositivo del disco. Queste statistiche si applicano all'intera unità.

Quando un dispositivo contiene diversi File system, i contatori per il dispositivo sono aggregati in modo efficace in tutti i File system.

Configurazione di LAD 4.0 di esempio

In base alle definizioni precedenti, questa sezione fornisce una configurazione dell'estensione LAD 4.0 di esempio e una spiegazione. Per applicare questo esempio, usare il proprio nome dell'account di archiviazione, il token SAS dell'account e i token SAS di Hub eventi.

Configurazione delle impostazioni protette

Le impostazioni protette configurano:

• Un account di archiviazione.
• Token di firma di accesso condiviso dell'account corrispondente.
• Diversi sink: JsonBlob o EventHub con token SAS.

{
  "storageAccountName": "yourdiagstgacct",
  "storageAccountSasToken": "sv=xxxx-xx-xx&ss=bt&srt=co&sp=wlacu&st=yyyy-yy-yyT21%3A22%3A00Z&se=zzzz-zz-zzT21%3A22%3A00Z&sig=fake_signature",
  "sinksConfig": {
    "sink": [
      {
        "name": "SyslogJsonBlob",
        "type": "JsonBlob"
      },
      {
        "name": "FilelogJsonBlob",
        "type": "JsonBlob"
      },
      {
        "name": "LinuxCpuJsonBlob",
        "type": "JsonBlob"
      },
      {
        "name": "MyJsonMetricsBlob",
        "type": "JsonBlob"
      },
      {
        "name": "LinuxCpuEventHub",
        "type": "EventHub",
        "sasURL": "https://youreventhubnamespace.servicebus.windows.net/youreventhubpublisher?sr=https%3a%2f%2fyoureventhubnamespace.servicebus.windows.net%2fyoureventhubpublisher%2f&sig=fake_signature&se=1808096361&skn=yourehpolicy"
      },
      {
        "name": "MyMetricEventHub",
        "type": "EventHub",
        "sasURL": "https://youreventhubnamespace.servicebus.windows.net/youreventhubpublisher?sr=https%3a%2f%2fyoureventhubnamespace.servicebus.windows.net%2fyoureventhubpublisher%2f&sig=yourehpolicy&skn=yourehpolicy"
      },
      {
        "name": "LoggingEventHub",
        "type": "EventHub",
        "sasURL": "https://youreventhubnamespace.servicebus.windows.net/youreventhubpublisher?sr=https%3a%2f%2fyoureventhubnamespace.servicebus.windows.net%2fyoureventhubpublisher%2f&sig=yourehpolicy&se=1808096361&skn=yourehpolicy"
      }
    ]
  }
}

Configurazione delle impostazioni pubbliche

Con le impostazioni pubbliche il LAD:

• Caricare le metriche della percentuale di tempo del processore e dello spazio sul disco usato nella tabella WADMetrics*.
• Caricare messaggi dalla struttura syslog "user" e dalla gravità "info" nella tabella LinuxSyslog*.
• Caricare le righe aggiunte nel file /var/log/myladtestlog nella tabella MyLadTestLog.

In ogni caso, i dati vengono anche caricati:

• Archiviazione BLOB di Azure. Il nome del contenitore è definito nel sink JsonBlob.
• Un endpoint di Hub eventi, come specificato nel sink EventHub.

{
  "StorageAccount": "yourdiagstgacct",
  "ladCfg": {
    "sampleRateInSeconds": 15,
    "diagnosticMonitorConfiguration": {
      "performanceCounters": {
        "sinks": "MyMetricEventHub,MyJsonMetricsBlob",
        "performanceCounterConfiguration": [
          {
            "unit": "Percent",
            "type": "builtin",
            "counter": "PercentProcessorTime",
            "counterSpecifier": "/builtin/Processor/PercentProcessorTime",
            "annotation": [
              {
                "locale": "en-us",
                "displayName": "cpu percentage guest os"
              }
            ],
            "condition": "IsAggregate=TRUE",
            "class": "Processor"
          },
          {
            "unit": "Bytes",
            "type": "builtin",
            "counter": "UsedSpace",
            "counterSpecifier": "/builtin/FileSystem/UsedSpace",
            "annotation": [
              {
                "locale": "en-us",
                "displayName": "Used disfilesystem used space"
              }
            ],
            "condition": "Name=\"/\"",
            "class": "Filesystem"
          }
        ]
      },
      "metrics": {
        "metricAggregation": [
          {
            "scheduledTransferPeriod": "PT1H"
          },
          {
            "scheduledTransferPeriod": "PT1M"
          }
        ],
        "resourceId": "/subscriptions/your_azure_subscription_id/resourceGroups/your_resource_group_name/providers/Microsoft.Compute/virtualMachines/your_vm_name"
      },
      "eventVolume": "Large",
      "syslogEvents": {
        "sinks": "SyslogJsonBlob,LoggingEventHub",
        "syslogEventConfiguration": {
          "LOG_USER": "LOG_INFO"
        }
      }
    }
  },
  "sinksConfig": {
    "sink": [
      {
        "name": "AzMonSink",
        "type": "AzMonSink",
        "AzureMonitor": {}
      }
    ]
  },
  "fileLogs": [
    {
      "file": "/var/log/myladtestlog",
      "table": "MyLadTestLog",
      "sinks": "FilelogJsonBlob,LoggingEventHub"
    }
  ]
}

Nella configurazione resourceId deve corrispondere al valore della VM o del Set di scalabilità di macchine virtuali.

• I valori di resourceId della VM in funzione sono noti a grafici e avvisi relativi alle metriche della piattaforma di Azure. Si prevede di trovare i dati per la macchina virtuale usando resourceId come chiave di ricerca.
• Se si usa la scalabilità automatica di Azure, resourceId nella configurazione di scalabilità automatica deve corrispondere a resourceId usato da LAD.
• Il valore di resourceId viene creato nei nomi di BLOB JSON scritti da LAD.

Visualizzare i dati

Usare il portale di Azure per visualizzare i dati sulle prestazioni o impostare gli avvisi:

I dati performanceCounters sono sempre archiviati in una tabella di Archiviazione di Azure. Le API di Archiviazione di Azure sono disponibili per più linguaggi e piattaforme.

I dati inviati ai sink JsonBlob sono archiviati nei BLOB nell'account di archiviazione indicato in Impostazioni protette. È possibile usare i dati BLOB in qualsiasi API di archiviazione BLOB di Azure.

È anche possibile usare questi strumenti dell'interfaccia utente per accedere ai dati nell'Archiviazione di Azure:

• Esplora server di Visual Studio.
• Azure Storage Explorer

Lo screenshot seguente di una sessione di Microsoft Azure Storage Explorer mostra le tabelle di Archiviazione di Azure e i contenitori generati da un'estensione LAD 4.0 correttamente configurata su una macchina virtuale di test. L'immagine non corrisponde esattamente alla configurazione LAD 4.0 di esempio.

Per altre informazioni su come usare i messaggi pubblicati in un endpoint di Hub eventi, vedere la documentazione di Hub eventi pertinente.

Passaggi successivi

• In Monitoraggio di Azure creare avvisi per le metriche raccolte.
• Creare grafici di monitoraggio per le metriche.
• Creare un Set di scalabilità di macchine virtuali con le metriche per controllare la scalabilità automatica.