Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #638] call unknown check result handler on passive checks from unknown hosts/services #319

Closed
icinga-migration opened this issue Jul 26, 2010 · 20 comments

Comments

@icinga-migration
Copy link

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

Created by bschmidt on 2010-07-26 10:02:55 +00:00

Assignee: (none)
Status: Closed (closed on 2012-07-31 19:27:19 +00:00)
Target Version: (none)
Last Update: 2012-07-31 19:27:19 +00:00 (in Redmine)


It would be very nice if Icinga not just log an error if a check result for an unknown passive check comes in, but call a "unknown check result handler" instead.

This would make it possible to handle check results for "til now" unknown hosts/services.

This leads to various options how we could handle such events.

For example we could

  1. categorize the check result and reinsert it (now mapped to a known host/service)
  2. create a config snippet to make it a known host/service (which could be useful if we have agents that do some autodiscovery)
  3. feed a kind of event database

This feature should be implemented like the notification commands.
Of course it should be optional - and be disabled by default.

Thanks,

Birger


Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-08-04 21:05:56 +00:00

  • Status changed from New to Assigned
  • Assigned to set to mfriedrich

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-08-09 20:51:40 +00:00

base/commands.c

passive hostchecks

        /* we couldn't find the host */
        if(temp_host==NULL){
                logit(NSLOG_RUNTIME_WARNING,TRUE,"Warning:  Passive check result was received for host '%s', but the host could not be found!\n",host_name);
                return ERROR;
                }

passive servicechecks

        /* we couldn't find the host */
        if(real_host_name==NULL){
                logit(NSLOG_RUNTIME_WARNING,TRUE,"Warning:  Passive check result was received for service '%s' on host '%s', but the host could not be found!\n",svc_description,host_name);
                return ERROR;
                }

        /* make sure the service exists */
        if((temp_service=find_service(real_host_name,svc_description))==NULL){
                logit(NSLOG_RUNTIME_WARNING,TRUE,"Warning:  Passive check result was received for service '%s' on host '%s', but the service could not be found!\n",svc_description,host_name);
                return ERROR;
                }

config options to set

passive_eventhandlers_for_wrong_hostcheck=0
passive_eventhandlers_for_wrong_servicecheck=0

same as
https://git.icinga.org/?p=icinga-core.git;a=commit;h=e859e553926fc5fcf366d72b253d40891537af6c

running

handle_host_event(hst);
handle_service_event(temp_service);

this needs eventhandlers defined for the passively defined host.

e.g. host {
...
event_handler detect-wrong-host
}

whereas detect-wrong-host will be called if the host defined in the passive check command does not fit. basically the script should then take the macros handed over.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-09-17 15:33:38 +00:00

  • Target Version set to 62

fits perfect into an unstable release.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-10-10 12:13:32 +00:00

  • Target Version changed from 62 to 1.3

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-01-04 17:11:20 +00:00

  • Target Version changed from 1.3 to 1.4

feature for 1.4, no time currently. anyone else interested though?

@icinga-migration
Copy link
Author

Updated by berk on 2011-02-14 08:42:07 +00:00

i think we need that as a workaround until we have a dynamic configurable core

@icinga-migration
Copy link
Author

Updated by pdeneu on 2011-02-14 08:45:06 +00:00

Excellent idea.
Would be very nice to add this feature to the core.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-02-14 08:47:12 +00:00

what is a "dynamic configurable core"? :p i've already declined a feature request on the feedback tracker regarding configurable states ;-)

but yes, that feature is on my todo list, just no time til now. possibly something for mike dupont? ;D

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-04-27 21:31:03 +00:00

  • Target Version changed from 1.4 to 1.5

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-05-27 16:19:07 +00:00

  • Status changed from Assigned to Feedback
  • Assigned to deleted mfriedrich
  • Target Version deleted 1.5

although it's an interesting feature, i don't have time for that. patches welcome - the algorithm above tells already more than necessary.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-06-29 14:19:29 +00:00

  • Target Version set to 1.5

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-07-12 18:47:52 +00:00

  • Target Version changed from 1.5 to 1.6

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-01 11:01:57 +00:00

doesn't work like proposed. can't assign that result handler to a non existing object. most likely this must be defined somewhere else, same as perfdata commands or similar.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-01 11:48:52 +00:00

  • Target Version deleted 1.6

furthermore, doing it with a command object defined, calling that withing reap check result won't work with macros, so how to pass host, service, checkresult to that command either way?
you may hardcode populating the macros and free them straight afterwards, but this would still need a lot of caution on the macros themselves. and is not a clean solution.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-01 11:50:12 +00:00

what comes to mind, would be a new callback for neb, telling that an unknown checkresult was received, passing a new struct with hostname, servicedesc and checkresult over there.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-12-01 23:01:37 +00:00

interesting. a user was just asking about a so called unconfigured objects strategy by a commercial product. what they do, is parsing the event log, creating a serialization database and provide that gui based to the user, allowing the addition of more passive checks. and event handler could possibly resolve the parsing and serialize problem.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-12-01 23:01:50 +00:00

  • Target Version set to 1.7

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-02-18 14:30:41 +00:00

the effective problem is, that this can't be implemented like notifications, because at the stage of parsing the passive check result, there is no object available, so no macros, no attributes, nothing but a host or host/service with some more checkresult attributes.

given that this handler must be a global command, perfdata commands come to mind, where you can define a command to be called when such a thing occurs.

the main problem will be, that those attributes of the checkresult itsself must be passed itsself as argument somehow in order to provide all the information to the handler. this can get complicated, if the command set is not a path to a binary, but a command definition itsself.
if it would be a call to a binary, we might need to define a syntax for that.

SERVICES
process_passive_service_check
time_t check_time,
char *host_name,
char *svc_description,
int return_code,
char *output

HOSTS
process_passive_host_check
time_t check_time,
char *host_name,
int return_code,
char *output

if we are doing so, we should also create the base shell script as an example and install that accordingly, to prevent users to create their own and failing. if we go the way with calling a script directly.

@birger
would that be an applicable solution?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-03 12:33:59 +00:00

  • Target Version deleted 1.7

since it requires more feedback, i'll remote the release target again.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-07-31 19:27:19 +00:00

  • Status changed from Feedback to Closed

as we cannot attach handlers to non-existant configobjects, someone would rather query a core api to see if it's there, or, after having handler configuration within icinga, defining such in a more general way.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant