+2We have some messages that we eliminate via an automatic restart during the night (e.g. C disks with warning, SWAP messages).
If we work with acknowledgements and the problem has not been solved overnight, the alarm remains permanently acknowledged and we lose sight of this alarm.
If we work with a downtime until the next morning at 05:00 (which we currently do), we do not notice if the C disk switches from Warning to Critical by then and may prevent users from continuing to work.
+18If we work with a downtime until the next morning at 05:00 (which we currently do), we do not notice if the C disk switches from Warning to Critical by then and may prevent users from continuing to work.
I’m not sure to understand the difference in your use case from using acknolegements and downtimes.
If during the restart phase you “don’t care” about the data, why not just using the planned downtime for those machines (or through api dynamically) to disable the raise of errors, the status issue (if there is) will come back after the reboot phase.
+18+2if we set a downtime from 09:00 h - 05:00 h (+1), because we do a reboot of a vm over night to solve c disk warning, we’ve the problem that we will not get an info about warning raising to critical from 09:00 h to 05:00 h (+1).
E. g. if C disk raises to critical at 13:00 h, our users cannot work anymore, but in Centreon monitoring all is fine, because there is set a downtime.
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
