Quantcast



Docs

Blogs

Forums

Samples

Media

Labs

Resources
 




DevCentral > Weblogs > Deb Allen - DebCentral
 Monitoring WebSphere with the LTM HTTP Monitor
posted on Tuesday, August 05, 2008 11:58 AM

imageIn researching my tech tip last week (Replacing the WebSphere Apache Plugin with iRules), I ran across another interesting tidbit about monitoring WebSphere with LTM that apparently is not documented in the Deployment Guide (Deploying the BIG-IP LTM system and IBM WebSphere Servers.

The Deployment Guide was written for WebSphere ver. 6.0, and demonstrates creating an HTTP monitor with a simple GET request over HTTP 1.0.  We've had recent reports from the field that at least for version 6.1, you actually have to use an HTTP monitor that sends the GET request over HTTP 1.1 with the required hostname specified as * (asterisk), which seems to allow the servers to respond to the request.  (Using the VS hostname or any other string doesn't seem to work.)

Here's a solution that details how to construct a proper Send string for an HTTP 1.1 monitor: 

SOL2167: Writing full HTTP commands for Extended Content Verification (ECV) or Extended Application Verification (EAV) health monitors

Email This
  del.icio.us
      

Feedback

8/6/2008 6:07 AM
Gravatar Not 100% sure, but I think the issue is how WebSphere is configured for accepting inbound request. I don't know the exact term as I'm not the WebSphere person, but I know we had issue trying to do anything through the F5 to WebSphere in the beginning.

The problem was that WebSphere during the install was setup with a single specific virtual host name that defaulted to the host name of the server. The WebSphere group had to configure a virtual server with the name of "*". Prior to that we would get an error that there was no virtual server configured to handle that application.

I'm glad to see we are not the only ones trying to use the F5 in place of the WAS Plugin.
giltjr
8/6/2008 2:30 PM
Gravatar Thanks for the feedback. I'm obviously no WebSphere expert myself, and sometimes it's not terribly clear how ubiquitous an issue like this might be, so it's good to hear some validation from the real world!
deb
8/12/2008 3:24 PM
Gravatar The problem is most likely how WebSphere's virtual host settings are defined. At application deployment, you bind a specific virtual host to a web module. WebSphere matches the host:port definitions in the virtual host and the context root of the web module to those same values on the incoming request. If they don't match, you'll get a virtual host exception. By specifying a * value on the incoming request, it might work, but you're better off adding the correct host:port combination to the WebSphere virtual host.
brett
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 5 and 8 and type the answer here:

Copyright 1996 - 2008 F5 Networks, Inc. | Privacy Statement | Terms Of Use