Dear Marc, Thanx for you elaborate feedback. The joke is somewhat on me, but more on that in a second. You're documentation is good and to the point!
The configuration I used was a apt-get installed nagios3 on Ubuntu 9.10 which seems a recipe from a modern kitchen. I ofcourse totally agree with you that you can't be responsible for how other distro's deploy your (marvelous piece of) software. Then for laughs .. I have set up a major Nagios cluster in the past. You can check here whether or not my Nagios knowledge is good enough: http://www.gerardjp.com/2007/05/12/nagios-remote-eventhandling-for-init-scripts/ (RFE'd the $MAX_CHECK_ATTEMPTS$ which was incorporated in a newer release btw) Anyway, in that aformentioned nagios setup, I used to check for a list of urls, from 2 different nodes running nrpe. It must be pure coincidence that these two nodes did run a webserver themselves. I now realize that I never checked the intended urls, but just the websites running on these nodes. Ah well .. one lives and learns :) Thanx again! On 15-04-10 14:45, Marc Powell wrote: > > On Apr 15, 2010, at 3:50 AM, Gerard Petersen wrote: > >> Hi All, >> >> I've been testing with the check_http service. I always was under the >> assumption that the setup below would check www.example.com > > Why did you make this assumption? It's not documented to work like this. > >> check_command check_http!www.example.com!/ > >> With this service definition (as often installed out of the box): >> >> define command{ >> command_name check_http >> command_line /usr/lib/nagios/plugins/check_http -H '$HOSTADDRESS$' >> } > > It's not been like this in a long time I believe. Perhaps you've installed > from a distribution specific package and they've deviated from current > nagios? If so, there's nothing that we can do about that. This is what the > official package uses -- > > # 'check_http' command definition > define command{ > command_name check_http > command_line $USER1$/check_http -I $HOSTADDRESS$ $ARG1$ > } > > Note that your assumed configuration still wouldn't work here but the > official documentation expects this definition. See 'Monitoring HTTP' at > http://nagios.sourceforge.net/docs/3_0/monitoring-publicservices.html. > >> Wrong! It would check for a webserver on myhost1. Since there's nothing >> running at myhost1:80 i got a TCP error. Somewhat baffled I've been tailing >> the access.log of www.example.com to see when I actually got a hit. > > >> The funny thing is this (with no additional parms) even returns ok, would >> you have a webserver listening on myhost1:80 >> >> check_command check_http > > This is because your command_line doesn't use any of the params you think > you're passing it ($ARG1$, $ARG2$). > >> So, you would be wise to turn the command syntax into this: >> >> command_line /usr/lib/nagios/plugins/check_http -H '$ARG1$' -u '$ARG2$' > > Or follow the example documented use of the plugin. In general, you can't > make assumptions about how a plugin works without looking at, and > understanding, the defined command_line for that plugin. Every one is > different. > >> Then this will actually test www.example.com: >> >> check_command check_http!www.example.com!/ >> >> Is it me or is this check_http setup misleading? (ubuntu 9.10 in this case) > > No, but that would depend on the documentation you're referencing to use the > plugin. If the ubuntu documentation says that your format works with their > packaged version of the check_http command definition, then that is > misleading and they should correct that. Otherwise it looks like you made an > incorrect assumption about how something worked without understanding it. If > I buy a car from a dealer and they tell me it runs on diesel, fill it up with > diesel and it doesn't, then that's their fault. If they don't tell me > anything about it and I assume it does without reading the manual, that's my > fault. > > For a new admin, the simplest use case is just to check that a web server is > listening on a host. That's what your definition does and what the official > definition does if no additional parameters are passed. As an admin becomes > more familiar with the plugin and more sophisticated in what they want to do > they need to edit either one or both of the command_line and check_command in > your case but only the check_command in the official case. I think the > official way provides the most flexibility all around, IMHO. > > -- > Marc > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Nagios-users mailing list > Nagios-users@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 > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Nagios-users mailing list Nagios-users@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
