Freigeben über

Aggregation of OMS Data from across Azure Subscriptions

  • Artikel

An Operations Management Suite (OMS) Repository can be associated to a single Azure Subscription. Companies that host their Products on separate per-tenant Azure Subscription for their Customers have this need to consolidate the Health data from all these Subscriptions for ease of monitoring and tracking. OMS provides the ability to configure Alerts that would call a Web Hook configured on a Central Incident Management System. The IT Support Team could then track and diagnose issues in their  Solution deployment. However, when there are no such Systems implemented, an alternative approach would be to host a Common OMS Workspace to which the individual, per tenant Workspaces would send the Health data to, using the Data Collector APIs.

Aggregation of Heartbeat data from Compute Resources in Azure

The PowerShell script VMsHeartbeatAggregator.ps1 that implements the aggregation logic is called from an Azure Runbook. The Runbook executes under an Azure Automation Account and has a scheduler configured to recurrently trigger the PowerShell script.

The PowerShell script executes a Dynamic Query on OMS to retrieve aggregated Heartbeat Data from the VMs and VMSS deployed in that Subscription. This data is then pushed to the Common OMS Workspace using the Data Collector API. This Runbook would be deployed in each of the Azure Subscriptions and the data captured from these OMS Workspaces is aggregated to a single, common OMS Workspace.

The Data Collector API (REST API) does not insert or update data into the Record Types that OMS provides by default, namely Heartbeat, Event, etc. It is required to create a custom Record Type into which the data is pushed using the API. Assign different Record Type names in the Common OMS Workspace corresponding to each Source OMS Workspaces that sends the data.

View Designer and Custom Views can be used to create the Dashboard in the common OMS Workspace, one for each Source OMS Workspace. Provide hyperlinks in these Dashboards back to the Dashboards in the respective Source OMS Workspace. This lets the Help Desk Team drill down into the raw data in the Source Subscriptions to investigate an issue.

The PowerShell scripts used to implement this scenario can be downloaded from the GitHub Repository here It is based on the elaborate guidance on the invocation of the Data Collector API using PowerShell, which is covered in the Documentation here

The key steps to be performed to implement this scenario are:

  • Configure a Log Analytics Resource and add the VMs and VMSS Resources to be monitored to it. An OMS Workspace corresponding to the Log Analytics Resource is created where the Heartbeat information is sent to. Refer to the Azure documentation here to get started
  • Create an Azure Automation Account from the Azure Portal
  • Within the Automation Account, navigate to Runbooks> Add a new Runbook
  • Edit the runbook and paste the PowerShell script from VMsHeartbeatAggregator.ps1 into it

To execute this script, certain PowerShell Modules need to be imported first, as shown in the screenshot below. At the prompt, acknowledge the installation of the Dependent Modules as well.

  • Add a Scheduler to the Runbook created above. Since the PowerShell script uses input parameters, the Scheduler configuration form would prompt for these values. In the scenario implemented here, the input parameters used are:

[Parameter (Mandatory=$true)]
[String] $ResourceGroupName,    -> Resource Group that contains the VMs and VMSS being monitored
[Parameter (Mandatory=$true)]
[String] $WorkspaceName,   -> Source OMS Workspace Name where the Heartbeat data is queried upon
[Parameter (Mandatory=$true)]
[String] $CustomerName,     # e.g. CustomerX for whom the solution is deployed
[Parameter (Mandatory=$true)]
[String] $EnviromentName     # e.g. staging

The values of $CustomerName and $EnvironmentName are concatenated to form the name of the Record Type created in the Common OMS Workspace.

In the PowerShell script, set the values of the following variable pertaining to the Target Common OMS Workspace

# This is the Unique identifier of the Common Workspace in OMS
$CustomerId = "[Enter the Common OMS Workspace ID]"

# The access key to connect to the common OMS Workspace
$SharedKey = "[Enter the Access key required to invoke the Data Collector API on the common OMS Workspace]"

These values can be obtained from the OMS Workspace Data Source Settings Page, as shown in the screenshot below

  • Execute the Runbook manually, or use the Scheduler to trigger it. View the Console output and ensure that there are no errors.
  • Navigate to the Common OMS Workspace and use Log Search to view the data inserted using the Data Collector API. Note that the Record Type name is suffixed with _CL by the API. See Screenshot below.

 

  • Likewise execute the Runbook in each of the Source Subscriptions and push the data to the corresponding Record Type in the Common OMS Workspace.
  • Use View Designer or Custom Views in the Common OMS Workspace to create a Dashboard for data inserted for each Record Type

Azure Web App Monitoring with Alerts

The PowerShell script WebAppHealthcheckRunbook.ps1 in this sample is deployed in a Runbook that exposes a Web hook.

  • An Azure Application Insight Resource is configured to execute Web App URL Ping Tests
  • When the outcome is a failure an Alert can be raised which would call the Web hook configured for the Runbook and pass the details like the Web App Name, Resource Name, etc to it
  • The Power Shell script would then invoke the Data Collector API of the common OMS Workspace and insert the Ping Test result data into a custom Record Type

Guidance on working with Webhook in a Runbook is covered in the Azure Documentation Link here 

The screenshot below shows how Application Insights can be configured to execute Ping Health Checks on a Web App, and how an Alert could be configured to invoke the Webhook exposed by a Runbook.