BUG: special agent_activemq with wrong URL composition

CMK version: v2.1.0p2
OS version: Ubuntu 20.04 LTS

Error message: Service detection does not find ActiveMQs anymore

Output of “cmk --debug -vvn hostname”:

In version v2.0.0p25 this plugin was active and showed a service for each queue running on the host.
In version v2.1.0p2 the rule is still active, but no service is recognized.

cmk --debug -vvn does not list apache_active_mq entries.

We have the same problem on the service detection with SNMP (posted in a separate thread) - it seems that the service detection is somehow broken in the raw edition.

Plugin page.
Does somebody has similar problems / ideas what to do?
Regards,
Christoph

What plugin do you use for the “apache_active_mq” checks?
As i see no code inside the “normal” CMK for this check.

Hi Andreas,
if you search for a ruleset named “ActiveMQ”, you will find a ruleset for “Apache ActiveMQ queues”, which automatically activate the services, if an ActiveMQ Queue is found (there is an http - Login inside the ruleset). [Setup->Agents->Other integrations->Apache ActiveMQ queues]
In our case the port, user and pw didn’t change, but the plugin does not find any entry inside the service discovery.

cmk -II -vv --debug mySERVER

Calling: /omd/sites/hfm/share/check_mk/agents/special/agent_activemq 'mySERVER' '8161' '--protocol' 'http' '--piggyback' '--username' 'admin' '--password' '************'
Write data to cache file /omd/sites/hfm/tmp/check_mk/data_source_cache/special_activemq/mySERVER
Trying to acquire lock on /omd/sites/hfm/tmp/check_mk/data_source_cache/special_activemq/mySERVER
Got lock on /omd/sites/hfm/tmp/check_mk/data_source_cache/special_activemq/mySERVER
Releasing lock on /omd/sites/hfm/tmp/check_mk/data_source_cache/special_activemq/mySERVER
Released lock on /omd/sites/hfm/tmp/check_mk/data_source_cache/special_activemq/mySERVER

seems to work, but no service pops up in GUI.

If I open the cache data file: /tmp/check_mk/data_source_cache/special_activemq/mySERVER - the file is empty.
Deleting the caches (from agent + special_agent) does not make any difference.
There is no error reported on the console.
Regards,
Christoph

Ok I was not looking for special agents only agent plugins :slight_smile:
For this problem it would be good to compare the special agent output between 2.0 and 2.1 version if there is a difference.
If this is the same output, the problem is on the discovery side.

Still the same after Update to 2.1.0p4…

cmk -II -vv --debug myHOST

[…]
[special_activemq] Success
[…]

But no Services showing.
Is there any chance to debug this “special agent” to get more than “Success” ??

Execute the special agent manually with the command shown with “cmk -D myHOST”
You can also look if the special agent has some debug switches on the command line.

cmk -D myHOST

myHOST
Addresses:              myHOST
Tags:                   [address_family:ip-v4-only], [agent:all-agents], [checkmk-agent:checkmk-agent], [criticality:prod], [department:electris], [ip-v4:ip-v4], [location:HQM], [networking:lan], [os:winServ19], [piggyback:auto-piggyback], [site:hfm], [snmp_ds:no-snmp], [tcp:tcp]
Labels:                 [cmk/os_family:windows], [cmk/piggyback_source_zeus.headquarter.local:yes], [cmk/site:hfm], [cmk/vsphere_object:vm]
Parents:                zeus.headquarter.local
Host groups:            WindowsServer, Server
Contact groups:         check-mk-notify
Agent mode:             Normal Checkmk agent, all configured special agents
Type of agent:
  TCP: myHOST:6556
  Program: /omd/sites/hfm/share/check_mk/agents/special/agent_activemq 'myHOST' '8161' '--protocol' 'http' '--username' 'admin' '--password' '****************'
  Process piggyback data from /omd/sites/hfm/tmp/check_mk/piggyback/myHOST
Services:
  checktype                      item                                params     

List all services we see in GUI, but NOT the activeMQ services.
In v2.0 the activeMQ generated a service for each queue, which was found (in our case about 20).

I started the special agent manually with the credentials from agent output:

./agent_activemq ‘myHOST’ ‘8161’ ‘–protocol’ ‘http’ ‘–username’ ‘admin’ ‘–password’ ‘*******’ --debug --verbose

And got:

INFO 2022-06-29 16:13:40 root: running file /omd/sites/hfm/lib/python3/cmk/special_agents/utils/agent_common.py
INFO 2022-06-29 16:13:40 root: using Python interpreter v3.9.10.final.0 at /omd/sites/hfm/bin/python3
Unable to connect. Credentials might be incorrect: mismatched tag: line 15, column 2

But login is ok, as I can connect with a browser to http://myHOST:8161 with the same credentials.

I found out, that you could set a tracefile and filled a log with the requests.

interactions:
- request:
    body: null
    headers:
      Accept:
      - '*/*'
      Accept-Encoding:
      - gzip, deflate
      Connection:
      - keep-alive
      User-Agent:
      - python-requests/2.27.0
      authorization:
      - '****'
    method: GET
    uri: http://myHOST:8161//admin/xml/queues.jsp
  response:
    body:
      string: '<html>

        <head>

        <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>

        <title>Error 404 Not Found</title>

        </head>

I see a double “/” Slash in the request http://myHOST:8161 // admin/xml/queues.jsp, which corses the 404.
If I call the URI without double quotes in my browser, I get values from the queue!

So I guess, there is a bug in the python script of the check.

Could please somebody with support - credits highlight this to the support?
Thx,
Christoph

Until this is fixed in the normal release, you can help yourself with a small modification of the special agent file inside “/omd/versions//lib/check_mk/special_agents/agent_activemq.py”
Line 63 if i see it right.
api_path must be without a leading /

Interesting thing is that this agent was not changed from 2.0 to 2.1
It is possible that the new error is only a side effect from updated libraries.

1 Like

Hi Andreas,
I just want to confirm, that this change works.
We directly get all Services for the Queues back.
Thanks!
Regards,
Christoph

PROBLEM FIXED in v2.1.0p9

Hi all,
just as info: BUG is still not fixed in v2.1.0p7-1
Andreas hack has to be done again.
Regards,
Christoph

My patch was only applied to the master branch. Question for @robin.gierse if he can ask why it is not also applied to 2.1 and 2.0 branch as all are affected.

You got some link for me to pass on? :upside_down_face:

That was the commit

I will back-port this fix to 2.1 and 2.0. Changes made in PRs are usually only applied to the master branch. We only back-port them up on request, if the change applies cleanly to older versions.

1 Like

Ok thanks, but now we have a problem - PRs should be only be against the master branch.
Normally if the same file exists in older branches they are affected the same way.
How should we do our PRs then?

I think you still create the PR against the master branch and maybe ask for it to be back ported.
Just my semi-educated guess though. :slight_smile: