[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Capture program/script output and display on service page?

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

Thank you for the advice. I'll try working from the myprogram structure and see how that works out.

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 code

While 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:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]