On 07.03.2013 09:58, Marko Vainiokangas wrote: > At the moment IDOMOD will log into the database any statechanges,
idomod registers a neb callback function, which gets triggered when the core receives any state change event. so the actual control about a change in that area is still based on the core itsself while idomod just receives the data for the state change itsself. for code specific regions, check base/checks.c|sehandlers.c|broker.c starting with the calls to handle_service_event() upon (hard_)state_change. > however, that’s based on the warning and critical levels set on the > check (from what I can see). the logic on state changes itsself is based on what state the plugin returns. so if the thresholds match some warning or critical condition, the plugin will return the state which then the core processes and tests whether a state change happened or not. the core itsself does not care about the plugin thresholds but only calls the check command itsself, according to your configuration. > > Even if there’s a large variation in the results, it’s still not > interpreted as a statechange. the plugin api defines the exit state of a plugin. which is then the condition for a state change happening. there's no method of "diff the last and current check output and overwrite a state", as it does not make sense to let the inner core logic decide which output is right and which is wrong. the plugins are responsible for applying thresholds, and therefore returning the proper state. the output is just the verbose information on the state. http://docs.icinga.org/latest/en/pluginapi.html > > For instance if the service is OK, but the CPU load is just below the > warning level, it’s not displayed in the icinga_statehistory log. Even > if for instance there’s a 27% cpu load for 8 hours but the last state > change was at 3% it’s last entry will be 3% in the icinga_statehistory > table. if the plugin does not trigger the threshold, returning a different state than OK, how would icinga core then know which state the check should be in? and since the core does not know anything about the thresholds and plugins called, idomod won't receive any state change updates, and so does ido2db not write any updates/inserts to the database in the statehistory table. > > And icinga_logentries isn’t connected to object_ids so pulling out the > actual reported values from the checks means building a parser, which > has already been done in idomod. adding a grep on the log entry line which host or service object this would be, would likely kill everyones performance when just inserting log lines which could still be read as "line by line" insert. idomod doesn't know the object ids which will be required for linking, and passing the host name / service description for a further lookup of the object_id will cause another select onto the database before actually inserting the data. given the current architecture and implementation, it might be easy to add, but will slow down the faster events (like events, logs, checks) and the overall outcome will be more performance loss than gaining better results. imho suchs logs should be processed by external tools capable of a more deep down logic and api on parsing log data and doing the reporting with it. though, if you know better ways to connect such data in a more compliant way, feel free to provide a patch. i just don't see the general benefit with just connecting log entries with objects in order to resolve the "not happened state change, but only output changed" issue. you might also need some sort of filtering logic then, not only for which host or service objects, but also in regards of which states and state changes would be affected and which are not. > > Would it be possible to add a flag in the idomod.cfg or similar location > to always add an icinga_statehistory entry if the long_output differs > from the previous entry? you are actually talking about _output_ changes, and not _state_ changes. which is a totally different story here, as it affects different parts, especially the backend database tables. the thing you are likely referring to, is "stalking", which is, generally speaking, the attempt to watch "same state, no state change, different output". which is not stored in any backend as state change (because it isn't!), but a log entry and normally only allows to trigger on demand log/eventhandlers/notifications. http://docs.icinga.org/latest/en/stalking.html let's assume, you'd have an entry for a state change in the core, when the output is different. how would this be compatible with a.) the core itsself, based on the alert and notification logic b.) the data integrity in the state change table (a change of an output isn't really a state change, is it?) c.) how would external tools, like icinga reporting, treat such new data within the current implementation? c.) is the most important part. breaking existing data structures must not even happen with a config flag, only in +1 versions (like Icinga2 could do) in general, i do understand the need for output changes, given the same state for a long time. but given the current implementation, i doubt this would make sense as implementation, is it either breaks on performance or compatibility with changes here. anyways, if you have anything implemented and want to discuss further on your attempts, feel free to share them here. kind regards, michael -- DI (FH) Michael Friedrich mail: michael.friedr...@gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmi...@jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ icinga-users mailing list icinga-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/icinga-users
