Little bit off the wall this one, but related none the less…
How do your users/customers request monitoring?
Do you have a form or a template that they can fill in with examples of what SCOM can do?
We are looking to build such a template, and have one in Excel at the moment which covers the most basic information such as:
Type (Service/process/log file/URL/etc)
Description (What the service/process/etc does)
Server Function (What it does as a whole)
Alerting groups (DBAs/Web/etc)
And so on…
Once we have something more solid we are looking to move it to InfoPath or SharePoint forms, or something else at least.
Basically, we are trying to minimise the initial too and fro associated with monitoring requests and to outline from the offset for the PMs and Service Managers what it is they really need to think about before coming to us.
Within our environment a standard template was created that gathers the ‘Non-Functional Requirements’ covering Availability/Capacity/Performance/Monitoring/etc. for a given application at two key points:
During its initial design and architectur
As part of any future releases (code/infrastructure/etc.)
The NFR spreadsheet is what our business teams then come to the Monitorig Services group on their requirements. We then sit with them and highlight what SCOM (or other tools we have in place) can offer to meet the need. From there a service request is raised and the bespoke monitoring it in place.
Like you I would be very interested to see what others have and don’t mind sharing a sanitised version of the spreadsheet we use for discussion if others want to trade.
I believe the common emerging theme here is being able to translate the vast amount of cool stuff SCOM can monitor into simple offerings that a customer can navigate and choose from. It’s almost as if we need SCOM Service Catalog that takes the management pack inventory, monitors, rules and other native SCOM functions and just presents this in a nice simple UI. Go in and I see a menu of what the SCOM instance an monitor from technology view and then drill dow. The plus from there is being able to opt in to monitoring for objects under my control but this is a secondary benefit.
you can build something using SharePoint, SMA / Azure Automation, the OpsMgrExtended PS module and the SharePointSDK module. I have plenty of examples on my blog: http://blog.tyang.org/tag/automating-opsmgr/
However, I don’t think it’s something you can do it very quickly, you will need to have some dev and scripting skills.
This isn’t an answer, so I’ll keep it as comment, but I wanted to flag for you the ‘export to excel’ feature in Squared Up which may help with this.
You’ll find this in any server drilldown to the right of the monitors (can’t share a screenshot here)
Unfortunately, this doesn’t get you past the fact that it’s still a very manual process, rather than self-service tuning but it does at least allow you to share what’s already in place and perhaps act as a starting point for a template
Interesting topic this. I don’t have the answer, but i may be able to contribute further down the road. Were planning something similar our self. One thing i usually do when a customer request monitoring (apart from simple url or msservice) is to draw down the whole application/system and split them in to sections like front end, back end etc. and then determinate what type of monitoring that is mandatory in these parts of the system.
Hopefully we can get a good discussion out of this
Thanks good to hear it’s worth while topic - arguably it’s against forum rules but I thought it was important enough to try!
Totally agree that if you can get some sort of design document that depicts the front and back ends etc it does make the whole thing much, much easier to envisage.
A good approach could be to group specific monitors/performance views etc and present these to the users in form of screenshots or demo dashboards and allow users to select the groups they are interested in when filling in the form. This way you could generate baseline Squared-Up dashboards based on the form data and publish it automatically (this was covered in the February Masterclass webinar with a nice solution involving Orchestrator runbooks). Hopefully this would mean users get a good overview of what SCOM monitors per default so they know what type of custom monitoring they would need to request from the SCOM administrators.
While it does not remove the fact that you still would need to manually create custom SCOM monitors for websites/log files/processes, it would mean less manual work when creating basic dashboards in Squared-Up, and hopefully gives users a better insight as to what SCOM already monitors.
