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_namecheck_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_namecheck_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_comm
