Feature Request - Bigger Alarm Time Period

[stemplar]

We have a test and development environment and would like to optimize the alarms to our needs. In that sense, the one hour as maximum period is too short for build and automated test machines. Right now it means we exclude some VMs from the trigger. I'd like to have bigger monitoring intervals. Ideally a custom number plus a selectable unit, e.g. 3 hours, or 1.5 days, ....

[stemplar]

Hello Nikita,

A build server is o.k. to use the CPU for 3-6 hours, but not for e.g. 12 hours in a row. I'd like to get an email after 12 hours, but not before.
All I saw so far was the one hour threshold.

[Shestakov]

Simon,

In the next version of Veeam One, which is going to be released in November you would be able to select time parameter in an alarm rules for up to 3 hours.
Also we have extended alarm suppression options, you would be able to select days and specific hours for alarms suppression.
Another way to solve the issue you have described is to switch necessary objects to the maintenance mode.

Is that what you are looking for?

[stemplar]

No, maintenance mode is not what I'm looking for. Why do you limit the user in the coming version to 3 hours? Is it technically difficult to be more flexible?

In order to manage a VDI environment, I need multiple triggers on the same kind of performance parameters at different thresholds and at different length. E.g. 20 ms read latency on a data store for 1 hour may be ok, but possible I'd like 15 ms average in 2 days. The artificial intelligence of vCOPs did not help me at all so far. But Veeam One's period based triggers really make a difference, and I'd like to use more of it, even if it would 'cost' me more on the Veeam DB side.

[Vitaliy S.]

Why do you limit the user in the coming version to 3 hours? Is it technically difficult to be more flexible?

No, it's not. When we were discussing this setting, we could not come up with a situation where you would need more than 3 hours for performance metric being about the defined threshold, so thanks for additional clarifications.

[stemplar]

The long monitoring period could also be used in the other direction, e.g. if a VM has CPU load less than 300 MHz for 5 days, and has disk IO of less than 10 MB read/written in one week, then perform a vCould compatible shutdown. A 'low activity' shutdown trigger would help a lot our operations. Right now, vCloud only offers time base approaches, which fall short in a lot of scenarios.

[Vitaliy S.]

Thanks for sharing this case as well, but you can use Idle VMs report to detect these VMs and shut them down. I have talked to our dev team and we will extend available options in the alarm settings in our next minor updates (right after version 8 goes live).