sjmh
Enthusiast
Enthusiast

Alert templates based on configured resources

I'm somewhat afraid to ask this, after my recent foray, but I've got to.

What recommendations are there for creating alerts based on configured resources? The EE version does let you configure alert templates, but only for the general resource. In a way, this is too much abstraction and it works for some things but others, not so much.

Here's some examples:

Alert templating works great for a platform, because a platform is specific. I could set an all Linux systems to alert on their CPU usage or some other thing.

However, this kinda sucks for the FileServer Mount service because it isn't specific enough. While I might want to set the root partition to alert at 95%, because in a system that is configured with mounts for alot of it's directories the root partition won't grow that much, I might want to setup an alert template for 80% for all /var mounts. Unfortunately, I don't see a way to do that.

This occurs again for things like processes and such. So my question is - how to get around this? Should I instead define groups for all similar resources ( all my / partitions ) and then create a 'If any 1 of these resources is above 80%, alert' or is there some other way? I saw in some of the HQU items, specifically the Mass plugin, that it supports a type of dynamic grouping, although it would have to be run manually each time in order to get everything into the right group.

Another disadvantage of the abstraction is that the global alert templates override the changes made in each alert for the specific resource. For instance, let's say that I go through my 300 systems and correctly modify their discovered file mount resources for each partition and set them up the way I like. Then 6 months later, I choose to update the default alert template from 80% to 85%. It goes and changes all my file mount alerts - ow?

It just seems there should be a way in the global alert templates to define alert templates for specific instances of resources, rather than abstracting it to any instance of the resource. Something like an extra field that says 'And if the resource has this configured property or matches this string'.

But as they stand now, I don't see how the alert templating makes much sense or is of that great of use in alot of circumstances. I'm hoping someone can shed some light on the situation and that I'm not just being blind.

Read up some more about HQU. 🙂


Message was edited by: shajducko
0 Kudos
4 Replies
admin
Immortal
Immortal

Have you taken a look at Group Alerts? Put all the resources you
want to apply your alert def to into a group, then setup an alert for
all those members.

-- Jon


On Apr 22, 2008, at 11:55 PM, Steven Hajducko wrote:

> I'm somewhat afraid to ask this, after my recent foray, but I've
> got to.
>
> What recommendations are there for creating alerts based on
> configured resources? The EE version does let you configure alert
> templates, but only for the general resource. In a way, this is
> too much abstraction and it works for some things but others, not
> so much.
>
> Here's some examples:
>
> Alert templating works great for a platform, because a platform is
> specific. I could set an all Linux systems to alert on their CPU
> usage or some other thing.
>
> However, this kinda sucks for the FileServer Mount service because
> it isn't specific enough. While I might want to set the root
> partition to alert at 95%, because in a system that is configured
> with mounts for alot of it's directories the root partition won't
> grow that much, I might want to setup an alert template for 80% for
> all /var mounts. Unfortunately, I don't see a way to do that.
>
> This occurs again for things like processes and such. So my
> question is - how to get around this? Should I instead define
> groups for all similar resources ( all my / partitions ) and then
> create a 'If any 1 of these resources is above 80%, alert' or is
> there some other way? The problem with the grouping method is that
> I then have to take each resource during inventory and shove them
> into the right groups.
>
> Another disadvantage of the abstraction is that the global alert
> templates override the changes made in each alert for the specific
> resource. For instance, let's say that I go through my 300 systems
> and correctly modify their discovered file mount resources for each
> partition and set them up the way I like. Then 6 months later, I
> choose to update the default alert template from 80% to 85%. It
> goes and changes all my file mount alerts - ow?
>
> Perhaps this can be accomplished with the new Groovy stuff? I'm not
> sure. It just seems there should be a way in the global alert
> templates to define alert templates for specific instances of
> resources, rather than abstracting it to any instance of the
> resource. Something like an extra field that says 'And if the
> resource has this configured property or matches this string'.
>
> But as they stand now, I don't see how the alert templating makes
> much sense or is of that great of use in alot of circumstances.
> I'm hoping someone can shed some light on the situation.


0 Kudos
sjmh
Enthusiast
Enthusiast

Yeah, I mentioned the group alerts in my post. As I said, the only downfall to the groups is that they aren't dynamic, meaning one has to put the new resource into the proper groups, rather than having groups that are formed based on criteria ( which I believe is already a filed enhancement ).

We'll probably go that path for now with the Mass plugin to constantly update the groups.
0 Kudos
admin
Immortal
Immortal

Yes, manually updating of group membership is more painful than it
needs to be.

You'll be happy to know that our next major release (this summer)
will provide criteria based groups, which automatically determine
group membership based on arbitrary criteria.

-- Jon



On Apr 23, 2008, at 10:18 AM, Steven Hajducko wrote:

> Yeah, I mentioned the group alerts in my post. As I said, the only
> downfall to the groups is that they aren't dynamic, meaning one has
> to put the new resource into the proper groups, rather than having
> groups that are formed based on criteria ( which I believe is
> already a filed enhancement ).
>
> We'll probably go that path for now with the Mass plugin to
> constantly update the groups.


0 Kudos
sjmh
Enthusiast
Enthusiast

Cool, thanks Jon.

Also watched your HyperCAST on the HQU stuff. Very impressive and I can see the real power in it. I just gotta go buy my Groovy in Action book and start plugging away. 🙂
0 Kudos