New Module IDEA
Andreas Ericsson
ae at op5.se
Wed Mar 24 00:01:37 CET 2004
joerg.helmert at aracomp.de wrote:
> Hi Jeff,
>
> I like the idea of checking multiple things with one service definition.
Can be useful, but only when you have several servicechecks running
toward one and the same machine (like disks, which you mention).
> I compare it to the way, check_disk works.
> I would not like to define a service for each mounted disk ;-)
>
There is however the issue of different warning levels. The root
partition, which shouldn't really be written to much, needn't be checked
with such strict options. Any data-gathering partitions needs be with
stricter threshholds. How do you separate those?
--[ snip ]--
> Of course suppressing the good ones is also possible with that plugin output
> but may not be needed.
>
A must, if it is to scale beyond 4 jumbled service checks.
>
> I saw another approach within the sap-plugins, available from one of Suse's
> ftp-servers.
> Since nagios does only show the first line of plugin output, these plugins
> are able to return results in a html-table.
BAAAAD idea. If plugin output gets cut short, you get a twisted table in
the web-interface windows. If this exceeds 99 levels, some web-browsers
(MSIE) will crash.
Also, if output exceeds 2048 chars without \n, 'undocumented things' may
happen.
---[ snip ]---
> There's one caveat:
> The html output produces lots of unvisible characters, which will be counted
> against MAX_PLUGIN_OUTPUT and another limiting value (currently at home, can
> provide it tommorrow).
> Default is around 380 characters. So output of big tables will be truncated.
> I increased these values up to 2048.
The buffer Nagios uses to read this in is 2048 bytes wide to start with.
I don't think it's any smaller in the cgi's, but if you didn't check,
parsing the logs might make the cgi's crash.
>
> Again, what do you think?
>
Bad Thing.
>
> One thing at the end:
> I think the approach with a shell script checking urls one by one has one
> caveat:
> If several urls show slow response times, the plugin will need a long time
> to finish.
> I'm testing with www.yahoo.com and had response times up to 8 seconds till
> now.
> I saw even more on high loaded pages fed from databases.
> Solution would be, to run the checks in parallel.
> Do you think it is woth the effort?
No. Nagios runs checks in parallell as it is, so moving all that to a
script which doesn't seems a bit silly to me. For disks I can agree, but
that can be done with the use of one of two things;
A) a single snmpwalk down the .1.3.6.1.2.1.25.2.3.1 tree.
B) a check performed remotely, which effectively removes load from the
server running the nagios core, and saves the time it takes to do the
networking / handshaking part of NRPE / SSH / RSH or whatnot.
> Maybe it would be better to change from bash to something else?
>
If you're looking for parallellization without race conditions, then
yes. You'll need an industrial strength programming language for that
(i.e. C or C++). Make sure you have the glibc documentation package(s)
installed and do 'man pthread_create' if you're interested in how to do
it properly.
> Joerg
>
--
Sourcerer / Andreas Ericsson
OP5 AB
+46 (0)733 709032
andreas.ericsson at op5.se
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
More information about the Users
mailing list