Collapse Clustered Instances at Group Level
It has recently become clear to me that when you have multiple devices with the same instances (due to clustering or otherwise shared resources), there is no way to collapse these into a single alerting instance without a lot of manual and maintenance-intensive effort. The most recent example I have run into relates to vSphere with shared datastores (i.e., any implementation with vCenter, vMotion, etc.). In those cases, LM fails to distinguish the datastores presented at the cluster level from host-local datastores, and all are presented in parallel. With a vCenter and 8 hosts, this generates 9 alerts per clustered DS. I have been told by support I am out of luck on this for now, which is unfortunate, but I had an idea that could be used for this case along with other similar cases. Sadly, the name "Cluster Alerts" has already been taken, but I would call this idea that as well, just with a different methodology. So either an extension to Cluster Alerts or some new name TBD. The idea is to collapse specific instances within a group into a single instance at the group level. This way we can pick which instances are clustered (still manual, but manageable) and ensure only a single alert and view of those instances. Ideally, LM could be smart enough to identify the clustered elements and do this automatically, but this method would apply to any similar situation even if the API does not reveal the cluster binding details like ESX does. Please consider adding this enhancement soon!
Thanks,
Mark
Cole McDonald
·7 years agoPrevious had an issue with the properties it was adding. If you're creating a new property from a proertySource script, it adds it as an "auto.*" property, which goes away as soon as the script stops processing. To add a new permanent custom property, you have to use the REST API, not just a "category.name=data" output from the script. Here's the final:
Cole McDonald
·7 years agoDone!!! Here's the final code... same warnings as in my previous post:
Cole McDonald
·7 years agoOK... I've got everything working but the folder creation... isolating and fixing.
Cole McDonald
·7 years agoAlright... I'm really close. What am I missing here? It worked, then it didn't... now it applies the first output and stops doing the rest of them. I know it's something small and dumb, but I've been staring at this for a while now:
Disclaimer: Neither I nor Beyond Impact 2.0, LLC make any warrantee that this code will work properly in your environment. Use cautiously. Caveat Emptor.
Cole McDonald
·7 years agoI've got the whole thing written, but troubleshooting scripting in the LM environment is tricky at best. All of the pieces work individually, but seem to not do the things they are supposed to as soon as I put it in a PropertySource. I'm trying the chrome plugin as well... I don't even seem to be able to get it to write a log... I have some really broken down troubleshooting to do to figure out how to troubleshoot the actual script.,, but it's promising. It:
A) checks to see that if the device is already tagged and tags if necessary
if it's not already tagged it:
B) identifies VMs that are part of a cluster
C} identifies the cluster they're part of
D) checks the group structure to determine if there is a group already made for that cluster
if it doesn't exist yet, it:
E) makes the dynamic group if it doesn't exist yet with the appropriate appliesTo to pull in the devices
After that, I just need to determine what cluster alerts to apply to it (and how to make that happen)
Cole McDonald
·7 years agoOk... Progress:
I'm about half way done with the rest of this script:
Time for the weekend, I'll keep you all updated.
Cole McDonald
·7 years agoCan't edit the previous post... so here's a quick update: I lied. I had thought HyperV clusters and SQL clusters used a different mechanism for their respective clustering. They don't, they use the same mechanism. This works for hyperV as well. To make it work with vCenter, you'll just need to identify an identifying piece. I am using the existence of the Cluster DB file.
Cole McDonald
·7 years agoFor Failover Clusters in Windows Server, here's a powershell propertySource that will add a category to members of clusters. It's not the complete solution, but it'll allow you to better target eventSources to eliminate some of the strain on your Collectors:
It doesn't currently identify owners (although that can probably be done with an invoke-command { test-path "hklm:\0.Cluster" } as the owner of the cluster gets the extra Registry Cluster Hive copied during the failover. (https://blog.workinghardinit.work/2016/03/29/the-cluster-and-0-cluster-registry-hives/).
I have powershell that will identify Clusters by name and GUID and find the Nodes associated with them. I've got to figure out how to get that to create dynamic groups and populate them using properties. I'm most likely going to have to figure out how to make it be a timed script 1-2 times a day that then scans for cluster members and performs a bunch of queries using the failovercluster PS Module commandlets. Then use the REST API to create the associated structures to get them grouped so we can add clustered alerts to them and turn off their individual alerts.
Then I can apply the same kind of logic to Hyper-Visor clustering. I'm slowly chipping away at this to make it fit our business model's use case.
Cole McDonald
·7 years agoHere was my solution:
Add Custom Property to each device with the cluster ID (or an arbitrary GUID/unique naming convention instance). We used HyperV.Cluster.GUID = <GUID generated by powershell with New-GUID>
Use that to build a dynamic group for each cluster
Use that group to allow for cluster alert for which ever sources you're trying to get visibility into, then tell it not to trigger those source alerts for the individual members of the group.
To help reduce the number of repeated emails generated by the escalation chains, add a blank entry to the end of the escalation chain you're using. The escalation increments through the steps after the escalation time has passed, then repeats the last step once it gets to the end. That can produce far more emailed alerts than are necessary. Adding a blank last step causes the escalation to repeat that after making it through the chain. You can add timing pauses into your escalation chain as well by adding blank steps between. If the alert closes during that time, the rule ends and the following steps don't fire.
For instance, in Dynamics AX, the AOS servers can take a long time to come up. Our team needs to know that it's gone down. Our customer needs to know if it doesn't com up. Rather than making a pair of sources that we can then create separate alerts for, We make the first step the contact to our team, then enough blanks to account for the time it normally takes for the service to restart. After that, we add the customer's team, then a blank.
Our current ticketing system only accepts automated tickets via email. These little tricks allow us to have tickets only generated once per alert, and allow us to make sure we're not panicking our customers for failovers / failures that are recovering as expected.
Cole McDonald
·7 years agoI'm working through this specific issue right now as we move from SCOM to LogicMonitor. Has anyone found a good workaround for this? I'm getting a dozen alerts for a single event every time a volume in our Hyper-V Cluster goes over capacity threshold.
Annie_Dunham
·9 years agoHi Mark - Thanks for taking the time to write this up. We're currently knee (possibly neck) deep in designing how take what has historically been a device - instance centric view of the world and extend it to best accommodate applications, services, and clusters. This is on our radar, and we'll keep your specific use case in mind.