|
From: | Rob Cotrone |
Subject: | Re: Capture program/script output and display on service page? |
Date: | Tue, 26 Nov 2013 22:33:38 -0500 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 |
I understand that monit uses the exit status of the program as the protocol and not the string data.
NAGIOS also uses exit codes. The string data is more for a human approach. It was cool how nagios presented the text data.I could go to a page and get a birds eye view of all resources and the numerical and text values. In the nagios logs I could capture the history for the checks and see trends.
For the new use I'm exploring, I'm interested in capturing SMART data on an array of hard drives. I did not see a SMART test as a built in check. Which means I need to script it.
No biggie, but I want to see the whole output.The users I work with want to see the current status of a value rather then just an exit code. I.E. There are a 'few' smart values used to determine and pending issues with hard drives on an array. Pending sectors, uncorrectable sectors and/or a high amount of reallocated sectors. In any error case, these values and where they are determine what we do in handling a drive with impending failure. Many times a drive with only a few pending sectors can have the sectors refreshed or forced to reallocate and the drive will still be usable. So we want to know which values are having issues with a program test and not have to program each test as a separate shell. 30 hard drives with 3-4 tests each. Temperature, age, smart values, etc, etc. could get unmanageable.
One test of a number of drives, reporting any have pending issues, plus documenting them in the first 256 bytes of data would be helpful.
There are other pieces of data the end users would want to see in a monitor situation.
Monthly they do a scrub/parity check of the data.They would want to see the status (alerted) and where in the parity sync process the current status is. So data from the program is useful, especially if it gets mailed/and or SMS'ed, etc, etc.
As far as OK, well it's a comfort thing. A successful parity check test program might say something like.Parity check is update to date, Last parity check was: x days ago, finding 0 errors, next check is on mm/dd/yy.
In other areas and message systems, we also add hyperlinks to documentation and other access points.
We don't need to see allot of data. I see the buffer is 256 bytes normally, that should be enough. Thanks for the advice. I'll post back once I get it working. On 11/26/2013 11:00 AM, Jan-Henrik Haukeland wrote:
On 25 Nov 2013, at 22:32, Rob Cotrone <address@hidden> wrote:Is it possible to capture a program(plugin) script output and display it on the service page?Yes, but this require some minor modifications to the codeWhile looking at the source I've seen that if a failure occurs, stdout, then stderr, are captured into the event structure. I modified the cervlet.c to display it if it exists. It's working a bit. * The one thing that is missing is the actual program/plugin output display. I'm used to popping up NAGIOS, getting a birds eye view of all service plugin output data, not just a success or failure, but a few lines of data from the plugin(program) output. When showing users monit, some users balked, because they could not see the output of their test scripts via the browser interface.In Monit, most of the standard checks are built-in and do not rely on plugins. The program check you refer to do not use a plugin output “protocol” to determine if the check succeeded or not like I believe Nagios does. Instead we simply test the exit code of the program. In case of an error, i.e. the program exited with an unexpected status, the output from the program will be included in an alert, otherwise no output is displayed. The web-ui does display the last known exit status of a program. I’m not sure I see the benefit of displaying the _output_ from the program in the web-ui if everything is okay? In case of errors I can see this might be useful, even though you do get the output in an alert. What do others think? In any case, if you want to always display the last output of a program in the web-ui I suggest you copy the approach used to display the latest exit status of the program. Expand 'struct myprogram' in monit.h with a buffer to hold the program output. I suggest a static buffer of some reasonable size so you don’t have to allocate/free every time. Then in validate.c:check_program read the output from the command and copy into the myprogram buffer at the same place in the code where the exitStatus is copied. To display the output from the program in the Web-UI, again use the same approach we use to display program exitStatus in cervlet.c:print_service_params_program. That should be it. -- To unsubscribe: https://lists.nongnu.org/mailman/listinfo/monit-general
[Prev in Thread] | Current Thread | [Next in Thread] |