Feature #9795

Improvement in the hook that updates check_mk from the ENC so that it does not always reinventorize

Added by Gerard Bernabeu Altayo over 5 years ago. Updated over 5 years ago.

Start date:
Due date:
% Done:


Estimated time:


The original request lives in RITM0252925, but since as of today (August 5th 2015) the ENC/check_mk integration has no owner anymore it is hard to keep a SNOW ticket open. I'll copy&paste here.

Sorry for having created an incident, I thought the ENC was only updating check_mk when necessary.

Since I have not made any change on the nodes ENC check_mk config, it
should not be reinventorized automatically.

In short: how would the script know this? The design is to
re-check every time the ENC is updated.

Is the re-inventory actually causing any problems?

Yes because:

1) Make ENC updates very slow
2) Remove ACKs (not sure if downtimes too) associated with the alerts
3) Removes checks in an uncontrolled way at times.
- I have already realized about problems a few times thanks to check_mk showing a node is missing a check (eg: missing mount, missing GUMS checks).

Tim explained how the hook works today:

When you make a change to a host in the ENC, the hook between the
ENC and check_mk will update the node data in check_mk. This is the
desired behaviour, from my perspective.
That said, it's your service; if you don't want that, your options
pretty much boil down to:
1.  Stop the re-inventory in all cases.
2. Turn off the hook.
3. Write and deploy something new. (I don't have any suggestions
In any case, I don't think that this is my bailiwick anymore, and
it's certainly not ECF-CIS's bailiwick. Incidents and RITMs associated
with this issue are simply not appropriate.
- Tim Skirvin ()

In my opinion there is still another option which is make the hook smart enough so that it only triggers the check_mk workflow whenever "checkmk_.*" variables are updated/added/removed in the ENC entries.


#1 Updated by Gerard Bernabeu Altayo over 5 years ago

Another email from Tim:

For what it's worth, I've put this into something resembling a
feature request in omdclient. I say "something resembling" because it's
far shy of an actual feature request tool:
The same file is in our local copy (git@cms-git:omdclient).  I
don't know how maintaining this package fits into the current world.
If you have cycles to hack on it, please feel free to do so!

#2 Updated by Gerard Bernabeu Altayo over 5 years ago

Another example on why the current is a very bad operational behaviour is that when setting nodes on and off repair status we update the ENC, this causes the node to be reinventorized thus it loses all its checks...

At least WATO gives us a way to stop it by discarding the changes instead of applying...

Also available in: Atom PDF