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

[Rob Cotrone]

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:
> https://lists.nongnu.org/mailman/listinfo/monit-general