We have two Icinga environments, one for test and one for prod. In production, we have our Master (icingaweb2) server behind a proxy, this is the URL: https://icinga-cofc.msappproxy.net
However, when you access via the proxy URL, it also works, but data isn't loaded into the widgets until after a significant delay (1m55s according to my stopwatch).
More interestingly, running dashing in the foreground seems to indicate that data is being retrieved at the SCHEDULER interval of 10 seconds, but the front end is not updating to reflect those retrievals. At least, again, not until after a long time.
Wondering what sort of variables/intervals in the source do you think align with this time frame and is it fixable? Have you seen a working instance of dashing-icinga2 behind a proxy?
This is a captured log of running dashing in the foreground while trying to access dashing via proxy URL
Expecting dashing icinga2 to show data on front end immediately upon page refresh/load
Current Behavior
Dashing front end does not load data until 1m 55s after page refresh (so, it's succeeding, just after a long wait)
Significant to note here that the 10s scheduler interval was not changed
Possible Solution
Based on the log suggesting that the backend querying works, I imagine there's something on the front end referencing a request URL that's causing the data not to load in properly, but I could be completely wrong. Alternatively, there's a moving part linking the backend icinga2 job to the front end widgets that is malfunctioning due to the use of a non-local URL/address (proxy instead of localhost)
As the primary administrator of this application for the College of Charleston's IT department, my goal is to establish a reliable, nice dashboard to keep up on a shared office monitor that reveals monitoring data and alerts about the > 1000 hosts and > 3000 services that we are monitoring, from web server VMs to physical networking gear. It's really about closing the gap between problems and solutions by improving awareness.
Your Environment
Dashing version (gem list --local dashing):
1.3.7
Ruby version (ruby -V):
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]
Version of this project (tarball name, tag name or git show -1):
[root@RP-Icinga-M01 dashing-icinga2]# git show -1
commit 68cf8b254e0fefc3d5df547452a8b49477e54b9c
Merge: 5ce63b1 3a1d20c
Author: Michael Friedrich <michael.friedrich@gmail.com>
Date: Wed Nov 27 11:00:48 2019 +0100
Merge pull request #99 from mocdaniel/master
Scrolling of crammed widgets
* Modifications to this project, if any (`git diff`):
We have two Icinga environments, one for test and one for prod. In production, we have our Master (icingaweb2) server behind a proxy, this is the URL: https://icinga-cofc.msappproxy.net
We have the dashing dashboard located at https://icinga-cofc.msappproxy.net/dashingicinga
When you access dashing via the server name directly (say, http://icingawebserver/dashingicinga), it works like a charm.
However, when you access via the proxy URL, it also works, but data isn't loaded into the widgets until after a significant delay (1m55s according to my stopwatch).
More interestingly, running dashing in the foreground seems to indicate that data is being retrieved at the SCHEDULER interval of 10 seconds, but the front end is not updating to reflect those retrievals. At least, again, not until after a long time.
Wondering what sort of variables/intervals in the source do you think align with this time frame and is it fixable? Have you seen a working instance of dashing-icinga2 behind a proxy?
This is a captured log of running dashing in the foreground while trying to access dashing via proxy URL
Expected Behavior
Expecting dashing icinga2 to show data on front end immediately upon page refresh/load
Current Behavior
Dashing front end does not load data until 1m 55s after page refresh (so, it's succeeding, just after a long wait) Significant to note here that the 10s scheduler interval was not changed
Possible Solution
Based on the log suggesting that the backend querying works, I imagine there's something on the front end referencing a request URL that's causing the data not to load in properly, but I could be completely wrong. Alternatively, there's a moving part linking the backend icinga2 job to the front end widgets that is malfunctioning due to the use of a non-local URL/address (proxy instead of localhost)
Steps to Reproduce (for bugs)
This is a link to our example of a malfunctioning dashing-icinga2 dashboard living behind a Microsoft App proxy: https://icinga-cofc.msappproxy.net/dashingicinga
Context
As the primary administrator of this application for the College of Charleston's IT department, my goal is to establish a reliable, nice dashboard to keep up on a shared office monitor that reveals monitoring data and alerts about the > 1000 hosts and > 3000 services that we are monitoring, from web server VMs to physical networking gear. It's really about closing the gap between problems and solutions by improving awareness.
Your Environment
Dashing version (
gem list --local dashing):Ruby version (
ruby -V):Version of this project (tarball name, tag name or
git show -1):[root@RP-Icinga-M01 dashing-icinga2]# git diff diff --git a/assets/javascripts/application.coffee b/assets/javascripts/application.coffee index 70fbd31..9f662e4 100644 --- a/assets/javascripts/application.coffee +++ b/assets/javascripts/application.coffee @@ -12,8 +12,8 @@ Dashing.on 'ready', -> Dashing.widget_base_dimensions ||= [300, 300] Dashing.numColumns ||= 5
background-color: black; / Stretch the background image, don't duplicate it / -webkit-background-size: cover; / For WebKit / -moz-background-size: cover; / Mozilla / @@ -120,7 +120,7 @@ h3 { }
banner {
@@ -172,12 +172,12 @@ h3 { display: flex; flex-direction: column; / Pimp mode /
border-radius: 8px; }
.header { @@ -258,6 +258,7 @@ h3 {
container {
display: inline-block;
diff --git a/dashboards/icinga2.erb b/dashboards/icinga2.erb index aa400af..0c02b45 100644 --- a/dashboards/icinga2.erb +++ b/dashboards/icinga2.erb @@ -25,7 +25,7 @@ $(function() { data-title="Hosts" data-labels="Up,Down" data-colornames="green,red"