Freigeben über

Using Azure Automation, OMS and Storage Tables to capture Configuration Data of Azure VMs Part One.

  • Artikel

Many customers have legacy configuration management database (CMDB) systems that they'd like to update with Azure Virtual Machine configuration data like hostname, IP address, subscription, etc. Part one of this blog will review how to capture this information to an Azure Storage table each time a virtual machine is created. Subsequent parts will cover virtual machine changes and deletes.

At a high level:
1. Azure Activity Logs are being sent to OMS Log Analytics
2. OMS sends an Alert Webhook to Azure Automation on each vm creation event
3. Azure Automation executes a runbook that captures the VM information and writes into Azure Storage Tables
4. An on-premises process picks up the data and writes it into the legacy CMDB (this part is not covered in this or subsequent blog posts).

The first step is well documented here so I won't belabor the point.

The next step is also well documented. Remember that your Azure Automation Account and OMS Workspace must be in the same resource group.
Link

Step three requires a few things. First, the Azure Automation must parse the JSON it is receiving from OMS/Webhook. My coworker Rob Davies has an excellent blog post about this process here and you can also see the example I've used in the runbook. Once the runbook has parsed the JSON it needs to get the configuration information for the VM - this uses regular Azure PowerShell like get-azurermvm. Finally, the runbook needs to write this data to an Azure Storage Table. For this I leaned (or plagiarized?) another coworker Paulo Marques da Costa who wrote a very handy Powershell module for working with tables. This module is available in the gallery and must be imported into the Automation Account. I would recommend updating all PowerShell modules in the automation account as well as adding the AzureRM.Network module.

You'll notice a couple odd logic sections in the runbook as well. The first "foreach ($v in $cmdata.searchresults.value)" is there because OMS only alerts once every five minutes. If you create 10 VMs in 2 minutes, they'll come through in a single alert with multiple values in the request body.

The next logic workaround is because there may be several virtual machine write operations in the activity log on a single VM creation operation. The logic after the comment "#search the storage table to see if the VM already exists" checks to see if the resourceID is already in the storage table, and if so, records it as a VM Update.

This is definitely a continuing effort so I'm not posting the PowerShell here as it'll see quite a few updates. The runbook solution can be found on GitHub.

Comments

  • Anonymous
    August 22, 2017
    Nice work John!