Disregard of "Checkmk Agent / API Integrations" option selection

Troubleshooting
1

CMK version:
Checkmk Enterprise 2.3.0p30 (CEE)

OS version:
Docker container running on AlmaLinux 9.3 host

Problem summary

I’m trying to monitor a Spring Boot service exposing a valid and accessible Jolokia endpoint at:

http://ip.address/pricing/actuator/jolokia

This URL works fine via curl from within the Checkmk container. I’ve configured a Jolokia integration under:

Setup → Agents → JMX monitoring of Java JVMs using Jolokia

However, neither of the two available “Checkmk Agent / API integrations” options work.

1. Option: “Configured API integrations, no Checkmk agent”

In this mode, no connection attempt is made. Output of:

OMD[cmk]:~$ cmk --debug -vvn ip.address

Yields:

[API/agent] host configuration requires a datasource but none configured (!!)
[piggyback] Successfully processed from source 'another-ip'

It’s as if the Jolokia integration is not being recognized at all as a datasource, despite being configured for this host.

2. Option: “API integrations if configured, else Checkmk agent”

In this mode, it ignores the Jolokia API integration and tries to connect via TCP (which is not running):

[agent]: Communication failed: [Errno 111] Connection refused
[piggyback] Successfully processed from source 'another-ip'

So the agent fails, and the Jolokia integration is still not used.

Conclusion / Bug?

Checkmk Enterprise doesn’t seem to recognize the configured Jolokia rule as a valid data source, even when the endpoint is reachable and correctly set.

This makes both available modes unusable:

  • “Configured API integrations, no Checkmk agent” fails with “no datasource”
  • “API integrations if configured, else agent” skips the API entirely

This looks like a bug in how datasource plugins are registered or matched to the host.

Would appreciate guidance on whether this is a misconfiguration or a regression in 2.3.0p30.

2

Followup details:

After installing the agent on the host:
Configured API integrations, no Checkmk agent
Still shows [API/agent]: host configuration requires a datasource but none configured

“API integrations if configured, else Checkmk agent”

Disregards configured “JMX monitoring of Java JVMs using Jolokia” rule, with no output showing.

Conclusions

  • Checkmk does not actively fetch Jolokia data over HTTP via configured rules unless the agent plugin is present.
  • The agent plugin (mk_jolokia) must be “baked in” or manually copied to the target host and configured via jolokia.cfg.
  • The “Configured API integrations, no Checkmk agent” option seems to be ignored or broken for Jolokia HTTP.
  • “API integrations if configured, else Checkmk agent” falls back to trying the agent (TCP port 6556), even though Jolokia is configured.
3

This is the wrong rule for special agent access.
This rule will only work with agents and plugin deployment.

Jolokia special agent can be found here.
Setup → Agents → Other integrations → Jolokia

Then all the other problems should not exist.

1 Like
4

Thanks. Ok I added a rule, and it found a set of JMX values
Jetty 11.0.17 (Jolokia version 2.1.1)
GC G1 Concurrent GC
GC G1 Old Generation
GC G1 Young Generation
Memory
Memory Pool CodeHeap ‘non-nmethods’
Memory Pool CodeHeap ‘non-profiled nmethods’
Memory Pool CodeHeap ‘profiled nmethods’
Memory Pool Compressed Class Space
Memory Pool G1 Eden Space
Memory Pool G1 Old Gen
Memory Pool G1 Survivor Space
Memory Pool Metaspace
Threading
Uptime

Does the plugin only allow for checking these values?

We have 15+ services running in pods, and I have open issues on the Kubernetes integration, and the Prometheus integration, so Jolokia is a last resort setup, where I’d be querying 15+ Jolokia URLs.

Is there any way to setup or alter the plugin for querying other values?

The problem with the JMX agent method, is that we have it set up for the legacy machine already, and baking a new agent bakes only the first rule into the jolokia.cfg, and disregards the rest. So I can’t add additional rules applicable to the new machine (let alone 15+ new rules, and baking the agent into the pods isn’t an option - it would have to run on the host). Is there a supported way to query more MBeans per instance, using the HTTP plugin and not baking, since the baking method only allows a single rule, and we have already set up this rule for the legacy monitoring? I’ll try moving the rule down and baking a new agent that uses the HTTP URLs and see how that goes.

5

Ok that works. Thanks.

6

Hello!

If one of the answers helped you solve your question, please mark it as the solution. This way, you thank the person who helped you and also indicate that the question has been resolved. This, in turn, helps others who come across the same question.

Solution

Thank you!