Invalid literal for int() with base 10: '1658736833.50' - Exchange msx Queues

[Overlord (M)]

CMK version: 2.1.0p8
OS version: Debian 11

Error message: invalid literal for int() with base 10: ‘1658736833.50’

Output of “cmk --debug -vvn hostname”: (If it is a problem with checks or plugins)

File "/omd/sites/sitename/lib/python3/cmk/base/plugins/agent_based/winperf_msx_queues.py", line 46, in parse_winperf_msx_queues
    return {int(line[0]): int(line[-2]) for line in string_table[2:]}
  File "/omd/sites/sitename/lib/python3/cmk/base/plugins/agent_based/winperf_msx_queues.py", line 46, in <dictcomp>
    return {int(line[0]): int(line[-2]) for line in string_table[2:]}
ValueError: invalid literal for int() with base 10: '1658737016.81'

I saw a lot of issues here with the same "invalid literal for int() with base 10 - seems to be an generall issue with the new version?

Greetz
Ovrld

[Overlord (M)]

Hey guys - the issue still persist? Is there no fix or workaround?

Parsing of section winperf_msx_queues failed - please submit a crash report!

[andreas-doehler (Andreas)]

In your case the definition of the “msx_queues” counter on the agent side is relevant. I think it pulls the wrong counter.

The error message itself comes from the floating point number instead of an integer.

[Overlord (M)]

Thank you for your hint - now I had time to have an eye on it. Unfortunately, there is no section anymore in CheckMK with “MS Exchange message queues discovery”

Is this a bug or is the section removed?

Edit:
It’s renamed - I found it under “Queue names”

I changed MSX Queues by checkin the counters file but I have the same issue:

Starting job…
WARNING: Parsing of section winperf_msx_queues failed - please submit a crash report! (Crash-ID: xxx)
Completed.

I deleted all except this two under “MS Exchange message queues discovery”:

MSExchangeTransport Queues / Offset 96
MSExchange Delivery SmtpReceive / Offset 120

But the error still occurs.

Edit 2:
I deactivated the rules under Queue Names and MS Exchange message queues discovery - so no rule should be used. And the issue with the crash is still there.