Monitoring a very large number of hosts

General
1

Hi,
We use actually Check_mk 1.2.8p27, configured with text files, using our own templates, for monitoring more than 10k hosts, and are considering moving to OMD/Check_Mk 2.2

However, it is not feasible to populate that many hosts with Wato.

Is there some documentation on the format of files used by Wato, in order to populate them with our templates ?

Thanks,
Regards,
Xavier

2

Hi @Xavier_Humbert,

I would suggest using the Bulk Import options that Checkmk got. Like a CSV import.
Alternatively, you could build something with the REST API. I’m not a big fan of doing things under the hood. :grinning_face_with_smiling_eyes:

What kind of templates do you have?
Most things should be possible with the rule based configuration, if I’m not missing something here. Host Labels/Tags can also really help in this case.

Looking forward to your reply!

Regards
Norm

3

The format of the hosts.mk file is quite simple. I am not aware of a documentation, but a basic example is the attached Perl template at the bottom of the autopb script:

Note that the format of the .mk files changes from time to time. You might need to adapt the templates, especially when upgrading to a new release.

There are other options you could consider:

The REST API of Checkmk 2.1+ is now very powerful. You can query the configured hosts, compare them with your CIDB in regular intervals and add/modify/delete hosts through the API.

If you intend to use the Checkmk Enerprise (or Cloud or Managed Services) edition, you can use the Dynamic Configuration Daemon for your purposes:

  • The DCD comes with the piggyback connector which adds hosts to the monitoring when there is piggyback data available. You can simply write a plugin or a datasource program which injects piggyback information to the monitoring, and let the DCD add the host objects.
  • There is a 3rd party tool, the DCD file connector which picks up CSV or JSON files containing host objects and their attributes. This is very powerful, you can also add host labels or fill in custom host attributes.
  • Finally, you can write your own DCD connector which directly queries your CIDB. Unfortunately, there is hardly any documentation on that, you need to study the source code of other connectors.

With the Checkmk Raw edition, there is no DCD. The autopb script mentioned above can be a starting point. But for your purpose, it needs to be modified. Currently, it adds rather dumb host objects to Checkmk; without an IP address and without agent based monitoring, just as a container to display available piggyback data.

1 Like
4

Additionally, to what @Norm and @Heavy wrote, there is an open source tool by @bkuhn called cmdbsyncer, with which you can sync different datasources (e.g. csv,ldap,netbox) based on rulesets into checkmk.

1 Like
5

Please take into account that manually altering files in checkmk isnt supported. As already mentioned the format vary over different versions and you will have no official support.
To migrate from 1.2 to 2.2 I would recommend to do it step by step and create the necessary rules for each step.

1 Like
6

Yes, and that tool should even be able to read data from the Old Checkmk using the old Webapi. But don’t know about the main.mk hosts there. With some little (import) modification and the use of a custom view there, it should be possible that you can use your old Tags to create Wato Folders for Structure, and with an already ordered new Feature it will be possible even migrate your Tags into Wato Tag Groups and of course tag the Systems again.

Only the rules need a bit of brainpower to solve. Even thought, the Syncer can create Rules, I have no idea yet how to read and convert them. Maybe just create them new with best practice, this I did successful already in more old 1.4, 1.6 to 2.2 migrations with not much effort instead of migrate them. Was always also meant as cleanup the old stuff.

But having your hosts structed in the new world, would be already a win. And once you have them in Syncer, you can even use the Syncer to Update all your Agents, and register Bakery and or TLS. (Just did that with about 400 Windows hosts this morning, last time).

Docu: Cmdbsyncer Documentation
Download: GitHub - kuhn-ruess/cmdbsyncer: Rule Based Syncronisation System with Checkmk and Ansible Support

1 Like
7

The Checkmk documentation explicitly mentions this option, so I doubt you will lose support for that, see Checkmk on the command line - Understanding and using command line commands

In fact, there is no fully supported toolchain to get information from a CMDB into Checkmk. 3rd party tools like the DCD file connector or cmdbsyncer are also not supported (by tribe29). The DCD piggyback connector comes closest, but you need still some tooling to provide the piggyback data.

8

Thanks for the hint. We will massively alter section 5 of the article mentioned. Looking into config files is OK for debugging, but when editing there might be side effects caused by interdependencies. Scripted configuration changes should be done using the REST API these days.

1 Like
9

I can’t get into any details but for us 10k hosts we consider a small installation…

I’d recommend using more automated and standardised ways to add hosts, using the RestAPI. The RestAPI has a bulk function and when I stress-tested it a few months ago we added 25.000 host in less than 10 minutes using just small virtual machines to act as the Checkmk setup.

I would assume ou have some kind of CMDB and/or IPAM were you might have other information that might be useful as well. We create labels from our CMDB for things like Operating System, location, owner of the host etc.

Having this approach we do not have to worry about the .mk file format being removed or changed.

3 Likes
10

As already mentioned above you have the REST API.
We populate monitoring with host objects from Service Now CMDP with help of REST API.

1 Like
11

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.