No host or service shown on the icingaweb2 gui

Icinga Web 2
13

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

14

I tested a little bit but nothing special happend.
Even when I configure a local transport it is not showing any hosts on the GUI.

15

Hi,

more details needed.

  • icinga2 --version
  • zones.conf from both masters
  • icinga2 feature list
  • cat /etc/icinga2/features-enabled/ido-mysql.conf from both masters (replace sensitive details).
  • cat /etc/icingaweb2/resources.ini (remove sensitive details)
  • cat /etc/icingaweb2/module/monitoring/backends.ini

Cheers,
Michael

16

Hi Michael

icinga2 --version

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

icinga2 feature

Disabled features: command compatlog elasticsearch gelf graphite influxdb livestatus opentsdb perfdata statusdata syslog
Enabled features: api checker debuglog ido-mysql mainlog notification

ido-mysql master1:

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

ido-mysql master2:

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

resources.ini

[icingaweb_db]
type = “db”
db = “mysql”
host = “192.168.122.35”
port = “”
dbname = “icingaweb2”
username = “icingaweb2”
password = “PASSWORD”
charset =“”
use_ssl = “0”
[icinga_ido]
type = “db”
db = “mysql”
host = “192.168.122.35”
port = “”
dbname = “icinga”
username = “icinga”
password = “PASSWORD”
charset =“”
use_ssl = “0”

backends.ini

[icinga]
type = “ido”
resource = “icinga_ido”

FYI: I have a seperate DB server with the IP 192.168.122.35
BR
Thaja

17

Hi,

thanks, looks fine to me. The HA cluster should then have the IDO feature active on one master, likely master2.

Can you verify whether the database is being updated accordingly, e.g. with running the mentioned query here?

Also, which user is currently logged in, and which roles are configured in Icinga Web 2 for this user?
Configuration > Authentication > Roles

Cheers,
Michael

18

Good Morning

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.

Hosts still not appeard :confused:

BR
Thaja

19

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.

Icinga Web 2 has specific status views which allow to export them as JSON, CSV. You can also add format=sql to the URL and extract the executed SQL. https://icinga.com/docs/icingaweb2/latest/doc/20-Advanced-Topics/#global-url-parameters

Use that to manually query the database and see what happens. Post your findings in detail here.

Cheers,
Michael

20

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.

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

1 Like
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.

1 Like
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

1 Like
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.