It’s no mystery I’m currently working more and more with Microsoft OMS (OMS), a lot of key new features are added on a weekly basis and more and more are coming. Still, we as a managed service provider and our customers have a huge investment in System Center Operations Manager (OpsMgr). The goal is to get the best from both worlds and integrate them as one, actually the products are integrated in many ways and OMS is a natural extension for OpsMgr:
- far better security management (log consolidation, update assessment, malware assessment, threats analytics, …)
- ability to analyze and correlate
- ability to consolidate a huge amount of data, an amount that’s simply too expensive or simply technically out of reach with an on premises implementation
- AD, SQL insights
- Application dependency discovery
- and many more
On the other side OMS is still far from the breadth of monitoring, especially in terms of proactive and reactive alerting capabilities, that OpsMgr acquired during the years from both Microsoft, third parties and community contributions.
With this headsup post I just want to share the approach we took to leverage the wo solutions as one and being able to give our operators a single console for alerting management.
We choose to keep OpsMgr as our alerting console, there are many reasons that drove our decision:
- Even if OpsMgr alerts can be ingested into OMS they’re not actionable in OMS
- Our operators are trained on the existing OpsMgr console
- The OpsMgr console is far more actionable that OMS is: alert status, rich knowledge base articles, tasks, integration with Service Manager incident management, integration with internal databases and notification systems, …
Obviously this can change in the future, when OMS will have alerting management.
Given this decision the challenge was to get the alert generated by OMS into OpsMgr. As you you know OMS has its own alerting mechanisms, basically given a search query you can send an email or trigger an automation action (either through Azure automation or you custom tool using a webhook).
Basically there two options for integrating those alerts:
- using the automation interface to inject alerts into OpsMgr
- using the search language to extract alerts
Both approaches have pro and cons, with automation you have a near realtime delivery and rich context status, but it’s a custom solution not easily replicated across different OpsMgr implementation; with the search language the delivery is based on the polling interval (minutes) and you lose the context information (basically the documents returned by the query that triggered the alert). In any case the context information can be retrieved if needed from the OMS portal.
With this solution you can define any alert on OMS and get the same alert in OpsMgr for proper management, the alerts are stateful, when an alert is no triggered anymore the corresponding alert on OpsMgr is closed accordingly. We’re already leveraging this solution for many scenarios where OMS has more context and data than OpsMgr.
After careful weighting we decided to go with the search language approach. We even decided to share on github the code and the management pack as a v2 of our MSOMS Management Pack for OpsMgr. You can find the first prerelease on github please consider:
- it depends on the Azure MP technical Preview
- in the preview release it implements Log Analytics monitoring and alerting integration and OMS Backup Server monitoring. I will soon add Automation and OMS Backup monitoring, while for ASR will come as soon as the REST API is consolidated.
Please add your comment on github if see any improvement that can be added.
Also consider the documentation is still in progress, we had a bad business need for this kind of integration and documentation will follow later.
This posting is provided “AS IS” with no warranties, and confers no rights