Design and build a management solution in Operations Management Suite (OMS) (Preview)
This is preliminary documentation for creating management solutions in OMS which are currently in preview. Any schema described below is subject to change.
Management solutions extend the functionality of Operations Management Suite (OMS) by providing packaged management scenarios that customers can add to their OMS workspace. This article presents a basic process to design and build a management solution that is suitable for most common requirements. If you are new to building management solutions then you can use this process as a starting point and then leverage the concepts for more complex solutions as your requirements evolve.
What is a management solution?
Management solutions contain OMS and Azure resources that work together to achieve a particular monitoring scenario. They are implemented as Resource Management templates that contain details of how to install and configure their contained resources when the solution is installed.
The basic strategy is to start your management solution by building the individual components in your Azure environment. Once you have the functionality working properly, then you can start packaging them into a management solution file.
Design your solution
The most common pattern for a management solution is shown in the following diagram. The different components in this pattern are discussed in the below.
The first step in designing a solution is determining the data that you require from the Log Analytics repository. This data may be collected by a data source or another solution, or your solution may need to provide the process to collect it.
There are a number of ways data sources that can be collected in the Log Analytics repository as described in Data sources in Log Analytics. This includes events in the Windows Event Log or generated by Syslog in addition to performance counters for both Windows and Linux clients. You can also gather data from Azure resources collected by Azure Monitor.
If you require data that's not accessible through any of the available data sources, then you can use the HTTP Data Collector API which allows you to write data to the Log Analytics repository from any client that can call a REST API. The most common means of custom data collection in a management solution is to create a runbook in Azure Automation that collects the required data from Azure or external resources and uses the Data Collector API to write to the repository.
Log searches are used to extract and analyze data in the Log Analytics repository. They are used by views and alerts in addition to allowing the user to perform ad hoc analysis of data in the repository.
You should define any queries that you think will be helpful to the user even if they aren't used by any views or alerts. These will be available to them as Saved Searches in the portal, and you can also include them in a List of Queries visualization part in your custom view.
Alerts in Log Analytics identify issues through log searches against the data in the repository. They either notify the user or automatically run an action in response. You should identify different alert conditions for your application and include corresponding alert rules in your solution file.
If the issue can potentially be corrected with an automated process, then you'll typically create a runbook in Azure Automation to perform this remediation. Most Azure services can be managed with cmdlets which the runbook would leverage to perform such functionality.
If your solution requires external functionality in response to an alert, then you can use a webhook response. This allows you to call an external web service sending information from the alert.
Views in Log Analytics are used to visualize data from the Log Analytics repository. Each solution will typically contain a single view with a tile that is displayed on the user's main dashboard. The view can contain any number of visualization parts to provide different visualizations of the collected data to the user.
You create custom views using the View Designer which you can later export for inclusion in your solution file.
Create solution file
Once you've configured and tested the components that will be part of your solution, you can create your solution file. You will implement the solution components in a Resource Manager template that includes a solution resource with relationships to the other resources in the file.
Test your solution
While you are developing your solution, you will need to install and test it in your workspace. You can do this using any of the available methods to test and install Resource Manager templates.
Publish your solution
Once you have completed and tested your solution, you can make it available to customers through either the following sources.
- Azure Quickstart templates. Azure Quickstart templates is a set of Resource Manager templates contributed by the community through GitHub. You can make your solution available by following information in the contribution guide.
- Azure Marketplace. The Azure Marketplace allows you to distribute and sell your solution to other developers, ISVs, and IT professionals. You can learn how to publish your solution to Azure Marketplace at How to publish and manage an offer in the Azure Marketplace.