[dev.icinga.com #2131] In ServiceStatus Cronk only the first Host with problematic Services is displayed:

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/2131

Created by armin on 2011-12-01 08:38:34 +00:00

Assignee: jmosshammer
Status: Closed (closed on 2012-02-23 13:46:15 +00:00)
Target Version: 1.6.2
Last Update: 2012-02-23 13:46:15 +00:00 (in Redmine)

---

I have 3 Hosts with Warning Services which is correctly displayed in the status cronk, but only one host (the first in alphapetical order) is displayed in the ServiceStatus Cronk (Debian Squeeze with Icinga 1.5.1 from squeeze backports and latest 1.6 icinga-web. I had the same problem with 1.5.1 and 1.5.2 icinga-web).
Also like in Bug 2126 the Hostgrouping is lost after navigating through the OK, Warning and Error ServiceState Cronks.

I have a working system for testing (1.5.2) but if i change the database.xml to point to the production system it has the same error, so it is difficult for me to locate the error.

I have logged the queries in mysql, the first looks right and finds all open warnings:

SELECT DISTINCT i.object_id AS i__object_id, i.object_id AS 
i__object_id, i.name2 AS i__name2, i2.icon_image AS i2__icon_image, 
i2.display_name AS i2__display_name, i2.instance_id AS i2__instance_id, 
i3.alias AS i3__alias, i3.display_name AS i3__display_name, 
i5.current_state AS i5__current_state, i5.last_check AS i5__last_check, 
i5.current_check_attempt AS i5__current_check_attempt, i5.output AS 
i5__output, i5.max_check_attempts AS i5__max_check_attempts, i6.name1 AS 
i6__name1, i6.object_id AS i6__object_id, i6.name1 AS i6__name1, 
i7.instance_name AS i7__instance_name, i6.name1 AS i6__0, i2.icon_image 
AS i2__1, i7.instance_name AS i7__2, i6.object_id AS i6__3, i.object_id 
AS i__4, i6.name1 AS i6__5, i3.alias AS i3__5, i3.display_name AS i3__6, 
i.name2 AS i__7, i2.display_name AS i2__8, i5.current_state AS i5__9, 
i5.last_check AS i5__10, i5.current_check_attempt AS i5__11, i5.output 
AS i5__12, i5.max_check_attempts AS i5__13, i2.instance_id AS i2__14, 
(i5.has_been_checked-i5.should_be_scheduled)*-1 AS i__15, 
(i5.has_been_checked-i5.should_be_scheduled)*-1 AS i__16, 
(i5.has_been_checked-i5.should_be_scheduled)*-1 AS i__17, 
(i5.has_been_checked-i5.should_be_scheduled)*-1 AS i__17 FROM 
icinga_objects i INNER JOIN icinga_services i2 ON i.object_id = 
i2.service_object_id INNER JOIN icinga_hosts i3 ON i2.host_object_id = 
i3.host_object_id LEFT JOIN icinga_hoststatus i4 ON i3.host_object_id = 
i4.host_object_id LEFT JOIN icinga_servicestatus i5 ON 
i2.service_object_id = i5.service_object_id INNER JOIN icinga_objects i6 
ON i3.host_object_id = i6.object_id INNER JOIN icinga_instances i7 ON 
i2.instance_id = i7.instance_id WHERE ((i5.current_state = '1' AND 
(i5.has_been_checked-i5.should_be_scheduled)*-1 <= '0') AND 
i2.config_type = '1' AND i.is_active = 1) ORDER BY i6.name1 ASC LIMIT 25

the second query should have all Service ID's as criteria in the "WHERE (i.service_object_id IN ('977'))" clause i think but it only has one:

SELECT i.servicestatus_id AS i__servicestatus_id, i.instance_id AS 
i__instance_id, i.service_object_id AS i__service_object_id, 
i.status_update_time AS i__status_update_time, i.output AS i__output, 
i.long_output AS i__long_output, i.perfdata AS i__perfdata, 
i.current_state AS i__current_state, i.has_been_checked AS 
i__has_been_checked, i.should_be_scheduled AS i__should_be_scheduled, 
i.current_check_attempt AS i__current_check_attempt, 
i.max_check_attempts AS i__max_check_attempts, i.last_check AS 
i__last_check, i.next_check AS i__next_check, i.check_type AS 
i__check_type, i.last_state_change AS i__last_state_change, 
i.last_hard_state_change AS i__last_hard_state_change, i.last_hard_state 
AS i__last_hard_state, i.last_time_ok AS i__last_time_ok, 
i.last_time_warning AS i__last_time_warning, i.last_time_unknown AS 
i__last_time_unknown, i.last_time_critical AS i__last_time_critical, 
i.state_type AS i__state_type, i.last_notification AS 
i__last_notification, i.next_notification AS i__next_notification, 
i.no_more_notifications AS i__no_more_notifications, 
i.notifications_enabled AS i__notifications_enabled, 
i.problem_has_been_acknowledged AS i__problem_has_been_acknowledged, 
i.acknowledgement_type AS i__acknowledgement_type, 
i.current_notification_number AS i__current_notification_number, 
i.passive_checks_enabled AS i__passive_checks_enabled, 
i.active_checks_enabled AS i__active_checks_enabled, 
i.event_handler_enabled AS i__event_handler_enabled, 
i.flap_detection_enabled AS i__flap_detection_enabled, i.is_flapping AS 
i__is_flapping, i.percent_state_change AS i__percent_state_change, 
i.latency AS i__latency, i.execution_time AS i__execution_time, 
i.scheduled_downtime_depth AS i__scheduled_downtime_depth, 
i.failure_prediction_enabled AS i__failure_prediction_enabled, 
i.process_performance_data AS i__process_performance_data, 
i.obsess_over_service AS i__obsess_over_service, 
i.modified_service_attributes AS i__modified_service_attributes, 
i.event_handler AS i__event_handler, i.check_command AS 
i__check_command, i.normal_check_interval AS i__normal_check_interval, 
i.retry_check_interval AS i__retry_check_interval, 
i.check_timeperiod_object_id AS i__check_timeperiod_object_id FROM 
icinga_servicestatus i WHERE (i.service_object_id IN ('977'))

---

Relations:

• relates #2131

[icinga-migration]

Updated by armin on 2011-12-01 14:08:06 +00:00

It may has to do with json under Debian:

http://www.nagios-portal.org/wbb/index.php?page=Thread&threadID=24239
http://www.nagios-portal.org/wbb/index.php?page=Thread&threadID=24205

I will try the virtual applicance with my database.

[icinga-migration]

Updated by armin on 2011-12-02 11:32:51 +00:00

Tried in CentOS, same behavior, i spent days in searching for the error, no luck.
Can it be a problem with the data in the SQL Database?

[icinga-migration]

Updated by armin on 2011-12-12 11:13:20 +00:00

I found the reason for the error, it has to do with "check_multi", if i enable the option "-r 2" several HTML Tags are added to the Output of a Plugin and stored in the Table "icinga_servicestatus.output", Icinga has Problems with the verbose Output, as a second result the column "Duration" displays a "0" value as result for the only row displayed in the cronk as described above.
Would be nice if someone could fix this behavior.

[icinga-migration]

Updated by armin on 2011-12-12 13:47:21 +00:00

The type of the field "icinga_servicestatus.output" in the icinga Database is "varchar(255)" and is to short for the output of "check_multi -r 2". In my testsystem the type of the field is "text" and it works with the "-r 2" option.
On the testsystem i have upgraded NDOUtils with the Icinga Scripts to 1.5 database version, looks like the field was of type "text" in NDOUtils since i have not found a update statement, so it would make sense to change the type of the Database field to "text".

[icinga-migration]

Updated by mfriedrich on 2011-12-12 13:55:38 +00:00

check #2181 .. if you got any upgrade sqls / patches, much appreciated - pls attach them over there.

[icinga-migration]

Updated by armin on 2011-12-13 14:45:59 +00:00

I have updated my IDO Database, may you could include the following Database Update in new idodb versions:

ALTER TABLE `icinga_servicestatus` MODIFY COLUMN `output` text NULL;

Please close the issue when done!

[icinga-migration]

Updated by mhein on 2012-01-20 11:42:03 +00:00

• Assigned to set to jmosshammer
• Target Version set to 1.7

[icinga-migration]

Updated by mhein on 2012-02-10 09:23:13 +00:00

• Target Version changed from 1.7 to 1.6.2

[icinga-migration]

Updated by jmosshammer on 2012-02-23 13:46:15 +00:00

• Status changed from New to Closed

See #2181 for further development (and thanks for the db-query)