I’ve the strange problem that no hosts or services are shown in my icingaweb2 GUI.
I’ve a HA Master and HA Satellite setup. The endpoints are listed correctly, when I run the “icinga2 object list --type Endpoint” command on the servers.
The config check (icinga2 daemon -C) shows the correct number of host.
I validated the configurations (e.g resources )on the icingaweb2 GUI and they are working properly.
SELinux is disabled and I disabled the firewall for testing.
The debug log also is not showing any usefull output.
debug log: [2020-02-13 10:09:30 +0100] notice/ApiListener: Current zone master: srv-icinga-master1.thaja.local [2020-02-13 10:09:30 +0100] notice/ApiListener: Connected endpoints: srv-icinga-master2.thaja.local (1), srv-icinga-satellite2.thaja.local (1) and srv-icinga-satellite1.thaja.local (1) [2020-02-13 10:09:31 +0100] notice/JsonRpcConnection: Received ‘event::Heartbeat’ message from identity ‘srv-icinga-satellite2.thaja.local’. [2020-02-13 10:09:31 +0100] notice/JsonRpcConnection: Received ‘event::Heartbeat’ message from identity ‘srv-icinga-satellite1.thaja.local’. [2020-02-13 10:09:31 +0100] notice/JsonRpcConnection: Received ‘log::SetLogPosition’ message from identity ‘srv-icinga-satellite2.thaja.local’. [2020-02-13 10:09:32 +0100] notice/JsonRpcConnection: Received ‘log::SetLogPosition’ message from identity ‘srv-icinga-master2.thaja.local’. [2020-02-13 10:09:32 +0100] notice/JsonRpcConnection: Received ‘event::Heartbeat’ message from identity ‘srv-icinga-master2.thaja.local’. [2020-02-13 10:09:32 +0100] notice/JsonRpcConnection: Received ‘log::SetLogPosition’ message from identity ‘srv-icinga-satellite1.thaja.local’.
how you configured your monitoring backend and your command transport? Maybe here is something wrong or something happend there. e.g. if your command transport would be api, is your api user still configured?
ok, if you use the directory “conf.d” for your configuration be sure, that this is NOT excluded in /etc/icinga2/icinga2.conf!! Because in the docs is often recommanded not to use this directory! Because here you find example configurations and can be overwritten during an update!
Better to use “api.conf” from “/etc/icinga2/features-available” and be sure you have enebled the api feature with icinga2 feature enable api
And you also test the api user with the url you wrote in /etc/icingaweb2/modules/monitoring/commandtransports.ini
So your test should be not with localhost, it should be like
curl -k -s -u icingaweb2:PASSWORD ‘https:// srv-icinga-master1.thaja.local:5665/v1’
in your case
Maybe because there are no actions to log. Try to click arround to see actions in the log file.
try to do simple things in icingaweb2 like creating users, set permissions to test if icingaweb2 write entries in the file.
While doeing this you could also check the permissions of your web users
icinga2 - The Icinga 2 network monitoring daemon (version: 2.11.2-1)
Copyright (c) 2012-2020 Icinga GmbH (https://icinga.com/)
License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl2.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
System information:
Platform: CentOS Linux
Platform version: 7 (Core)
Kernel: Linux
Kernel version: 3.10.0-1062.el7.x86_64
Architecture: x86_64
Build information:
Compiler: GNU 4.8.5
Build host: runner-LTrJQZ9N-project-322-concurrent-0
Application information:
General paths:
Config directory: /etc/icinga2
Data directory: /var/lib/icinga2
Log directory: /var/log/icinga2
Cache directory: /var/cache/icinga2
Spool directory: /var/spool/icinga2
Run directory: /run/icinga2
Old paths (deprecated):
Installation root: /usr
Sysconf directory: /etc
Run directory (base): /run
Local state directory: /var
Internal paths:
Package data directory: /usr/share/icinga2
State path: /var/lib/icinga2/icinga2.state
Modified attributes path: /var/lib/icinga2/modified-attributes.conf
Objects path: /var/cache/icinga2/icinga2.debug
Vars path: /var/cache/icinga2/icinga2.vars
PID path: /run/icinga2/icinga2.pid
The IDO was feature was active on both masters, so I disabled it on the first one.
The mysql query gave me the needed output, as mentioned in the documents with the update every 10 seconds.
In the authentication config there was only my admin user with administrative rights, who is currently logged in.
Uhm, that shouldn’t be the case with this configuration. The IDO feature will be paused on one master, but still be activated. If you have that now disabled via feature command, the HA failover will not work.
Without knowing and see your environment I’m out of ideas. But I’m sure @dnsmichi have ideas. I wish you luck to fix it. I’m also still interested what the problem was.