VMware Cloud Community
alsmk2
Hot Shot
Hot Shot
Jump to solution

Customizing alert sensitivity

I'm finding that the OOB alerts with vRealize are too sensitive, meaning that after an initial deployment, the client is usually flooded with repeated alerts. Whilst the alerts may be valid, I find it ends up with most clients simply ignoring alerts rather than doing anything about them.

Here's an example - an alert for continuous high CPU workload is triggered repeatedly on a VM. When you delve into it, the high workload is only for a few minutes every few hours, and still not maxing out resource. In this instance, the alerts are just a nuisance as the IT team do not see this as a problem.

What I'd like to achieve is for the alert still to trigger, but only after the issue has been active for X amount of time, such as 1-2 hours. Is this possible?

I've not really delved into modifying the alerts, and in all honesty, I'm not fully understanding how to do so. I keep coming across the "wait cycle" within the alert definition, but I'm not sure if that is what I need to modify. One cycle is equal to 5 mins, so if I were to change this to 12, would this have the effect of waiting an hour before triggering an alert if the various symptoms were ongoing during that period?

Reply
0 Kudos
1 Solution

Accepted Solutions
sxnxr
Commander
Commander
Jump to solution

Yep vrops out of the box will generate lots of alerts. What i do (and this can be time consuming but worth it) is disable all OOTB alerts in your policy and clone the ones you want and create your own alerts,

The main reason we did this is so we get alerts on what we want and because we cloned and didn't modify existing OOTB alerts is if we do an upgrade to vrops it would not over write my alerts.

also the wait cycle is probably what you want to change. My understanding is wait cycle is the length of time to wait before triggering the alert. Each cycle is 5 mins so if you set it to 10 it wont trigger the alert until it was active for 50 mins.

View solution in original post

Reply
0 Kudos
4 Replies
sxnxr
Commander
Commander
Jump to solution

Yep vrops out of the box will generate lots of alerts. What i do (and this can be time consuming but worth it) is disable all OOTB alerts in your policy and clone the ones you want and create your own alerts,

The main reason we did this is so we get alerts on what we want and because we cloned and didn't modify existing OOTB alerts is if we do an upgrade to vrops it would not over write my alerts.

also the wait cycle is probably what you want to change. My understanding is wait cycle is the length of time to wait before triggering the alert. Each cycle is 5 mins so if you set it to 10 it wont trigger the alert until it was active for 50 mins.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

sxnxr​ has you in the right direction. You want to modify the Wait Cycle, but his recommendation to clone the OOTB alert and modify is exactly right. Never modify content that comes OOTB because future upgrades will wipe away those changes. The wait cycle is how many collection cycles vROps has to go through and observe that condition as 'true' before it will fire. What I recommend to people when I do these installations is to use the OOTB alerts and see how they perform in your environment. Then start keeping a list of alerts you want to disable, those you want to modify and tweak, and ones you want to see that aren't showing up. Take that to your policy and makes changes there. Do not delete OOTB alerts or modify them. You'll be in a better position going forward if you do so.

alsmk2
Hot Shot
Hot Shot
Jump to solution

Chaps - thanks for the responses.

I've cloned the most annoying alerts and set the wait cycles more appropriately. I'll monitor over the next few weeks to see whether it reduces the number of false positives.

Thanks again.

Reply
0 Kudos
OsburnM
Hot Shot
Hot Shot
Jump to solution

Not to hijack the thread but it's along the same lines as the OP here-- I've setup a couple new policies and I'm not getting very far with the inheritance / priorities.  It's setup (as below) the way I thought it was supposed to work, yet my Alerts keep firing.

My objective here is to turn off ALL Alerts, except one new User Defined Alert (Datastore Cluster Capacity Alert), and then block that new alert on a few specific objects defined in a custom group.

I'm attempting to leave the Alerts as defined in the "vSphere Solution's Default Policy" completely alone (ie, enabled/defaults).

I then created a new "COMPANY - Default Policy with Custom Baseline Alerts" where that used the Solution's Default as its base.  I disabled all but this one alert (Datastore Cluster Capacity Alert) and applied this policy to the "Product Licensed" default group.

From there I created another new "COMPANY - Default Policy Alert Override for X Datacenter" using the "COMPANY - Default Policy with Custom Baseline Alerts" as my base for this new Policy and I disabled the (Datastore Cluster Capacity Alert), and lastly applied this policy to a Custom Group that has the Datastore Clusters I wish to exclude from the alert.

The Policy Priorities are:

1 - COMPANY - Default Policy Alert Override for X Datacenter

2 - COMPANY - Default Policy with Custom Baseline Alerts

D - vSphere Solution's Default Policy

I'm able to validate the various objects all now show defined by #2 above except for the Datastore Clusters I want excluded via my group.  Those properly show the #1 policy above.  So everything LOOKS right, YET I'm still getting all the alerts!  Very frustrating.

Any ideas?

Reply
0 Kudos