No host or service shown on the icingaweb2 gui

Icinga Web
21

I’m a friend of isolating problems into smaller parts. In my experience not so many people do that and overcomplicate troubleshooting.

  • [x] The HA cluster works
  • [x] The IDO programstatus table is uptodate
  • [ ] There is actual data inside the IDO database for host objects
  • [x] User administrative role in web

Yet I am not sure what to do if there is data inside the DB from those queries. I would purge the roles and start testing with a new user.

Cheers,
Michael

22

I got no entry for the JSON export. This is the output:

For SQL I get a long query, but it seems to be nothing interesting.

QUERY

SELECT so.name1 AS host_name, h.display_name COLLATE latin1_general_ci AS
host_display_name, CASE WHEN hs.has_been_checked = 0 OR hs.has_been_checked
IS NULL THEN 99 ELSE hs.current_state END AS host_state, so.name2 AS
service_description, s.display_name COLLATE latin1_general_ci AS
service_display_name, CASE WHEN ss.has_been_checked = 0 OR
ss.has_been_checked IS NULL THEN 99 ELSE ss.current_state END AS
service_state, CASE WHEN (ss.scheduled_downtime_depth = 0 OR
ss.scheduled_downtime_depth IS NULL) THEN 0 ELSE 1 END AS
service_in_downtime, ss.problem_has_been_acknowledged AS
service_acknowledged, CASE WHEN (ss.problem_has_been_acknowledged +
ss.scheduled_downtime_depth + COALESCE(hs.current_state, 0)) > 0 THEN 1
ELSE 0 END AS service_handled, ss.output AS service_output, ss.perfdata AS
service_perfdata, ss.current_check_attempt || ‘/’ || ss.max_check_attempts
AS service_attempt, UNIX_TIMESTAMP(ss.last_state_change) AS
service_last_state_change, s.icon_image AS service_icon_image,
s.icon_image_alt AS service_icon_image_alt, ss.is_flapping AS
service_is_flapping, ss.state_type AS service_state_type, CASE WHEN
ss.current_state = 0 THEN CASE WHEN ss.has_been_checked = 0 OR
ss.has_been_checked IS NULL THEN 16 ELSE 0 END + CASE WHEN
ss.problem_has_been_acknowledged = 1 THEN 2 ELSE CASE WHEN
ss.scheduled_downtime_depth > 0 THEN 1 ELSE 4 END END ELSE CASE WHEN
ss.has_been_checked = 0 OR ss.has_been_checked IS NULL THEN 16 WHEN
ss.current_state = 1 THEN 32 WHEN ss.current_state = 2 THEN 128 WHEN
ss.current_state = 3 THEN 64 ELSE 256 END + CASE WHEN hs.current_state > 0
THEN 1024 ELSE CASE WHEN ss.problem_has_been_acknowledged = 1 THEN 512 ELSE
CASE WHEN ss.scheduled_downtime_depth > 0 THEN 256 ELSE 2048 END END END
END AS service_severity, ss.notifications_enabled AS
service_notifications_enabled, ss.active_checks_enabled AS
service_active_checks_enabled, ss.passive_checks_enabled AS
service_passive_checks_enabled, ss.check_command AS service_check_command,
CASE WHEN ss.has_been_checked = 0 OR ss.has_been_checked IS NULL THEN CASE
ss.should_be_scheduled WHEN 1 THEN UNIX_TIMESTAMP(ss.next_check) +
(ss.normal_check_interval * 60) ELSE NULL END ELSE

Unfortunately I 'cant post more it’s get stuck in the loading progress. Let me know if it’s something interesting then I will try to post the rest of the SQL.

BR
Thaja

23

You should use that SQL query and fire it manually against your database. Post the results from it, if there are any findings.

Also, at this stage, enable debug logging and inspect if there are any errors from the Icinga Web side.

Cheers,
Michael

24

There were 2 SQL queries on the export.

The first one which actually should list my checks and and hosts, gave me no output.

Empty set, 1 warning (0.00 sec)

The second one should count my hosts and give me the number of quantity.

±----+
| cnt |
±----+
| 0 |
±----+

I think there is a problem with the database, that it is not getting information from the master.
Do you know where I can start investigating ?

25

Since it mentions a warning, run SHOW WARNINGS; after executing the query immediately.

26

show warnings;

±--------±-----±---------------------------------------+
| Level | Code | Message |
±--------±-----±---------------------------------------+
| Warning | 1292 | Truncated incorrect INTEGER value: ‘/’ |
±--------±-----±---------------------------------------+
1 row in set (0.00 sec)

27

Hi Guys

So, I found out that the DB is connected to the secondary master and somehow the secondary master doesn’t write any configs to the DB. But in the debug log on master2 there are IdoMysql Connections entries.
I think somehow the second master doesn’t get any configuration from the master1. Do you know what could be wrong? Do I need to set the accept_config attribute in /etc/icinga2/feature-enabled/api.conf to true on the master2, that it can receive config from master1?

When I shutdown the master2 the failover of the db connection to master 1 works fine, and it shows the hosts in the GUI, so master1 can successfully write the config to the db.
I actually thought that the secondary master only connects to the db if the primary fails, or am I wrong? Do I need to set a specific attribute on the primary master?

This is my ido-mysql.conf on both masters.

master1:

object IdoMysqlConnection “ido-mysql” {
user = “icinga”
password = “PASSWORD”
host = “192.168.122.35”
port = 3306
database = “icinga”

master2:

object IdoMysqlConnection “ido-mysql” {
user = “icinga”
password = “PASSWORD”
host = “192.168.122.35”
port = 3306
database = “icinga”

Thanks for your help
BR
Thaja

28

ok, if you configured the database on an external server, you maybe forgot this the enable_ha option. Look at here https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#distributed-monitoring-high-availability-db-ido and here https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#distributed-monitoring-high-availability-db-ido

29

Do I need to enable_ha on both master oder just the primary one?
And what about the api.conf on the secondary master, set the accept_config to true or false ?

30

from the docs:

enable_ha:

Note : The DB IDO HA feature can be disabled by setting the enable_ha attribute to false for the IdoMysqlConnection or IdoPgsqlConnection object on all nodes in the same zone.

accpet_config:

Note

Cluster nodes must accept configuration for creating, modifying and deleting objects. Ensure that accept_config is set to true in the ApiListener object on each node.

31

Thanks this helped.
Now I can see the host entries even though the icingaweb2 is connected to the secondary master.
Do you know how I can configure that the primary master will be chosen for the icingaweb2 connection, so that the secondary master works as a fallback?

BR
Thaja

32

Nice to hear that is working now.

If you have your icingaweb2 DB on the same DB-server it should work. You only have to sync the dashboard.ini files from each user to the second master. Because if one user creates his own dashboard it is not saved in the db, it is saved in that .ini-files in /etc/icingaweb2/dashboards. We are doing this task with a cron job and scp.