Dashing-icinga2 - NOT Showing data from my ICINGA2 platform

HI!
I have installed on a fresh UBUNTU Server 18 the dashing-icinga2 dashboard.
The installation was simply and goes well.
I choose to install dashing-icinga2 on a separate server (in the same network of ICINGA)
dashing-icinga2 start correctly.
But the data I can see when connected to http://my-dashing-host:8005 seems to be “simple data” and not the data from my ICINGA2 server.
In addiction the frame with problems are empty and show a message related to cookies (Cookies must be enabled to run this application)
What I missing ?
THX

I PARTIALLY solved (was a problem with API USer) the first part of problem (NOW data are reported correctly from my ICINGA).
BUT still I have the “Icinga Web Host\servce Problem” EMPTY with text:
Cookies must be enabled to run this application

Hey,

I also have the same problem. I have just example values in my dashboard. Why?

I also have following problem:

I’ll dig this out, because I’m slowly going crazy.

I have setup dashing according to the docs (apart from not running bundle as root, because it wonly works as root) and also get only some sample values.
API user has the correct permission (even tried with “*”).

The VERY strange thing: As soon as I do systemctl stop dashing-icinga2 or systemctl restart dashing-icinga2 the values are updated to the actual numbers.

If anyone got the current v3.0.0 of dashing running correctly I would be very happy to be pointed in the right direction

looking at the log file of the dashing thin server also shows that data is pulled:

zones {"zone1"=>{"client_log_lag"=>0.0, "connected"=>true, "endpoints"=>["SRVzone1MONSAT"], "parent_zone"=>"master"}, "zone2"=>{"client_log_lag"=>0.0, "connected"=>true, "endpoints"=>["srvzone2monsat"], "parent_zone"=>"master"}, "master"=>{"client_log_lag"=>0.0, "connected"=>true, "endpoints"=>["srvzonemastermonmaster"], "parent_zone"=>""}, "zone3"=>{"client_log_lag"=>0.0, "connected"=>true, "endpoints"=>["SRVzone3MONSAT"], "parent_zone"=>"master"}}
checker {"idle"=>150.0, "pending"=>0.0}
command 1.0
main-log 1.0
graphite {"connected"=>true, "work_queue_item_rate"=>2.466666666666667, "work_queue_items"=>0.0}
app {"enable_event_handlers"=>true, "enable_flapping"=>true, "enable_host_checks"=>true, "enable_notifications"=>false, "enable_perfdata"=>true, "enable_service_checks"=>true, "environment"=>"", "node_name"=>"srvzonemastermonmaster", "pid"=>26523.0, "program_start"=>1601457142.66971, "version"=>"r2.12.0-1"}
ido-mysql {"connected"=>true, "instance_name"=>"default", "query_queue_item_rate"=>7.416666666666667, "query_queue_items"=>0.0, "version"=>"1.14.3"}
notification 1.0
Stats: [{"label"=>"Host checks/min", "value"=>30.0}, {"label"=>"Service checks/min", "value"=>112.0}, {"label"=>"json_rpc queue rate", "value"=>"8.22"}, {"label"=>"graphite queue rate", "value"=>"2.47"}, {"label"=>"ido-mysql queue rate", "value"=>"7.42"}]
Severity: [{"label"=>"srvzone3aap - cpu", "color"=>"yellow", "state"=>1}, {"label"=>"srvzone2temp19 - services", "color"=>"purple", "state"=>3}, {"label"=>"zone2Fax - disk-c", "color"=>"purple", "state"=>3}, {"label"=>"srvzone2temp19 - swap", "color"=>"purple", "state"=>3}, {"label"=>"srvzone2temp19 - memory", "color"=>"purple", "state"=>3}, {"label"=>"srvsql - services", "color"=>"purple", "state"=>3}, {"label"=>"srvzonemasterdocuware1 - memory", "color"=>"purple", "state"=>3}, {"label"=>"srvzone1hv2 - services", "color"=>"purple", "state"=>3}, {"label"=>"zone2SW-A04 - memory", "color"=>"purple", "state"=>3}, {"label"=>"zone2File - disk-d", "color"=>"purple", "state"=>3}, {"label"=>"srvzone1opc - swap", "color"=>"purple", "state"=>3}, {"label"=>"srvzone2usv1 - hardware-health", "color"=>"purple", "state"=>3}, {"label"=>"srvzonemasteropc - disk-c", "color"=>"purple", "state"=>3}, {"label"=>"cisco1 - hardware-health", "color"=>"purple", "state"=>3}, {"label"=>"srvzonemastersql - swap", "color"=>"purple", "state"=>3}, {"label"=>"zone2Spl - swap", "color"=>"purple", "state"=>3}, {"label"=>"srvzone1opc - memory", "color"=>"purple", "state"=>3}, {"label"=>"srvzonemastersql - memory", "color"=>"purple", "state"=>3}, {"label"=>"zone2SW-A04 - cpu", "color"=>"purple", "state"=>3}, {"label"=>"zone2DB - disk-d", "color"=>"purple", "state"=>3}]

Same :poop: happens with v2.0.0.
Strange thing, bc only this server is affected.

A different server of a different customer (running onprem instead of azure) works without problems.

edit:
dirty workaround:
cronjob for restarting the dashing-icinga2.service every morning…

@log1c
I saw this thread and your post the last days and I didn’t find time to look into. We are running dashing sine more than one year. But we are still staying at the master branch and v2, never upraded to the latest master or v3 - so, same as you.
After you edit your post with the dirty workaround I took also a look into our cronjob-config. So be calm, I saw my colleague configured the same. :man_shrugging: Seems to be a general problem

1 Like

Thanks for the feedback :laughing:
Do you, by chance, also have dashing running on an Azure VM?

nope, we run it on CentOS

Well, the workaround doesn’t really work.
If you open the dashing page after the restart it will still only display the sample (or whatever) values…

I’ll open a bug report and the if the maintainer has any ideas.

@stevie-sy can I interest you in sharing your setup in the bug report as well, as you are experiencing the same problem? :slight_smile:

1 Like

I read it. :slight_smile:
I ask my colleague, who has setup the dashing-server, why he really configure a cronjob with the restart. Because with that our dashing works fine and without any troubles. I’ll give you an update, if I know more.

But what I can see in our salt-call is we are using our own files:

  • /usr/share/dashing-icinga2/config/icinga2.local.json:
    this is clear, because of the API user for icinga
  • /usr/share/dashing-icinga2/dashboards/icinga2.erb (and other dashboards)
    this is also clear because of the dashboard design and which data should be shown on our big screen
  • /usr/share/dashing-icinga2/lib/icinga2-lib.rb
    no idea, why we chanced something here
  • /usr/share/dashing-icinga2/jobs/icinga2-jobs.rb
    no idea, why we chanced something here
  • /usr/share/dashing-icinga2/config.ru
    the chance here is the IP-Adresse of our dashing-server
1 Like

So, I asked my colleague. The answers:

  • /usr/share/dashing-icinga2/jobs/icinga2-jobs.rb => here he changed the time for the scheduler from 10s to 30s. And he expand how many hosts are unhandled
  • /usr/share/dashing-icinga2/lib/icinga2-lib.rb
    there are also adjustments in this file to match
  • Cronjob:
    He can’t remember 100%, but what he knew is at the beginning sometimes dashing wasn’t working everytime correct. Before we noticed this too late and have to restart the service, he created a cronjob.