Too Much Time Troubleshooting?
In our State of the Network 2008 Global Study, 75 percent of network professionals cited “identifying the source of a problem” as their primary troubleshooting concern. Most respondents spent at least 25 days per year determining the causes of their issues. In addition to troubleshooting, the study looked at 10 Gb, VoIP, and MPLS trends.

See the study (PDF)

     
   
  Going In-Depth with Applications
According to our recent Network Instruments Global Study, three-quarters of network managers get bogged down in pinpointing the causes of network and application performance problems. Organizations often lack the visibility necessary to identify a problem’s source.


Observer differs from the competition in its in-depth error and performance detail. This information is often the key to solving problems other platforms miss.

Observer's Application Analysis is a powerful tool for quickly identifying or eliminating application causes as the problem source. It shows details such as error count, transaction type, and failed transactions for applications including SQL, Oracle, VoIP, HTTP, POP3, Citrix, MS Exchange, Telnet, SMTP, SNMP, FTP, DNS, and MS Networking (SMB).

Other analysis tools may offer limited response-time reporting, but most fail to present detailed information on application performance or error codes.

The following example demonstrates how Observer's detailed application analysis allows network managers to accurately isolate performance issues they may not see with other analysis tools:

A user complained that access to the accounting database was slow. Was the problem caused by network factors, server issues, or application errors? Other analysis tools showed that application response times appeared normal.

Using Observer's Application Analysis, the network manager drilled into SQL server performance for a detailed view. Although application performance appeared normal, error codes revealed that for every request, the server issued "server not available" errors.

The manager checked the database management console, determined the database was corrupted, and restored it, which solved the problem.

Observer provides detailed, application-specific analysis critical to accurately pinpointing error cause. Without accurate analysis, the network manager would have spent hours attempting to locate the issue.

 

     
   
  Drilling into Errors from Application Analysis
From the high-level errors report in Application Analysis, it is easy to explore error details and drill into packets. To do so, follow these steps:

 

  1. Within Observer's Decode & Analysis screen, click the top Applications Statistics tab, which presents the statistics for the specified device in the capture.

  2. Highlight the application error. In the example, the internal server error is selected. Right click on the error and choose Show Error Detail. This generates the error screen, which lists errors with corresponding request and response packets and times.



  3. To view the specific error packet in the decode, select the error and then choose Go to Response Packet or Go to Request Packet. Depending upon the protocol, this will give you a more detailed view of error information.



 

     
 
may 2008 


Last Month's Answer
Data-stream segmentation occurs in the transport layer of the OSI model. Congrats to last month's winner, Marque Bibbs of Atlanta, Georgia.

This month's question: What OSI layer is frame relay mapped to?

Submit your answer and be entered to win a Network Instruments® polo shirt.

What's the State of Your Network?
Read about trends in MPLS, VoIP, and 10 Gb

NetworkWorld IT RoadMap
Boston, MA
June 18

Cisco Live
Orlando, FL
June 22-26

NIU in New York
June 9-12

NIU in Paris
June 11-13

NIU in Brasted, Kent, UK
June 17-19