[dev.icinga.com #371] Pending States in Icinga-web #58

Closed
icinga-migration opened this Issue Apr 8, 2010 · 8 comments

Projects

None yet

1 participant

@icinga-migration
Member

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

Created by mstreb on 2010-04-08 14:39:53 +00:00

Assignee: (none)
Status: Resolved (closed on 2010-09-14 07:32:14 +00:00)
Target Version: 1.2 (Stable)
Last Update: 2011-09-16 15:51:16 +00:00 (in Redmine)


Hosts/Services in Pending State are not viewable in icinga-web, i think we should change this.

@icinga-migration
Member

Updated by mhein on 2010-06-04 13:42:20 +00:00

  • Target Version set to 1.0.3
@icinga-migration
Member

Updated by mstreb on 2010-08-12 09:14:42 +00:00

i have to bump this, it is a feature which should be included in one of the next releases

admins who used the old nagios/icinga webinterface are totally confused about this missing services.
also it is not directly possible to reschedule this checks, only via "reschedule all checks on this host" which is not the best way to do

@icinga-migration
Member

Updated by Anonymous on 2010-08-12 11:32:22 +00:00

Hmm, I dont think Icinga Web currently has support.

What would also need changing for this to work is changing IDOUTILS so it parses the config + the services that are not yet filled with any checkdata.
The Pending state is a state thats not filled with a numeric value, I think the value of the state is NULL.

@icinga-migration
Member

Updated by mfriedrich on 2010-08-12 12:05:24 +00:00

  • Target Version changed from 1.0.3 to 1.2 (Stable)

there is the need to build your own logic based on different selections how the HOST|SERVICE_PENDING would look like.

the core handles that like this:

common/statusdata.c:348

                if(new_hoststatus->has_been_checked==FALSE){
                        if(use_pending_states==TRUE)
                                new_hoststatus->status=HOST_PENDING;

so only if pending states are enabled, this will be actually set to pending, and the status attribute of the hoststatus can be NULL or 0 or 1 (check the #defines for *PENDING)

basically in this regard, the database knows about the following columns to be selected and created pending states:

  has_been_checked number(6) default 0 NOT NULL,
  should_be_scheduled number(6) default 0 NOT NULL,

  last_check date default TO_DATE('1970-01-01 00:00:00','YYYY-MM-DD HH24:MI:SS') NOT NULL,
  next_check date default TO_DATE('1970-01-01 00:00:00','YYYY-MM-DD HH24:MI:SS') NOT NULL,

building the logic once more:

  • has_been_checked==0
    true

=> should_be_scheduled==1
=> true => get next_check, print "check scheduled on $next_check"

=> false => checks_enabled0 && next_check!=datetime(0) && check_optionsforced
=> true => get next_check, print "forced check scheduled on $next_check"
=> false => print "not scheduled to be checked"

this is sth for the api in regard of the logic, the output can be generalized by icinga-web, but should be the same like classicui/core provides.

@icinga-migration
Member

Updated by mhein on 2010-08-25 07:54:18 +00:00

Is this state really in database?

I think we'll get some problems because there are no results in the database. You have to rewrite the API with left joins on the current status side.

LG Marius.

@icinga-migration
Member

Updated by mhein on 2010-09-10 09:07:46 +00:00

select * from icinga_servicestatus where service_object_id=1512 \G

* 1. row*
servicestatus_id: 257920
instance_id: 1
service_object_id: 1512
status_update_time: 2010-09-10 10:43:02
output:
long_output:
perfdata:
current_state: 0
has_been_checked: 0
should_be_scheduled: 1
current_check_attempt: 1
max_check_attempts: 3
last_check: 1970-01-01 01:00:00
next_check: 2010-09-10 10:52:13
check_type: 0
last_state_change: 1970-01-01 01:00:00
last_hard_state_change: 1970-01-01 01:00:00
last_hard_state: 0
last_time_ok: 1970-01-01 01:00:00
last_time_warning: 1970-01-01 01:00:00
last_time_unknown: 1970-01-01 01:00:00
last_time_critical: 1970-01-01 01:00:00
state_type: 1
last_notification: 1970-01-01 01:00:00
next_notification: 1970-01-01 01:00:00
no_more_notifications: 0
notifications_enabled: 1problem_has_been_acknowledged: 0
acknowledgement_type: 0
current_notification_number: 0
passive_checks_enabled: 1
active_checks_enabled: 1
event_handler_enabled: 1
flap_detection_enabled: 1
is_flapping: 0
percent_state_change: 0
latency: 0
execution_time: 0
scheduled_downtime_depth: 0
failure_prediction_enabled: 1
process_performance_data: 1
obsess_over_service: 1
modified_service_attributes: 0
event_handler:
check_command: check_nrpe_windows_uptime
normal_check_interval: 10
retry_check_interval: 2

has_been_checked and should_be_scheduled are our friends I think

LG Marius.

@icinga-migration
Member

Updated by jmosshammer on 2010-09-14 07:32:14 +00:00

  • Status changed from New to Resolved

Pending states are now visible in hoststatus, servicestatus and open problems view

@icinga-migration
Member

Updated by theh on 2011-09-16 15:51:16 +00:00

Still a problem in 1.5.2.

@icinga-migration icinga-migration added this to the 1.2 (Stable) milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment