Product usage analytics coming to Checkmk 2.3, 2.4, and 2.5

Announcements
1

Hello Checkmk users!

At Checkmk, we constantly strive to improve in the areas most important to your daily work. We want to be able to provide you with the best monitoring possible for your use cases, so that you can spot and resolve problems proactively and ensure your IT infrastructure stays healthy. For that, we need to understand how you use Checkmk and what are your most essential monitoring use cases. We have different sources of input to understand such topics. However, while data from the Ideas Portal, interviews, and surveys are crucial, they sometimes leave us with blind spots.

To better understand your monitoring needs, we will be introducing Product usage analytics in Checkmk 2.5. It will also be made available in 2.4 and 2.3 with the patch release following the 2.5 release. When activated, this feature will collect usage data about Checkmk and thus provide us better insights into how you monitor your infrastructure and applications.

This feature will be off by default in all on-premise editions, and we would like to ask you to enable it if possible. The benefit for you is a better-informed product roadmap, resulting in a Checkmk that is more closely aligned with your real-world monitoring requirements.
We will not gather any personal or sensitive information, such as IP addresses, site names, licence information, service names, host names, or folder names. Still, before enabling this, we recommend reviewing all the data and scope of affected instances.

This is a quick heads-up regarding what’s coming soon to Checkmk. We will update this thread with an official Werk once product usage analytics is officially planned in a patch release. We are currently preparing the documentation and technical details to remain fully transparent about how we collect and transfer telemetry data. We hope for your cooperation in helping us understand how Checkmk is used.

If you have any questions, please reach out—we’re happy to answer.

2 Likes
2026 February Community Bulletin
2

In case you are interested in what is being collected, here is an example:

