OK so strange question here, as I am thinking there has to be a simpler solution.
I have a distributed topology, with a central server and then pollers in each of my datacenters… and I have auto registration working, but ONLY if I point the registering agent to my central server (I then have to do the TLS registration against it’s assigned site)
It seems like there should/would be a setting somewhere to say if I register to “site2” against the remote poller running that site, to tell the poller to simply proxy that request and forward it to the central server?
My first, and obvious solution here was to just re-enable configuration changes on the remote poller, but while this seems to fix the issue, hosts registered directly do not seem to propagate back to the central server, so I seem to NEED to perform the registration there, but am hoping there is a way to proxy these requests as otherwise this is a lot of firewall permits I need!
It’s not insurmountable, I am just trying to ensure I am not missing an easier way to do this…
Not sure I understand, what “auto registration” are you referring to? Checkmk does not have one.
I normally do the TLS registration FIRST but does not matter.
You need to do the Automatic updates registration towards your main site as far as I know. Why is that a problem?
Sorry I guess I could have been more clear! We have a script we have written that registers hosts using the “automation” account and the /check_mk/api/1.0 target (This all works today, but we realized we have to register to the central server which I just assumed had to be something I was not doing right.
We are running the community edition, and I ‘think’ the agent bakery is only in the enterprise edition?
Still I am compiling a list of benefits for potentially moving to Enterprise, so if this is the case (And the agent barkey will do what I need) it may be an option.
However it is important to note the majority of the time I am doing this is on new hosts that are spun up in AWS via ASG’s so the goal is o have the new host auto register with the CheckMK server, I think from past reading the bakery was targeted more at push deployment rather than pull?
Or can I just define a subnet and say “Any new hosts that spin up, push the client to them” which would be the inverse of what I am doing today, but as I think it through probably a lot easier to maintain…
Automatic agent updater registration (cmk-update-agent) which is the agent bakery itself
TLS registration (cmk-agent-ctl)
When you say auto-registration, I assume you mean the 2nd one where you are basically executing the following on all hosts after installing the package so that it can register against the site:
Here the site should be your monitoring instance where the host is being monitored. If you have a Distributed monitoring setup where there is a dedicated site (lets say AWS) for monitoring the EC2 instances then all EC2 instances should be registered against the AWS site and not the master site.
For easier registration of multiple hosts, an host on which the agent is installed can perform a registration on behalf of other hosts. This is known as registeration by proxy.
Are you creating the hosts in the configuration with an API call from the host itself?
This has to be done by talking to the central site because it then deploys the config to the remote sites at activation time.
But this has nothing to do with the agent updater registration in the enterprise edition or the recently introduced TLS registration for encrypting the agent data.
Yes this is the initial registration from the host (The TLS piece works fine to the local poller), I was just looking for a way to simplify the initial registration call to the central server wondering if it could be proxied by the local poller instead (Greatly simplifying the firewall rules that needed adding)
This is currently not possible. The REST-API has to be called on the server where the configuration resides, i.e. the central site in a distributed setup.
Got it! That is the plan I was already proceeding with, I just posted this as working through it I was thinking “There has to be an easier way” and didn’t want to find out "Oh yeah you just toggle this 1 option and it all works) after I added all the firewall rules lol.
Sounds like I haven’t necessarily overlooked anything, the good news is as I look at this though I think I really only “need” this in AWS, in my physical DC’s I don’t add hosts programmatically, so while the auto add script is “nice”, when I weigh the actual work of just adding hosts via the console when they are spun up it’s pretty lightweight everywhere else.
Cheers to all, even with the extra firewall rules I need this is phenomenally better than adding hosts in nagios lol!
Understood, that was the part that made me confused. You are adding the hosts towards Checkmk. When you are registering the hosts this means the TLS step (as you do not have Enterprise, was a bit unclear in your post)
This is perfectly explained in the docs, both for windows and linux of the agent controller works.
I’d recommend to watch out for Checkmk 2.2 and/or 2.3 where there will be improvements running agents in a cloud env. (on-prem cloud or public cloud) where completely automatic registration is in the works.
Perfect, I think I get it, really like I said my biggest concern was “Am I missing something” but it seems like no, as I have it deployed the only real way I have to do what I want is the way I am doing it now, but in the future that may change.
It all works and everything, I just thought maybe I was making it more complicated than it needed to be!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
