Friday, March 7, 2003, 9:11:36 AM, you wrote: DLW> There are two problems with this approach. A check via a URL affects the DLW> stats generated by IIS for the site being checked. If checking a
Most stat programs have the ability to disregard hits from either a certain IP or on a certain page. For example, we use AWstats from awstats.sourceforge.net, and we have a special page set up in all our sites called Status.asp that does a basic database query against whatever db that site runs on. Then we have checks set up in SA to hit those pages. That way, we not only know that IIS is okay, but we also know that the connection to the database server is okay. In our experience, the web server, database server, IIS, and everything else can all be running perfectly fine - but if someone mucks up the db connection information in the web site, boom, all the pages go down. This is one centralized check that will verify that everything's working cohesively. DLW> Another affect is that restarting w3svc doesn't always bring back ASP DLW> and can cause HTTP/1.1 Application errors on busy servers. Not to mention that it trashes all your session variables, causing your customers to have to log in again on a lot of sites. I've never had to restart w3svc, but of course, that's just me. DLW> As a back up it IS worth checking w3svc via a URL but on a longer DLW> timescan. For instance we scan the w3svc service every minute and HTTP DLW> via a URL (to an ASP page) every 15 minutes. Again, just my opinion, but 15 minutes is too late. If you've got customers hitting your site all day long, and one of them starts getting errors, and then calls your customer support desk before the network admin even knows there's a problem, then you look like an idiot. I run URL checks every 2 minutes, because they're the most critical ones in the organization - if the customers catch you with your pants down, that's what really hurts. -- BrentO Famous last words: Don't worry, it's safe. To unsubscribe from a list, send a mail message to [EMAIL PROTECTED] With the following in the body of the message: unsubscribe SAlive
