Details
-
Problem report
-
Status: Open
-
Trivial
-
Resolution: Unresolved
-
5.4.11
-
None
-
None
-
Docker container: zabbix/zabbix-web-nginx-mysql:ubuntu-5.4.11
Docker host & container TZ: UTC
PHP_TZ=Africa/Johannesburg (aka UTC+02:00)
User TZ: System default: (UTC+02:00) Africa/Johannesburg
Description
I have noticed that the "Problem" value is inflated significantly in the "Services availability report" when using the "Daily" view when you've added a "One-time downtime" event that spans over midnight AND there was an incident that day.
Please see the Environment field in this ticket for my Zabbix setup.
This issue also existed in v5.4.6 and is still present after I upgraded to v5.4.11. I noticed that when I change my user's time zone, it also fixes the issue, but then the reporting's days are with an offset that I don't want.
Steps to reproduce:
- There had to have been an "Problem" on that day
- The Service's Time (under Configuration > Services > (your service) > Time) must have a "One-time downtime" configured that runs over midnight, eg. 2022-02-23 23:59 to 2022-02-24 00:01
- Your user profile's time zone matters, and possibly the server's time zone too
- Go to Monitoring > Services > (your service) > select "Daily" from the dropdown at the top right. I have not noticed this issue on the "Weekly" or "Monthly" view.
Result:
It is evident that the "Problem" duration when using the "Daily" view for 2022-02-24 is inflated (0d 07h 55m), because when comparing it to the "Weekly" view, that whole week's "Problem" duration only added up to like "0d 4h 38m". See the screenshots below:
Workaround/Expected:
Instead of adding a single "One-time downtime" that spans over midnight, I split them into 2x entries.
eg. Instead of "2022-02-23 22:00 - 2022-02-24 02:00", add one for "2022-02-23 22:00 - 2022-02-24 00:00" and another one for "2022-02-24 00:00 - 2022-02-24 02:00"
See the screenshot of the Daily view below when using this workaround:
Side note:
If I change my user profile's time zone (under Administration > Users > (my user) > Time zone) , then the "Problem" duration was not inflated, but then the "Downtime" calculation was impacted due to the timezone offset: