I have set up the latest (1.6 beta) from icinga web with icinga 1.5.1
packages from debian, configuration is correct and ido2db is working,
the icinga-web status cronk is displaying all states correctly.
The only problem is if i click on "Warnings" or any other state button
on the status cronk which belongs to the services only one warning is
displayed in the service state area.
Choosing a button which belong to a hoststate everything is working fine.
I had the same problem with icinga-web 1.5.1 and 1.5.2, i figured out a
problem in the SQL Queries (logged on mysql server), so i think it is a
problem in icinga-web.
I have definiteley 3 services with warning states, if you check the
"where" clause of the following query there is only one service ID
listed but each service ID should be listed as criteria, there is always
only the first Warning in alphapetical order by the hostname:
(In advance, i have no filters activated in icinga-web.)
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'))
In the same Log i can find a other query before this query which lists
the correct list of the 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
I have a testing System with a 1.5.2 icinga-web version, this works as
expected, i changed the "database.xml" settings to point to the
production System and it has the same error, so it is quite difficult
where to search for the error, in ido database or in icinga-web.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/icinga-users
