I know there has been a similar issue already, but the answer doesn’t help me.
I’m running v2.0.1 raw on Ubuntu 18.04
I was trying to setup REDIS info check. I downloaded “mk_redis” from the Linux agent plugins and put that on my host under “/usr/lib/check_mk_agent/plugins”. Change the access to “+x”.
I can run the script locally on my host, but I’m missing some step on the server. I neither can’t discover the new service nor made it visible.
What am I missing?
I didn’t expect it to be that weird…
Also in the free enterprise version - no way
Check_MK Agent Version: 2.1.0p20, OS: linux, Agent plugins: 1, Local checks: 0
Check_MK Agent Version: 2.1.0p20, OS: linux, Agent plugins: 2, Local checks: 0
Running the plugin manually on the host gives the expected “redis-cli info” output
But running OMD[monitoring]:~$ cmk --debug -vvn my-server does neither reveal the existence of the mk_redis tag (<<<redis_info:sep(58)>>>) nor does it contain the expected payload
Just
Redis Server Info PEND - Check plugin received no monitoring data
Come on, this is the Enterprise version now. I was easily able to write my own plugin with your documentation, but what goes wrong here? What is necessary to be configured in the GUI to make the service detectable?
EDIT:
Also, if this remark in Edit Rules: Redis database is meant to say, that the mk_redis plugin is deployed to my host at activation, then this doesn’t work either:
Found the reason: I was having an own plugin in the same directory as mk_redis. This was made following the tutorial here: Writing your own check plug-ins…
Well, obviously some unknown side effect. I just noticed that “my” plugin was always enumerated as last. I removed the plugin file from the host and tadaa… There it was, my Redis info
Custom plugins and CMK plugins cannot co-exist in the same directory?
If somebody is willing to debug this with me - welcome…
EDIT: Where to file an issue?
Wow, this is now a bug of the very special kind 
OK, of course my custom plugin worked fine as long as it was the last one in the chain. The problem did raise only in conjunction with the following Redis check.
You wouldn’t believe, what the reason is: A missing \n
I admit I had a bad feeling when I first monitored the output of my plugin:
#!/bin/sh
echo '<<<linux_rtsp_server>>>'
curl http://127.0.0.1:8081
I’m testing here the presence of a special API on my RTSP server, which is not exposed to the outer world. The result is - as always with curl - the plain body of the message (expected OK message: 404 page not found - yes, this is OK :))
It looked weird in the console, but it worked for itself (together with a python script on the host, which parsed the result)
ubuntu@ip-172-31-76-28:/usr/lib/check_mk_agent/plugins$ ~/linux_rtsp_server
<<<linux_rtsp_server>>>
404 page not foundubuntu@ip-172-31-76-28:/usr/lib/check_mk_agent/plugins$
Note the missing \n.
In fact, I could make this together with the REDIS check run after adding an echo:
#!/bin/sh
echo '<<<linux_rtsp_server>>>'
curl http://127.0.0.1:8081; echo
So verdict is: If a host plugin returns an “incomplete line” (let me say it this way), the Check_MK breaks… Well, somehow. Leave it up to you to find the correct reason.
This is not explicitly stated like so in the documentation. I also could only find it after spending some hours on it and in the end by mutual exclusion only. No debug means did help to find this. No documentation either (or I have overseen it, sorry if).
Case solved for me.
Thanks
This is because the next agent data section has to start on a new line with <<<.
When your own plugin does not end its output with a newline it is not a “good checkmk citizen”.
Yes, learned it the hard way. IMHO it should be documented (even though your documentation is already brilliant). But give customers a weapon, they will shoot their feet
The more because curl doesn’t necessarily end a body print with a line break…
Guess what? The person working on the spool directory article did exactly what you just did. So I emphasized the newline here:
Thanks for taking care
And we know that the article devel_check_plugins needs a massive overhaul: Yes, the content is extensive, but structure, didactic experience and consistency of the example need improvements. And pitfalls we even encounter ourselves from time to time have to be considered.
So I really appreciate your feedback, and we’ll definitively schedule the overhaul for 2023.
Well, it is not that bad at all. At least it made me up an running with an own plugin in minutes. And the missing new line - shit happens
Don’t worry, your documentation is way above standards.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.