I have been using Check_MK successfully for over 7 years. That success came with ease of use until now. I can’t begin to understand the logic or reason for jumping from ini files to yaml. I am having issues with running a powershell script on Windows. I am trying to run via MRPE. I tried running the powershell script by placing it in the plugin folder but that didnt work. The log application error state unable to execute script. I made sure the system can run powerscripts.
Can someone assist? I can post my check_MK.user.yml
As i don’t know the internal decisions, the yaml file format is more structured and well defined in comparison to the old ini file.
You said that your script is normal Powershell. Then the minimum what should happen is a small text output. But before let us check the locations.
Own scripts should be placed inside "C:\programdata\checkmk\agent\plugins". These paths you also find inside the “check_mk.user.yml” file.
Below is my default config i use in most of my servers. This works with over 1-2k Windows servers. The config created with agent bakery from enterprise don’t look different only smaller. I use the build-in paths for some plugins that are already shipped with the agent. I put only own scripts inside the custom plugin path.
Now we come to the possible problem.
The execution of scripts, not only powershell, are more sensitive to error conditions. If your script don’t finish with a clean exit it is possible that you see nothing as the agent thinks the script crashed.
Thanks for getting back so quickly. Unfortunately your yaml file did not work. In fact, the yaml file you suggested actually made it worse as MOST of my normal services on my test server had been removed. The powershell script works as I tested it and yet it doesn’t even appear in my services under your YAML file. The same powershell script was working in the previous versions of Check_MK as I was using scripts such as these to monitor my windows environment. As a solution - I simply reused the example check_mk.example.user.yml to retrieve my services.
Here is a important point to always remember when designing a product and the Check_MK team needs to understand. A product has an end user audience. In my experience, you always are going to have more non-technical people than technical people. The Check_MK introduced a change which has lead to, presumably, unintended difficulties as I have seen posts of users having issues similar to mine. Again - i didn’t have this issue under the previous versions as ALL of my scripts were executing with no issues. While one can state that YAML has a more solid structure, config ini files easily worked. In other words, config ini files keep things simple for the end user.
The solution, for me, now it seems is I am going to have to learn a new language, YAML. This is to get back to a point where I was before the Check_MK team introduced, in my opinion, an unnecessary level of complexity. Most people aren’t technical like you and I are. Most people are non-technical and their response will be not to learn a new language, but to find a different and easier product to implement. I hope this doesn’t happen to Check_MK as its a good product in my opinion. The Check_MK team needs to look through the eyes of most end users and see how the end user will respond. Simplicity is the key for the end user and it usually leads to a long shelf life of a product.
My configuration was an example how the yaml file works best for most of my systems if i have no baked agent.
Why? The config has nothing to do with your check scripts. It is only a configuration and that’s it.
If you can provide your configuration and the paths used for your scripts it would be easier to give some better advice what you should change.
YAML or JSON configurations are at the moment nearly the default configuration format used in the IT industry. Booth are easy to read and easy to understand.
Why? The config has nothing to do with your check scripts. It is only a configuration and that’s it.
Answer: YAML is new to me. There is still a learning curve. It’s not as simple as you are proposing. For example - in YAML is sensitive to spaces. I would not have known that without researching that to learn it. An improper YAML file means the script will NOT load as has been the case for me.
In fact - one of my application log errors is “Can’t load yaml file ‘C:\ProgramData\checkmk\agent\check_mk.user.yml’, exception: ‘yaml-cpp: error at line 227, column 5: end of map not found’”
YAML or JSON configurations are at the moment nearly the default configuration format used in the IT industry. Booth are easy to read and easy to understand.
Answer: Yes for the IT industry but not necessarily for the simple non-technical end user. The non-technical end user, whom has been using an easy monitoring system, may not take kindly to unnecessary hurdles thrown in the mix which has changed things and caused issues. Even most technical people like simplicity. This is why config ini files are popular even though it’s legacy.
Unfortunately I don’t know how to send private chat. Preformatted text still is presenting the yml file as messy. Do you have a email? Here is mine shandy4473@yahoo.com
Your configuration is mostly the unchanged demo “check_mk.user.yml”.
For your two scripts you don’t need to change anything.
Place the “ADAudit.ps1” to the folder “C:\ProgramData\checkmk\agent\plugins” that’s all.
Same for the Local check but don’t put it inside the plugin folder if it is really a local check.
In your case the “netstat_an.bat” is a plugin and not a local check und needs to be inside the plugins like you configured but not as a execution entry in the local section.
Put booth scripts “ADAudit.ps1” and “netstat_an.bat” inside the “C:\ProgramData\checkmk\agent\plugins” and finished.
After a manual config change you should use the test function of the agent before you try to activate the config.
check_mk_agent.exe showconfig and then reload_config
Your file loads at my system without problem?
And what’s now not working?
To shorten your config file a little bit the following is enough as nothing else was changed in your file.
Your new config
global:
only_from: 172.16.9.240
The following is the config output after a “check_mk_agent.exe showconfig” you see that the plugins and local sections are enabled and that it looks inside the $CUSTOM_PLUGINS_PATH$ for executable files.
Unfortunately this still isn’t working. Looks like I am going to have to resort to another technology to recover the scripting technology that Check_MK was delivering…SMH!!!
Actually I got the MRPE to execute the netstat_an.bat by simply reusing the check_mk.user.example.yml clean code and by not reinstalling the agent. What’s not working is the plugins. Placing a plugin - say like the windows_update.vbs plugin - actually removes 23 of my services. When I remove the vbs plugin, those services return.
The powershell i have to run using a string I remember from the older version calling the powershell.exe format.
I’ll test by removing the agent and reinstalling but I would not be surprised if that doesn’t work.
No luck Mr Andreas. I removed the agent and reinstalled it on a fresh Windows Server 2016 VM. I have went through every iteration of the yaml and plugins don’t seem to be working. The MRPE appears to work which is what I need for my environment. Unless something is wrong with my YAML, I have to come to the conclusion that there is a possible bug in the latest version of Check_MK 1.6.0p17.
In addition - I also tested against another client on a windows server 2008 r2 VM and no luck with plugins working.
Unless someone else can show evidence the plugins actually work in version 1.6.0p17 - i’ll submit for a possible bug to be addressed.
I wrote before with your setup you don’t need to change the yaml files. Only enter the IP.
Where are your scripts at the moment?
Don’t touch MRPE, all your scripts from your config file before where normal plugin scripts.
Give us some information what you see with a clean agent install in your discovery.
Put only one of your checks inside the folder “C:\programdata\checkmk\agent\plugins”.
Check again your discovery. Remember that it takes two times of the normal check interval or two full scans to get the actual data as all plugins are in asynchron execution.
Andreas: I have used powershell scripts with success using MRPE in the past and plan on to continue using MRPE. I have tried every possible iteration, including your suggestion, with no success and its getting a little tiring. I didn’t have this issue when under config ini files as placing the files in the plugin folder worked with no issues, and now there seems to be an issue after migrating to YAML. I tested this on two different nodes running the 1.6.p17 agent and same result…plugins don’t work.
Thanks for everything but I am going to conclude their is a bug that needs to be addressed unless I see some visual evidence to say otherwise.
Closing out thread…as execution of plugin appears to be broken in version 1.6.0p17. Tried on two different nodes on the same Check_MK server. Also tried my 2nd Check_MK server on a 3rd separate node with same result - plugins don’t execute when placed in plugin folder.
Will report as a possible bug on version 1.6.0p17 to the Check_MK team and/or on Github
Hi Steve,
you are right and I understand a little bit that you are wondering why there was a change from ini to yaml.
This change was not done solely because yaml is so f* * awesome, but to develop a better agent.
The CMK team works hard to keep CMK to make it as compatible as possible to any system out there (just think of >1700 checks which come by default!) and at the same time to make almost everything configurable by WATO. If you are using Checkmk since 7 years you know best that the product constantly evolved. This cannot be achieved by always only adding new features and keeping anything else as it is. Sometimes you also have to “break” with former design decisions to make the next big advance. (If you have ever worked with large INI config files of NSclient++, you know why YAML exists. )
Reading/editing YAML files is not that hard as you state, just give it a try - and always remember (also with a little bit of respect to the developers in mind): it was all done to deliver a better product. The YAML you are talking about is perhaps the remaining 0.01% of “complexity” which cannot be hidden by a nice GUI. The other 99.99% is what should really make you happy
I guess there is nothing in the IT world which does not require a little bit of readiness to learn something new from time to time. I even like that
PS:
Even most technical people like simplicity…
Yes… but they also understand easily why some things must change whilst technology is proceeding.
button for preformatted text.
)
