Hi, I already talk about problems/incidents in a previous email. It's a way to port the correlation we have in the notification part to the "real time" monitoring too. We raise notification only for the root problem (a gateway down, not for all servers behind it) if the user do not set unreachable (and I think it's an error to set it).
Now it can be cool to have this for the real time console monitoring : unreach hosts will be put in UNREACH state when we know that the gateway is down, not when we wait for this host to be check (we know that the check will fail!). When the gateway will be UP, we will remove the state (if there are no another problem on it of course). same with services but in unknown state. I look great, but it call for some questions: *enable it as a default behavior? I think it's a cool thing to have by default, and I do not see why put the disable parameter in fact. *just raise the status for HARD states? I think it's safer to do it, it will less "flap" in the console. *if a check came if the service is "in incident", should we keep the the unknown state, or put the one of the plugins? (for host, it will be in unreach, so it's ok). I think we can put the one of the plugin. Standard behavior for CPU likes checks should be unknown for connexion problem, not critical (-u of check_nrpe). For the output, more than just states, It can be cool to export list of problems/incidents for webinterfaces. I'll add it in the livestatus module (so add new "tables"). It's not supported officially in the livestatus protocol, so until we have such support, this feature will stay as experimental. What do you think of this? Jean ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Shinken-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shinken-devel
