Use the Linux diagnostic extension 4.0 to monitor metrics and logs

This article describes the latest versions of the Linux diagnostic extension (LAD).

The Linux diagnostic extension helps you monitor the health of a Linux VM on Azure. It has the following capabilities:

This extension works with both Azure deployment models: Azure Resource Manager and classic.

Prerequisites

• Azure Linux agent version 2.2.0 or later. Most Azure VM Linux gallery images include version 2.2.7 or later. Run /usr/sbin/waagent -version to confirm the version installed on the VM. If the VM runs an older version of the guest agent, update the Linux agent.
• Azure CLI. Set up the Azure CLI environment on your machine.
• The wget command. If you don't already have it, install it using the corresponding package manager.
• An Azure subscription and general purpose storage account to store the data. General purpose storage accounts support table storage, which is required. A blob storage account doesn't work.
• Python 2.

Supported Linux distributions

See Supported agent operating systems.

Python requirement

The Linux diagnostic extension requires Python 2. If your virtual machine uses a distribution that doesn't include Python 2, install it.

To install Python 2, run one of the following sample commands:

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

The python2 executable file must be aliased to python.

1. Run the following command to remove any existing aliases.

   sudo update-alternatives --remove-all python
   

2. Run the following command to create the new alias.

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

Install the extension

You can enable this extension for your VM and Virtual Machine Scale Set by using the Azure PowerShell cmdlets, Azure CLI scripts, Azure Resource Manager templates (ARM templates), or the Azure portal. For more information, see Virtual machine extensions and features for Linux.

Use the installation instructions and a downloadable sample configuration to configure LAD 4.0 to:

• Capture and store the same metrics that LAD versions 2.3 and 3.x provided.
• Send metrics to the Azure Monitor sink along with the usual sink to Azure Storage. This functionality is new in LAD 4.0.
• Capture a useful set of file system metrics, as in LAD 3.0.
• Capture the default syslog collection enabled by LAD 2.3.
• Enable the Azure portal experience for charting and alerting on VM metrics.

The downloadable configuration is just an example. Modify it to suit your needs.

Installation

You can install and configure LAD 4.0 in the Azure CLI or 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

Sample installation

In these examples, the sample configuration collects a set of standard data and sends it to table storage. The URL for the sample configuration and its contents can change.

In most cases, you should download a copy of the portal settings JSON file and customize it for your needs. Use templates or your own automation to use a customized version of the configuration file rather than downloading from the URL each time.

When you enable the new Azure Monitor sink, the VMs need to have system-assigned identity enabled to generate Managed Service Identity (MSI) authentication tokens. You can add these settings during or after VM creation. For instructions for the Azure portal, the Azure CLI, PowerShell, and Azure Resource Manager, see Configure managed identities.

# 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>
my_diagnostic_storage_endpoint="https://core.chinacloudapi.cn/"

# Login to Azure before you do anything else.
az cloud set -n AzureChinaCloud
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', 'storageAccountEndPoint': '$my_diagnostic_storage_endpoint'}"

# 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"
$storageAccountEndPoint = "https://core.chinacloudapi.cn/"
$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', 'storageAccountEndPoint': '$my_diagnostic_storage_endpoint'}"

# 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

Installation sample for Virtual Machine Scale Sets - Azure CLI

# 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>
my_diagnostic_storage_endpoint="https://core.chinacloudapi.cn/"

# Login to Azure before you do anything else.
az cloud set -n AzureChinaCloud
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', 'storageAccountEndPoint': '$my_diagnostic_storage_endpoint'}"

# 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

Update the extension settings

After you change your protected or public settings, run the same command to deploy them to the VM. If any settings changed, the updates are sent to the extension. LAD reloads the configuration and restarts itself.

Migrate from previous versions of the extension

The latest version of the extension is 4.0, which is currently in public preview. Older versions of 3.x are still supported. 2.x versions have been deprecated since July 31, 2018.

When you install the new extension, enable automatic minor version upgrades:

• On Azure Resource Manager deployment model VMs, include "autoUpgradeMinorVersion": true in the VM deployment template.
• On classic deployment model VMs, specify version 4.* if you're installing the extension through the Azure CLI or PowerShell.

You can use the same storage account you used for LAD 3.x.

Protected settings

This set of configuration information contains sensitive information that should be protected from public view. It contains, for example, storage credentials. The settings are transmitted to the extension, which stores them in encrypted form.

{
    "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": { ... }
}

To get a SAS token within an ARM template, use the listAccountSas function. For an example template, see List function example.

You can construct the required shared access signature token through the Azure portal:

1. Select the general-purpose storage account to which you want the extension to write.
2. In the menu on the left, under Security + networking, select Shared access signature.
3. Make the selections as previously described.
4. Select Generate SAS and connection string.

Copy the generated shared access signature into the storageAccountSasToken field. Remove the leading question mark (?).

sinksConfig

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

The sinksConfig optional section defines more destinations to which the extension sends collected information. The "sink" array contains an object for each extra data sink. The "type" attribute determines the other attributes in the object.

The Linux diagnostic extension 4.0 supports two protected sink types: EventHub and JsonBlob.

EventHub sink

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

The "sasURL" entry contains the full URL, including the shared access signature token, for the event hub to which data should be published. LAD requires a shared access signature to name a policy that enables the send claim. Here's an example:

• Create an Event Hubs namespace called contosohub.
• Create an event hub in the namespace called syslogmsgs.
• Create a shared access policy on the event hub named writer that enables the send claim.

If you create a SAS that's good until midnight UTC on January 1, 2018, the sasURL value might be like the following example.

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

For more information about generating and retrieving information on SAS tokens for Event Hubs, see Generate a SAS token.

JsonBlob sink

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

Data directed to a JsonBlob sink is stored in blobs in Azure Storage. Each instance of LAD creates a blob every hour for each sink name. Each blob always contains a syntactically valid JSON array of objects. New entries are atomically added to the array.

Blobs are stored in a container that has the same name as the sink. The Azure Storage rules for blob container names apply to the names of JsonBlob sinks. Names must have between 3 and 63 lowercase alphanumeric ASCII characters or dashes.

Public settings

The public settings structure contains various blocks of settings that control the information that the extension collects. Each setting, except ladCfg, is optional. If you specify metric or syslog collection in ladCfg, you must also specify StorageAccount. You must specify the sinksConfig element to enable the Azure Monitor sink for metrics from LAD 4.0.

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

The following sections provide details about the remaining elements.

ladCfg

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

The ladCfg structure controls the gathering of metrics and logs for delivery to the Azure Monitor Metrics service and to other data sinks. Specify either performanceCounters or syslogEvents or both. Also specify the metrics structure.

If you don't want to enable syslog or metrics collection, specify an empty structure for the ladCfg element:

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

metrics

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

Samples of the metrics specified in the performanceCounters section are collected every 15 seconds or at the sample rate explicitly defined for the counter. If multiple scheduledTransferPeriod frequencies appear, as in the example, each aggregation is computed independently.

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

The performanceCounters optional section controls the collection of metrics. Raw samples are aggregated for each scheduledTransferPeriod to produce these values:

• Mean
• Minimum
• Maximum
• Last-collected value
• Count of raw samples used to compute the aggregate

The counterSpecifier is an arbitrary identifier. Consumers of metrics, like the Azure portal charting and alerting feature, use counterSpecifier as the key that identifies a metric or an instance of a metric.

For builtin metrics, we recommend counterSpecifier values that begin with /builtin/. To collect a specific instance of a metric, attach the identifier of the instance to the counterSpecifier value. Here are some examples:

• /builtin/Processor/PercentIdleTime. Idle time averaged across all vCPUs
• /builtin/Disk/FreeSpace(/mnt). Free space for the /mnt file system
• /builtin/Disk/FreeSpace. Free space averaged across all mounted file systems

LAD and the Azure portal don't expect the counterSpecifier value to match any pattern. Be consistent in how you construct counterSpecifier values.

When you specify performanceCounters, LAD always writes data to a table in Azure Storage. The same data can be written to JSON blobs or Event Hubs or both. You can't disable storing data to a table.

All instances of LAD that use the same storage account name and endpoint add their metrics and logs to the same table. If too many VMs write to the same table partition, Azure can throttle writes to that partition.

The eventVolume setting causes entries to be spread across 1 (small), 10 (medium), or 100 (large) partitions. Usually, medium partitions are sufficient to avoid traffic throttling.

The Azure Monitor Metrics feature of the Azure portal uses the data in this table to produce graphs or to trigger alerts. The table name is the concatenation of these strings:

• WADMetrics
• The "scheduledTransferPeriod" for the aggregated values stored in the table
• P10DV2S
• A date, in the form YYYYMMDD, which changes every 10 days

Examples include WADMetricsPT1HP10DV2S20170410 and WADMetricsPT1MP10DV2S20170609.

syslogEvents

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

The syslogEvents optional section controls the collection of log events from syslog. If the section is omitted, syslog events aren't captured at all.

The syslogEventConfiguration collection has one entry for each syslog facility of interest. If minSeverity is "NONE" for a particular facility, or if that facility doesn't appear in the element at all, no events from that facility are captured.

When you specify syslogEvents, LAD always writes data to a table named LinuxSyslogVer2v0 in Azure Storage. The same data can be written to JSON blobs or Event Hubs or both. You can't disable storing data to a table.

sinksConfig

The optional public sinksConfig section enables sending metrics to the Azure Monitor sink in addition to the Storage account and the default Guest Metrics view.

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

fileLogs

The fileLogs section controls the capture of log files. LAD captures new text lines as they're written to the file. It writes them to table rows and any specified sinks, such as JsonBlob and EventHub.

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

Either "table" or "sinks" or both must be specified.

Metrics supported by the builtin provider

The default metrics that LAD supports are aggregated across all file systems, disks, or names. For nonaggregated metrics, refer to the newer Azure Monitor sink metrics support.

The builtin metric provider is a source of metrics that are the most interesting to a broad set of users. These metrics fall into five broad classes:

• Processor
• Memory
• Network
• File system
• Disk

builtin metrics for the Processor class

The Processor class of metrics provides information about processor usage in the VM. When percentages are aggregated, the result is the average across all CPUs.

In a two-vCPU VM, if one vCPU is 100 percent busy and the other is 100 percent idle, the reported PercentIdleTime is 50. If each vCPU is 50 percent busy for the same period, the reported result is also 50. In a four-vCPU VM, when one vCPU is 100 percent busy and the others are idle, the reported PercentIdleTime is 75.

The first four counters should sum to 100 percent. The last three counters also sum to 100 percent. These three counters subdivide the sum of PercentProcessorTime, PercentIOWaitTime, and PercentInterruptTime.

builtin metrics for the Memory class

The Memory class of metrics provides information about memory use, paging, and swapping.

This class of metrics has only one instance. The "condition" attribute has no useful settings and should be omitted.

builtin metrics for the Network class

The Network class of metrics provides information about network activity on an individual network interface since the startup.

LAD doesn't expose bandwidth metrics. You can get these metrics from host metrics.

builtin metrics for the File system class

The File system class of metrics provides information about file system usage. Absolute and percentage values are reported as they would be displayed to an ordinary user, not root.

builtin metrics for the Disk class

The Disk class of metrics provides information about disk device usage. These statistics apply to the entire drive.

When a device has multiple file systems, the counters for that device are, effectively, aggregated across all file systems.

Example LAD 4.0 configuration

Based on the preceding definitions, this section provides a sample LAD 4.0 extension configuration and some explanation. To apply this sample, use your own storage account name, account shared access signature token, and Event Hubs SAS tokens.

Protected settings configuration

The protected settings configure:

• A storage account.
• Storage account endpoint.
• A matching account shared access signature token.
• Several sinks: JsonBlob or EventHub with SAS tokens.

{
  "storageAccountEndPoint": "https://core.chinacloudapi.cn/",
  "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.chinacloudapi.cn/youreventhubpublisher?sr=https%3a%2f%2fyoureventhubnamespace.servicebus.chinacloudapi.cn%2fyoureventhubpublisher%2f&sig=fake_signature&se=1808096361&skn=yourehpolicy"
      },
      {
        "name": "MyMetricEventHub",
        "type": "EventHub",
        "sasURL": "https://youreventhubnamespace.servicebus.chinacloudapi.cn/youreventhubpublisher?sr=https%3a%2f%2fyoureventhubnamespace.servicebus.chinacloudapi.cn%2fyoureventhubpublisher%2f&sig=yourehpolicy&skn=yourehpolicy"
      },
      {
        "name": "LoggingEventHub",
        "type": "EventHub",
        "sasURL": "https://youreventhubnamespace.servicebus.chinacloudapi.cn/youreventhubpublisher?sr=https%3a%2f%2fyoureventhubnamespace.servicebus.chinacloudapi.cn%2fyoureventhubpublisher%2f&sig=yourehpolicy&se=1808096361&skn=yourehpolicy"
      }
    ]
  }
}

Public settings configuration

The public settings cause LAD to:

• Upload percent-processor-time metrics and used-disk-space metrics to the WADMetrics* table.
• Upload messages from syslog facility "user" and severity "info" to the LinuxSyslog* table.
• Upload appended lines in file /var/log/myladtestlog to the MyLadTestLog table.

In each case, data is also uploaded to:

• Azure Blob Storage. The container name is as defined in the JsonBlob sink.
• An Event Hubs endpoint, as specified in the EventHub sink.

{
  "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"
    }
  ]
}

The resourceId in the configuration must match that of the VM or the Virtual Machine Scale Set.

• Azure platform metrics charting and alerting knows the resourceId of the VM you're working on. It expects to find the data for your VM by using the resourceId as the lookup key.
• If you use Azure autoscale, the resourceId in the autoscale configuration must match the resourceId that LAD uses.
• The resourceId is built in to the names of JSON blobs written by LAD.

View your data

Use the Azure portal to view performance data or set alerts:

The performanceCounters data is always stored in an Azure Storage table. Azure Storage APIs are available for many languages and platforms.

Data sent to JsonBlob sinks is stored in blobs in the storage account named in the protected settings. You can consume the blob data in any Azure Blob Storage API.

You also can use these UI tools to access the data in Azure Storage:

• Visual Studio Server Explorer
• Azure Storage Explorer

The following screenshot of an Azure Storage Explorer session shows the generated Azure Storage tables and containers from a correctly configured LAD 4.0 extension on a test VM. The image doesn't exactly match the sample LAD 4.0 configuration.

For more information about how to consume messages published to an Event Hubs endpoint, see the relevant Event Hubs documentation.

Next steps

• In Azure Monitor, create alerts for the metrics you collect.
• Create monitoring charts for your metrics.
• Create a Virtual Machine Scale Set by using your metrics to control autoscaling.