Re: [Nagios-users] check_http (bogus) setup
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_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 >
Re: [Nagios-users] check_http (bogus) setup
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 > > define service{ > use generic-service > host_name myhost1 > service_description http - www.example.com > 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$' > } > > 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. > Why would you assume it would check www.example.com? Your service definition clearly tells it to check $HOSTADDRESS$, which is the address of the host the service is defined on. > 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 > > So, you would be wise to turn the command syntax into this: > > command_line/usr/lib/nagios/plugins/check_http -H '$ARG1$' -u '$ARG2$' > > 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) > It's you. The plugin's parameters, and the value of Nagios's macros, are all very well-defined and well-documented. -- 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
Re: [Nagios-users] check_http (bogus) setup
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_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
[Nagios-users] check_http (bogus) setup
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 define service{ use generic-service host_name myhost1 service_description http - www.example.com 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$' } 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 So, you would be wise to turn the command syntax into this: command_line/usr/lib/nagios/plugins/check_http -H '$ARG1$' -u '$ARG2$' 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) If you do have a webserver running at myhost1 that's the url you check. So you might see an OK status and think you're testing www.example.com .. but you would never touch it. Anybody experienced this? Regards, Gerard. -- 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