Bug #371

Pending States in Icinga-web

Added by mstreb about 4 years ago. Updated over 2 years ago.

Status:ResolvedStart date:04/08/2010
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:1.2 (Stable)
Icinga Version: DB Type:
Icinga Web Version: DB Version:
IDO Version: Browser Version:
OS Version:

Description

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

History

#1 Updated by mhein almost 4 years ago

  • Target version set to 1.0.3

#2 Updated by mstreb over 3 years ago

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

#3 Updated by TheFlyingCorpse over 3 years ago

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.

#4 Updated by dnsmichi over 3 years ago

  • 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_enabled==0 && next_check!=datetime(0) && check_options==forced
===========> 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.

#5 Updated by mhein over 3 years ago

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.

#6 Updated by mhein over 3 years ago

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.

#7 Updated by jmosshammer over 3 years ago

  • Status changed from New to Resolved

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

#8 Updated by theh over 2 years ago

Still a problem in 1.5.2.

Also available in: Atom PDF