In-band monitoring for HTTP.... protect the customer from error pages.

Today's topic is in-band monitoring.

1. The problem
2. The cause
3. The solution

1. The Problem

"404 - Page/Object Not Found", "500 - Server Error". Sound familiar? We receive these errors daily. Sometimes we receive them without noticing - ever noticed an image missing after a page loads?

These are all examples of wasting precious customer time. Customers with high expectations!

2. The cause

Web Applications are made of up both Static and Dynamic elements. Static: A basic web server request to get 'logo.gif'. Dynamic: a request to a database to list all the transactions where username is 'Bob'.

Typically, a 404 is received when a static object is requested of a web server but the object does not exist. Maybe it wasn't copied to the server? Was accidentally deleted? Permission problem? Server has a bad disk? There are a lot of reasons why this can happen but all have the same result. Poor customer experience.

A 500 Server error is usually (I did say usually - not always) returned from the Application Server and could be the result of: a hung process, poorly coded database timeout, over utilised server, code bug.... the list goes on. Before I get flamed by some Application Developers, the code they right is complex and the developers themselves are often under significant pressure from the business to deploy new functionality, to remain competitive. Rapid time to market = rushed code.

3. The solution

In-band monitoring. Why assume that every response from the Web Server or Application Server is a response that you are willing to share with your customer? A 500 Server Error is a valid response, after all! With an in-band monitoring solution you have the option of rejecting a bad response and retrying the request with a different server.

How's this sound in real time: If server A returns 500/404 then try again with Server B. The customer doesn't need to know.