Beta multisite, Auto/Updates, low hanging fruit?

General
, ,
#1

Hello! Thank you for your patience - our team has grown to like CheckMK. I am starting to learn as much as I can. But I have many questions that the forums and Google can’t seem to answer.

First - is it safe to run the v2 Beta in multi-instance (multisite)? Can one agent report back to two difference instances? Sorry, I couldn’t easily find these confirmed other than the instance needs to be strictly newer than the agent. I’m quite keen to see how v2 looks and feels.

Second; as I understand, the instance knows the CheckMK host name, and reaches out to register and monitor the host. Setting up a baked agent its the host instead needs to know the CheckMK host name, a password, and register back to the instance? Is there an option for CheckMK to reach out and perform this step instead? I don’t see any way to automate this at agent install without distributing a password and without the ‘CheckMK host name’.

Third - what is the greatest overlooked features tips or plugins of CheckMK that people forget to use? Overlooked “low hanging fruit” as such! :grin: I’m always fascinated by what people have learned and what newbies miss.

Thank you for your kind help!

Gene.

#2

What do you mean with “safe”? It is beta software and this means some feature can change until release or there can be bugs.

Technically the agent don’t report back to some server/instance. It is only queried by the instance. Inside the agent you can configure if it only should answer a single IP or many or all. All information about the agent can be found here The agent for Windows in detail and The agent for Linux in detail

In the normal environment there is no registration. CMK only needs an IP or an name instead of IP that is resolvable. The whole procedure of agent registration for automatic update (that is the only reason for the registration) is described here Distribute agents and plug-ins automatically
If you do this with a script you should create an automation user with only the right to register the agent. With this user it is no problem to have a password (secret for automation users) in clear text inside your script.

2 Likes
#3

Thanks. Agents being queried by two instances is quite … interesting!

I think this answers why the updater is registered from the agent end. Otherwise two instances would be able to enforce their version of the agent and scripts.

Apologies - with a script and an automation user I would still need to know the correct ‘checkmk host name’ for the agent? I couldn’t see how to automate that specific part post agent install.

It says “not for use in productive environments”. Can we ‘just’ run the beta as an Instance or is it recommended we set up a separate ODM host so bugs can’t influence the prod instance?

Would you recommend against using the beta instance to contact existing [dev] agents - could a bug cause issues to the host or to the prod instance getting its monitoring?

#4

There is no problem to have different instances on one host. I have also some systems with 3-4 different versions on the same machine.

For the registration problem. How many productive systems do you have? I my case most times only one system deploys the agent and other systems can also query data from the agent. So only you need to know the one systems where you need to register the agent deployment for automation of agent installation.

#5

Currently 150 hosts (to migrate ~2000 from prior monitoring) not including cloud. So not big, often just awkward when only monitoring allowed. We just have the one server.

I’m still unsure how to automate getting " Our host name in the monitoring: myhost " needed from the example. Do you just assume that it is perfect match to %COMPUTERNAME% with no name clash?

#6

It would be good if you have the same name in monitoring as in real life :slight_smile:
More important is that the hostnames inside your monitoring are case-sensitive.