You may want to try actually grabbing a couple-byte monitor page in your case from the load balancers and parse it and look for a special string inside it, that's what we do and that works well. This method not only tests if a connection is being opened, but more thoroughly tests server internals (i.e. Tomcat if you're using mod_jk for instance). And since they're all valid requests we can just do a simple <container>SetEnv var</container> or SetEnvIf var and CustomLog !var to filter out the noise, that way no Perl overhead. BTW, we're doing our health checks every 5 seconds not every 1 second.
Dave At 10:31 PM 8/29/2002 -0400, [EMAIL PROTECTED] wrote: >My solution to the complaints was to use piped error logs and have a >simple Perl script as the first script in a pipeline. The Perl script's >only job was to remove those error messages and then pass the log line >on to cronolog. > >The reason for taking such a measure was because the server farm was >behind a pair of commercial load balancers which made TCP connections to >port 80 and port 443 ** every second ** to health check that the servers >were alive and accepting connections within a reasonable response time. >Then, it shut down the connection, without attempting any SSL negotiation. >So every second, every server was logging two SSL failure messages (from >each of the redundant load balancers). Talk about noise in the logs! > >It would be Real Nice (tm) if these sort of SSL error messages weren't >reported unless some sort of data was exchanged above the connection >level. Only in those cases would the SSL error message be correct that >SSL negotiation failed, as opposed to not even having started. > >-Glenn
