Hi Greg,
Maybe a few more background questions are in order

.
When you say "This health check seems to create a session but not terminate it..", what do you mean?
Does the web application generate a session for the request because the request doesn't contain a valid session identifier?
Is the problem that these sessions aren't terminated soon enough? Does the application run into problems when too many sessions are open?
How would a client tell the web application that they're done using the application and that the app can terminate their session? Is there a logout URI that instructs the app to kill the session?
Are there any objects in the application that can be accessed where the application does not generate a session? If so, this would be an ideal object to use in the monitor.
To answer some of your questions:
"With this default configuration, I know the F5 performs an HTTP GET as its health check for the pool, and I assume for each physical server in the pool."
-- Yes, bigd sends an HTTP request using the send string to each pool member that the monitor is configured for. The port information does not need to be specified in the monitor as bigd uses the pool member definition for the request destination.
"What I did not understand was that there is some HTTP GET string I can create for Send strings that would be able to HTTP GET and then terminate/close the session."
-- You can configure any single HTTP request for bigd to send as long as it's valid HTTP using a stock HTTP(S) monitor's send string. The concept of "session" is something that is specific to the application--not the HTTP protocol or bigd. If the application allows a client to send a request which either doesn't trigger a session being created, or tells the application that it should terminate the session, you could configure this as the send string in a stock monitor.
If there isn't a way for a client to send a single request which doesn't generate a session, there should be a way to do this with multiple requests. If that's the case, you could create an external monitor which references a script. The script would make the series of requests which determine whether the application is responding correctly. This could be as simple as using Curl ([urlhttp://curl.haxx.se/docs/manpage.html">Click here) to send one request for the page you want to monitor and then a second GET request with the session identifier from the first request which tells the app to terminate the session.
A stock HTTP(S) monitor is significantly less resource intensive, so you should try that if you can. If you do need to make multiple requests for one monitor polling, the Codeshare (
Click here) has some good examples. Here is an example for sending an HTTP GET request with Curl (
Click here). And here is an example for using Curl to make an HTTP POST request (
Click here). You would need to modify one of these examples to make the first request verify the response is okay, parse the session identifier that the server sends, make a second request to the app with the session ID to tell the app to close the session and then respond to the monitoring daemon with confirmation that the pool member is up.
"'GET /train HTTP/1.1\r\nHost: \r\nConnection: Close\r\n' Is this all I need with no receive string? I am assuming that the "Host" and "Connection" pieces are populated automatically via the F5 request."
-- The send string is what bigd sends to the pool member. The only changes to the request are the \r\n's are replaced with actual carriage return/linefeeds:
GET /train HTTP/1.1
Host:
Connection: Close
Most applications aren't configured to require a host header value, so I didn't include one in that example. The Connection: Close header tells the server to close the TCP connection. This doesn't have anything to do with the applications "session". If you want to dynamically change the request that bigd sends to the pool member, you'd need to use an external monitor.
Hopefully this makes a bit more sense?
Aaron