First of all $OMD_ROOT corresponds - in your case - to /omd/sites/monsvrs so yes, the piggybacked data, should be there (meaning: /omd/sites/monsvrs/tmp/check_mk/piggyback the var I had above was wrong).
Your local check, should be in the “LocalDirectory”, my agent says it is /usr/lib/check_mk_agent/local and - as previously stated - must be executable.
Can you try to run your agent in debug mode and carefully check
the location it says for your LocalDirectory
the output after the section # Local checks? For me, this looks
like this (my local check is called localtest2):
# Local checks
echo '<<<local>>>'
+ echo '<<<local>>>'
<<<local>>>
if cd "$LOCALDIR"; then
for skript in ./*; do
if is_valid_plugin "$skript"; then
./"$skript"
fi
done
# Call some plugins only every X'th second
for skript in [1-9]*/*; do
if is_valid_plugin "$skript"; then
run_cached "local_${skript//\//\\}" "${skript%/*}" "$skript"
fi
done
fi
+ cd /usr/lib/check_mk_agent/local
+ for skript in './*'
+ is_valid_plugin ./localtest2
+ pattern='\.dpkg-(new|old|temp)$'
+ [[ -f ./localtest2 ]]
+ [[ -x ./localtest2 ]]
+ [[ ! ./localtest2 =~ \.dpkg-(new|old|temp)$ ]]
+ true
+ ././localtest2
<<<<otherhost>>>>
<<<local>>>
0 Status - I'm OK
0 Voltage - I'm OK, too
<<<<>>>>
--- rest skipped intentionally ---
For the local checks, It’s look like I found only this :
# Local checks
if cd "$LOCALDIR"; then
if $MK_RUN_SYNC_PARTS; then
echo '<<<local:sep(0)>>>'
for skript in ./*; do
if is_valid_plugin "$skript"; then
./"$skript"
fi
done
fi
# Call some plugins only every X'th second
for skript in [1-9]*/*; do
if is_valid_plugin "$skript"; then
run_cached "local_${skript//\//\\}" "${skript%/*}" "$skript"
fi
done
fi
Should I remove the agent and reinstall it ? When I tried the @r.sander’s method (plugin) maybe it caused a conflict with local checks?
Stupid question, when I put the script in the directory, checkmk should execute it automatically ?
And as my checkmk server and agent are on the same machine, I don’t really need to use Piggyback mechanism right ?
EDIT :
If I do a grep -A 20 mylocalcheck( mylocalcheck = name of the script) added to the previous command, it returns me that :
+ is_valid_plugin ./mylocalcheck
+ pattern='\.dpkg-(new|old|temp)$'
+ [[ -f ./mylocalcheck ]]
+ [[ -x ./mylocalcheck ]]
+ [[ ! ./mylocalcheck =~ \.dpkg-(new|old|temp)$ ]]
+ true
+ ././mylocalcheck
<<<local:sep(0)>>>
<<<local>>>
0 Status - I'm OK
0 Voltage - I'm OK, too
+ for skript in [1-9]*/*
+ is_valid_plugin '[1-9]*/*'
+ pattern='\.dpkg-(new|old|temp)$'
+ [[ -f [1-9]*/* ]]
+ false
+ true
+ run_plugins
+ cd /usr/lib/check_mk_agent/plugins
+ true
+ for skript in ./*
+ is_valid_plugin './*'
+ pattern='\.dpkg-(new|old|temp)$'
+ [[ -f ./* ]]
+ false
+ for skript in [1-9]*/*
+ is_valid_plugin '[1-9]*/*'
No, I don’t think so, but the plugin looks for me as if it is for Checkmk 1.6 and not for 2.0. Anyway, that shouldn’t interfere with local checks.
Yes, if it’s executable. From your output I see, that it is being executed.
In theory, no. But the services your local check creates, will be associated with your “main” host. If you can live with that, and just “know” that those two services refer to your UPS, that’s fine. If you want to have your UPS as a separate host in Checkmk, I’d personally use the piggyback method.
Back to the issue: the script mylocalcheck is being executed, but as I see, the <<<<otherhost>>>> identifier is not present, so I believe that’s the reason why no piggyback data is present.
Can you try two things:
remove the line with echo <<<local>>> from mylocalcheck. Wait three minutes or so, and recheck your host in “Setup”: Theoretically, your host should discover two new services. This would “fulfill” the scenario of having services which refer to the UPS, associated with your “main host”.
add both lines with echo <<<<otherhost>>>> and the line with echo <<<local>>> to mylocalcheck. Again, wait three minutes or so. Theoretically piggyback data should exist now, your host should “lose” the two services it discovered before, and if you discover services for “otherhost” it should find them. This would result in having two hosts in Checkmk: your main host, and the piggybacked one.
I hope all my explanations are not too convoluted…
Cool, glad that it worked for you!
First of all the “main dashboard” is different in an Enterprise
Edition compared to a RAW edition, but the following applies:
If there’s a WARN or CRIT alert for your services it will show up in the “main dashboard”
If you want to have a somehow different display (e.g. you want to see those services no matter what), you’d need to modify your dashboard accordingly (or create a new one). There is a nice section about what one exactly sees on the “main dashboard”, and how to modify it.
The article about views might also be of interest to you.
You’re right when there is a WARN or CRIT alert, they appear in the main dashboard successfully.
I don’t understand really well how the synchro with local check works, for exemple when I just modify my fake localcheck file txt, changing the value of the status service from 0 to 2 for exemple (so my status should change from “OK” to “CRIT”, sometimes changes apply immediately, sometimes it can take hours.
Anyway, now I will work on the final script which will convert my data from a txt file (named test2.txt) created by the first script (named ups.sh) to the good localcheck syntax, the first script is just a script which extract the information of the UPS and putting them on a txt file.
I didnt read the full thread because its quite long, so please apologize if I misunderstand something here.
For my understanding it is not necessary to run a separate cron job and the parse the txt file by a local check. This could be done all in one local check.
Just a rough sketch without any guarantee:
echo "<<<local>>>"
OUTPUT=$(upsc servers@localhost)
voltage=$(grep -e "output.voltage" <<< "${OUTPUT}" | awk -F ': ' '{print $2}' | awk -F '.' '{print $1}')
if [ ${voltage} -lt 200 ]; then
echo "1 ups_voltage voltage=${voltage};200;190 WARNING - Voltage is at ${voltage}"
fi
That should give you a good starting point. Extend it by the other parameters.
What @mike1098 proposes, looks very good, and is probably a starting point for you to write a local
check, fulfilling your requirements. Please see also the official documentation about local checks, which has a lot of useful information you may want to incorporate.
Congratulations, my friend, nice! Regarding your question about metrics: the manual
provides all answers you need. Let me elaborate:
From the moment that your check output always has 1 as the first character, any check result is considered a “WARN”-state. Please see the official documentation about local checks, to understand which parts mean what for the Checkmk server: 2.1. Creating the script.
That said, yes, “190” would be the value you have set as “CRIT” threshold. Here is an explanation about what the comma separated values mean: 3.1. Metrics. Of course, this is only true, if your script is actually checking for that, meaning:
In order to make your script respect your threshold, and “act accordingly”, you need to code its logic: the agent doesn’t do that for you. So you need to have some kind of “conditional”, e.g. values between X and Y result in an “OK” state, values between Y and Z mean “WARN”, etc. Hint: There are countless tutorials on the web for “simple Nagios” checks, and you can utilize their logic for Checmk local scripts, too. Here is one I found at HowtoForge.
The two values 200;190 are the WARNING and CRITICAL values for the metric.
You have the choice:
Either you can determine the state of your check in your code with conditions (if this > that do this:), then the two values after voltage are just produce a yellow and red line in the graph
or
You can use:
echo "P ups_voltage voltage=${voltage};200;190 WARNING - Voltage is at ${voltage}"
Then checkmk is taking this two values and determine the state of the check. Thats quite handy in this case but works not in complex situations or if you need to test text status.
Thats quite handy in this case but works not in complex situations or if you need to test text status.
I can changes the values manually in the txt file, just to get an overview. Do you know guys why when I make changes in files, sometimes it doesn’t update directly in Checkmk even if I use a full services scan (particularly in Piggyback method), I’m forced to reboot the VM.
About the metrics, for exemple, the output_voltage :
I want it to returns me CRITICAL if the value is lower than 180
Take in to account with piggyback you need to update both hosts, the host which collects the information via agent and then the host consuming the created piggyback data.
