Certain dashboards do not auto-refresh

Hi guys,

first time posting, so please be patient with me :wink:

Following issue:
Icinga 2.9.5
Graphite 1.1.0 (running in a pod)

Basically all running fine, icinga and graphite (even though running in OEL8), all good, BUT:
Iā€™ve created a Dashboard, showing only graphite graphs (donā€™t wanna see the check-result but only graphs of certain services/hosts (like cpu, vmstat, and so on). I did this by setting up the desired view from main menu ā€œGraphiteā€ ā†’ ā€œServicesā€ ā†’ filtering the whole bunch
This results in a URL which Iā€™ve copypasted into a new dashlet (basic icinga dashboard).

Works well, all desired graphs are being shown in the dashboard

BUT: this dashlet - in contrary to default like ā€œCurrent incidentsā€ or ā€œOverdueā€ - does NOT auto-reload. I have to manually click the refresh-swirl. Fine for me but my plan is to set this up for a department-user (or kiosk), where clicking is no option.

My guess: somewhere under the hood the dashboard is being refreshed if dashlet-URL contains ā€œmonitoring/list/blaā€ but in my case its ā€œgraphite/list/blaā€
(full dashlet url: graphite/list/services?service=host_check_cpu&(host=important_server1|host=important_server2)&graphs_limit=2 )

So my quite simple question: can I get my graphite-dashboard being auto-reloaded? I really hope its feasible somehow :expressionless:

Much appreciated

Stefan

Edit: example of such a dashboard

Hi, this works fine for me here. Using the same URL resulting in two graphs.

How did you notice that it doesnā€™t refresh? Note that the interval of the other contents are usually 10 seconds, the graphs are refreshed every 30 seconds though.

Just to make shure, what have you set in the user preferences?

Hi Johannes,

well, all other pages do autorefresh, e. g. ā€œCurrent Incidentsā€-Dashboard; also, in parallel opened those checks in a seperate tab; all pages do autorefresh, except those graph-dashboards
After a couple of hours one do see the gap

Hi Dominik,

auto-refresh is set, also it works well for all other dashboards and check-pages (basically everything else but this single dashboard-page containing graphs only)

For testing purpose Iā€™ve put a service-check aside, outcome: the service-check frame is being auto-reloaded, but NOT the graph-frame; this one remains un-refreshed

Just to be sure, do you use this graphite module or another one? Which version?

Yes, version is 1.1.0, launched within a pod as its been quite impossible to run graphite native on OEL8 (installation based on this: https://computingforgeeks.com/install-graphite-graphite-web-on-centos-rhel/ )

graph_module

Iā€™m suspecting that the ā€œissueā€ is rooted somewhere in this avalanche of icinga-php-files, as only monitoring/list-urls are being refreshed but nothing containing graphite/list-urls, but tbh my php-knowledge is too weak

Ah, I thought the version you mentioned in your OP for Graphite was for the backend.

The module in version 1.1 does not auto refresh. The latest release does.

Okay, so its a dead end as it seems ā€¦
1.2.x requires php-library 0.9
which requires icingaweb2 > 2.9.5
which does not exist for el8 in repos

:confounded:

as of now, icingaweb2 for el8 since nov2021 no change (stuck on 2.9.5) whilst el7 has already past 2.11.

ā€¦ hoping for updates soon ā€¦

There will be no public updates. See Announcing official Icinga packages for RHEL, Amazon Linux 2 and SLES and Icinga Ā» Developer Subscription for details.

sigh great ā€¦ new project: offboarding Icinga

Best line in this stupid announcement: ā€œBut not everything is badā€
I have no words for this ā€¦

We also werenā€™t happy about it but it coincided with us wanting to buy support anyways so we begrudgingly changed to the pay walled repo.
From the quite severe blow back, I think migrating away is a bit hasty as I believe a alternative will spring up soon in the form of a community repo or a free tier matching REHL licencing.
Migrating to Debian or Docker are also options - I would run on Debian if not for my external partners being more confident on RHEL based systems.