OMD[heute]:~$ cmk-product-usage 
{
  "metadata": {
    "version": "v1",
    "namespace": "checkmk",
    "name": "product_usage_analytics"
  },
  "data": {
    "id": "139183b7-cd1b-4f88-ad89-5961e467f1b6",
    "count_hosts": 6,
    "count_services": 156,
    "count_folders": 4,
    "edition": "ultimate",
    "cmk_version": "2.5.0-2026.02.23",
    "timestamp": 1771852850,
    "checks": {
      "check-mk": {
        "count": 6,
        "count_hosts": 6,
        "count_disabled": 0
      },
      "check_mk-uptime": {
        "count": 4,
        "count_hosts": 4,
        "count_disabled": 0
      },
      "check_mk-tplink_poe": {
        "count": 12,
        "count_hosts": 2,
        "count_disabled": 0
      },
      "check_mk-interfaces": {
        "count": 35,
        "count_hosts": 3,
        "count_disabled": 0
      },
      "check-mk-inventory": {
        "count": 6,
        "count_hosts": 6,
        "count_disabled": 0
      },
      "check_mk-memory_utilization": {
        "count": 3,
        "count_hosts": 3,
        "count_disabled": 0
      },
      "check_mk_active-cmk_inv": {
        "count": 6,
        "count_hosts": 6,
        "count_disabled": 0
      },
      "check_mk-snmp_info": {
        "count": 3,
        "count_hosts": 3,
        "count_disabled": 0
      },

EDIT: Adapted the command line command to match a recent rename. The script which collects the data can already be run on a 2.5 build.

4 Likes
3

A question about the check names. Judging from the data I guess that those are names of the built-in plugins. Will names of third-party plugins be transmitted, too? The reason I’m asking is that we write a certain amount of customer-specific checks, and those contain our customers’ names and even some potentially proprietary service names in the plugin names. I’d have to get their OK first.

2 Likes
4

I believe that some other useful data could be exported like the amount of innefective rules or even the usage of checkers and helpers. This could be used to suggest configuration changes (Advisor) and potentially reduce support tickets. This could be used as an argument to allow that data collection to happen.

5

Hi,
technically, we run a livestatus query to get the check command and then strip everything after the !, so that we get only the name of check. See the following example. This way we remove sensitive information. We don’t care which websites you check, in this case we rather want to know what checks are being used, so that we know where to invest further into.

check_mk_active-httpv2!–url https://checkmk.com → check_mk_active-httpv2

As we also want to use this as a basis for mainlining decisions, we do not differentiate between shipped and non-shipped (livestatus neither does so as well anyway). It helps us to know which exchange plug-ins are actually heavily used, and which we should prioritize in mainlining next.
You can run the command within the site and see if there is anything confidential in it, e.g. if the check name is too revealing (check name != service description as we on purpose do not collect the service item which can definitely have revealing information). And then you can decide if you want to opt-in and donate your data, or not.

@paulosantanabr Let’s see where the journey goes - but we decided we only collect data for which we have a clear purpose and already questions as of today. While I personally love to have as much data as possible, we can make better decisions only with diverse data, from many different users. And we believe minimal collection favours this

EDIT: Added explanation for the stripping of parameters from e.g. active checks

6 Likes
6

Thanks for the explanation. I don’t think I’ll opt-in, then. I don’t want to have to make that decision for the 80 or so sites we have, that’s too much effort.

I’m aware that check (plugin) names don’t equal service names. My argument was that the customer & service-specific checks that we write often contain the name of the thing we’re monitoring, and that might be part of a proprietary/non-public project, therefore we cannot simply expose even the plugin names to third-parties like that.

Maybe let us exclude data from certain plugins from the statistics, e.g. filter via an exclusion regex, managed from the central site. That’d be trivial enough for us to manage and would make opt-in highly likely. Something to think about.

5 Likes
7

Hey Moritz, thought about the same thing. Should be rather straight-forward to implement in the script - just have to think where we expose that (probably via a global setting). Will forward to the respective team.

4 Likes
8

As promised, here is the werk: https://checkmk.com/werk/19605

Product usage analytics is shipped starting from 2.5.0b3, 2.4.0p26, 2.3.0p47 and disabled by default in our self-hosted solutions.

Here is the user guide article with further details: Product usage analytics

Also, have a look at the product usage analytics manifest

2 Likes
9

Maybe you could explain why the columns “Check command” and “Check command expanded” display the same values.

Example:
Service: HTTPS checkmk.com
Check command: check_mk_active-httpv2!–url https://checkmk.com
Check command expanded: check_mk_active-httpv2!–url https://checkmk.com

I would have expected that the first column shows only the command itself, while the second includes the command with its arguments:

Check command: check_mk_active-httpv2
Check command expanded: check_mk_active-httpv2!–url https://checkmk.com

Then both you and we could use the “Check command” column in views and Livestatus queries to retrieve the check command without any arguments. :wink:

10

You might want to consider collecting the data centrally and in a consolidated way in the Ultimate Multi-Tenancy Edition. Nobody wants to set up firewall or proxy rules for 500 sites, and in many companies systems are not allowed to send data directly to the Internet.

An offline mode – similar to the licensing process – would therefore be very helpful, enabling you to also receive data from larger environments.

5 Likes
11

If I remember correctly, then Check command expanded resolves macro.
check_mk_active-httpv2!–url https://$HOSTNAME$
vs.
check_mk_active-httpv2!–url https://checkmk.com

1 Like
12

Currently, the Check command expanded column contains data only for active checks. And when it does, it merely duplicates the Check command column, resulting in redundant information:

grafik
grafik1576Ă—304 18 KB

Ideally, the Check command column should include only the check name (e.g. check_mk_active-httpv2) without arguments (!…). This would make both columns more meaningful and clearly distinct.

Alternatively, introducing a dedicated Check name column could be even more effective. For instance, it could display mrpe-my_super_duper_test instead of the generic check_mk-mrpe currently shown in Check command , ensuring more precise and useful data for analysis and automation.

These changes would make the columns more practical across different use cases, eliminate unnecessary workarounds, and significantly improve long-term usability.

2 Likes