Feature Pack 2 is out!

Dear Checkmk Community,

As we finalize the next Checkmk version, we are excited to announce the next step along the way: Feature Pack 2. Just like in the previous feature pack, the new features are delivered as MKPs that you can choose to activate. In the Enterprise Edition, this is easily done via WATO. Users of the Raw Edition can activate the features included in the feature pack via the CLI. We have written a detailed blog post here.

What’s in Feature Pack 2?

Prometheus Integration
Checkmk users who also use Prometheus can integrate it into their Checkmk from version 1.6.0.p12. We provide integrations for the most important exporters of Prometheus. The supported exporters are cAdvisor (Container Advisor), node_exporter and kube-state-metrics. It is also possible to include metrics from Prometheus via PromQL queries.

Redis Monitoring

Monitor Redis databases and instances. For the monitoring you need the agent plugin mk_redis , which can be configured with the Agent Bakery via the rule Redis databases . The plug-ins provide, for example, information on the persistence status of Redis instances and on the currently connected clients.

RabbitMQ Monitoring

It is now also possible for you to monitor RabbitMQ clusters with Checkmk. All you have to do is to configure the Special Agent via the Datasource rule Check state of RabbitMQ to monitor queue and vhost statistics, either cluster-wide or specifically on a node.

FortiGate VPN-Monitoring

It’s now possible to configure the monitoring for each of the active VPN tunnels.

Pulse Secure Monitoring

Monitor the number of users, CPU, memory and disk usage, temperature and log file usage on Pulse Secure appliances.

Cisco ASA Monitoring

Two new check plug-ins to monitor the number of active WebVPN and IPsec sessions for Cisco ASA devices.

Cisco Webex Team Integration

The extension allows you to inform operations teams about changes in the status of hosts and services via Cisco Webex Team.

1 Like

So to get this with Enterprise, do I need to update to the latest patch revision? Or should it “just show up” in my extension packages? Currently running 1.6.0p9.

This is what I see:

As the blog article mentioned in Faye’s post says:

We deliver the new Feature Pack 2 as part of Patch 1.6.0p12.

So yes, you need to update to p12, then install/activate the extension packages you want to use.

Oops! I did look at the blog post… but did not read it closely apparently. Thanks!

np. It surely wouldn’t have hurt to include that sentence here in the post as well :wink:

1 Like

:see_no_evil: will keep in that in mind next time :stuck_out_tongue_winking_eye:


Hi All,

Thanks for the nice work for this feature pack.

As we have some RabbitMQ instances in our environment, I am interested if there is added value of this plugin.

I observed a strange behaviour after enabling the RabbitMQ plugin on 1.6.0p12 CRE on Debian 10 (Buster) :

  • installed the ‘/opt/omd/versions/1.6.0p12.cre/share/check_mk/optional_packages/agent_rabbitmq-1.0.mkp’ plugin
  • enabled the datasource program for ’ Check state of RabbitMQ’
  • bind this rule to a specific host

After a ‘Full scan’ of this specific host, the new RabbitMQ services do appear, however the other regular services (ie. CPU, memory, IO, …) disappear…
When disabling the datasource program, the regular services appear again…

See attached some screenshots.

Are there some more steps required to have this working correctly?

Best regards,


I think you took the wrong datasource for the host. If you want checkmk agent output and datasource output, choose “Normal Checkmk agent, all configured special agents” in WATO configuration of the host.

@_rb , Thanks !

That was indeed the missing step. I did not realise this option was present, I only have used this for hosts with piggyback data!

Have a good weekend!


Team, I have added the Prometheus in the kubernetes cluster. I can addPromQL and I can add individual metrics. Is there any way all the metrics can be added automatically like in case of special agent scenario.

Also can you please let me know if the following exporters can be added all at once or only one should be added.

  • cAdvisor (Container Advisor)
  • node_exporter
  • kube-state-metrics

Hi All,

Today I attempted to add a second RabbitMQ host to our monitoring server via the above described procedure, but I believe I found a bug when there is more than 1 server defined.

I attempted this on 2 completely different CRE1.6.0p17 installations, with the same result.

Ways to reproduce:

  • create one Datasource Program ‘check state of RabbitMQ’
  • the config is pointing to a remote server with username/password
  • only ‘Queues’ are queried
  • an explicit host is configured from where the queries are initiated

This should result in a new service when the explicit host is ‘polled’, which it does in my case.

Now repeating the above with another (second) host in ‘Datasource Program’ results does not result in new services. See screenshot.
When the order of the hosts is shifted, the result is also reversed. The earlier discovered service will go into unknown state.

Can anybody confirm this behaviour before opening a bug ticket?

Perhaps I misunderstand your setup, but:
“The first matching rule defines the parameter.”
(as shown in your screenshot).

1 Like


Thanks for the response.
I simply want to monitor 2 different RMQ nodes, each with different queues/vhosts/exchanges etc.

Your quote seems to imply, that it is only possible to monitor 1 node/cluster? That would seem odd?

(troubleshooting with tcpdump does show connections to both nodes, but the services are not correctly created).

Best regards,


sorry for the late response.

Yes, you are right, this seems odd. For different conditions, the rules should not overwrite each other’s parameters.

Could be a bug. I currently have no such setup to test against. Anyone else?