Blind Troubleshooting | NETSCOUT


Blind Troubleshooting - Still A Leading Cause of Unresolved Problems in IT

Try this exercise when you get a few minutes. Grab a 100 piece puzzle, put on a blindfold, dump out the pieces on a table, and put the puzzle together.

Possible? Well, if we force the pieces to fit together we may technically be able to connect all the pieces, but once we lift the blindfold things may look a little messy.

This illustrates the situation that IT engineers of today may find themselves in. Network and application problems are increasing in their scope and complexity, and solving them requires complete client to back-end database visibility. Why? To answer that, let’s take a look at the life of a client request from client keystroke to server response to consider how many devices along the way are required to support it. Then we can determine if there are gaps in visibility in our own IT environment.

Client Keystroke to Application Delivery

First, the client connects to the application server(s). Let’s assume that these are located in a data center we control, and not in a public or hosted cloud environment. Also, let’s assume the person is connecting from a conference room via a laptop over wireless. To connect, the client must first connect to the WiFi environment, achieving a data rate and signal that is clear enough to support the application throughput. After authenticating with the domain, the client requests the application server IP from the DNS server which then allows it to connect to the application server(s). On their way to the server environment, packets from the client may then traverse any number of network devices, both physical and virtual, which may include MPLS or other WAN environments from a service provider.

Once in the data center, a request may initially be processed by a load balancer, which will forward it to an available front end server. At this point, the application may require back-end transactions to application or database servers, which may be present on the same or adjacent virtual environments. After a response is formed, it is finally transmitted back to the client on a similar network path, hopefully without congestion or packet loss.
Of all these components in the packet lifecycle (there may be more in some environments), how many are we effectively monitoring? This would include not only present-second monitoring for issues that are happening now, but also back-in-time data for intermittent problems that seem to come and go. After thinking about all the components required to deliver high-performance applications, we may find that there are major gaps in our visibility, making us blind in these areas when troubleshooting problems.

The OptiView XG and TruView other provide the comprehensive tools necessary for complete end-to-end visibility of application delivery. The OptiView XG provides present-second and back-in-time data for the wireless and wired network environments, including the detailed Visual Path Analysis features which pinpoints network problems in the packet path. In the application environment, the TruView leverages stream-to-disk packet storage, application response time, transaction analysis, and flow data to isolate problems to a single link, server, or transaction.
With these two products, blind spots in network and application visibility are a thing of the past. This allows IT engineers to quickly and clearly find the root cause of problems affecting performance.


Related IT Networking Resources
For more information on OptiView XG and TruView, click here.

OptiView XG v10: Best IT Hardware Bronze Award –– Network Products Guide Awards – 2013
Watch Video: Prove It’s Not the Network
Case Study: Bosch Group Automates Network and Application Analysis