Best Practices in setting up groups for alarm filters

Discussion created by sachinsharma on Dec 21, 2010
Latest reply on Dec 21, 2010 by 3859

At a POC and had a generic question come up that I thought I'd post to see what feedback I could get. We started to build out a custom dashboard and wanted to group services that made up applications into alarm filters. So for exmaple, we'd have a box that says "Claims Processing" on our dashboard and that box would contain an alarm object with alarms that contain claims processing services - SQL, e2e, system probes, etc, on various servers. Maybe another box that has all alarms related to "Mortgage Processing", etc.


Usually, it's easy enough to set up user tags on robots and use that as part of the alarm filter criteria. The issue is there aren't enough user tags. Sometimes a server can belong to multiple applications. You'd also have to consider agentless probes and how user tags aren't as elegant with agentless monitoring. So then we thought maybe use the source field in the alarms as a consistent differentiator in alarm filters. Issue with that is the source can be changed on some probes like logmon, but not all (would be nice for consistency!!). So then we thought how about subsystems. But with that, you have to set up custom subsystems per probe, per robot, which might, but seems like a lot of work. Finally, we thought how about this new custom tags option where there's 5 additional fields you can attach to alarms. But this seems like it can only be set up using scripts and I haven't experimented much with it.


So the questions then:

1. Has anyone worked with the custom tags setting in alarms? Is it only possible using LUA?

2. Would subsystems be the best option here?

3. What are the best practices you've seen in the field on this topic? I realize it's different for every customer, but I hope I'm not overlooking something that can be done very easily.




user tags

how to set custom tags in alarms


source only in some probes