Visual Network Systems Blog

Get Behind the Dashboard

ward.cobleigh — Wed, 08 Feb 2012 17:59:12 +0000

Topic:

Application Performance Monitoring

Get Behind the Dashboard

Where did the dashboard originate? According to highly-believable but completely un-verified Internet resources, this mid-1800s invention was originally mounted on horse-drawn carriages and was designed to keep the mud, water, or other debris that flew up from the horses’ hooves off of the passengers. Go without a dashboard and you might be faced with an unpleasant surprise.

Fast forward to our generation and most of us know dashboards as those things in our cars that provide us with Key Performance Indicators, warnings, and fault information. Ignore your dashboard and you might wind up stalled on the side of the road or explaining to the nice officer why you were exceeding established “thresholds”. Brace for segue.

So what should a good IT dashboard deliver? There are a few key capabilities that are essential:

1. The ability to take selected existing views from your current web-based management tools and combine them into a single pane of glass that is purpose-built for a specific need or role. As much as possible these views should be presented in a consistent, cohesive manner that is both pleasing to the eye and promotes efficient workflow. Tip: If your dashboard looks like a ransom note made up of random magazine clippings, there’s likely room for improvement.

existing data

3. The ability to combine both of these capabilities, along with highly-automated, flexible customization and single-sign on

4. Pre-built content and views so that you’re not building your dashboard from scratch

Visual Network Systems recently announced their Service Delivery Dashboard. Why did a leading industry analyst firm describe this as, “a groundbreaking announcement”? Because the Service Delivery Dashboard builds on Visual Network Systems’ proven expertise in performance management and extends that core foundation with the ability to connect, integrate, visualize, and interact with multiple data sources.

Visual Network Systems Service Delivery Dashboard provides powerful data integration and visualization

Imagine integrating best-in-class application performance analysis with the ability to seamlessly integrate with a variety of third-party sources such as service desk, event management, or even other performance management systems. Imagine creating views for Operations, Engineering, Executives, and customers alike that will clearly demonstrate how efficiently and effectively you are supporting key business services and objectives. No more unexpected surprises, no more penalties for exceeding thresholds, no more mud in your face. Get behind the dashboard.

Visual Network Systems’ Service Delivery Dashboard is the result of a partnership and collaboration with Edge Technologies, Inc.

Posted by on Feb 08, 2012

Director, Solutions Marketing & Project Management Edge TechnologiesFull Bio

Virtually Simple

daniel.odonnell — Wed, 01 Feb 2012 00:01:43 +0000

Topic:

Application Performance Monitoring

Live simple. What a nice concept. Our lives in the technology industry, however, seem to be all about conquering the complicated rather than pursuing the simple.

Mobility, virtualization, more data, faster links, new applications and increasing vulnerability all require complex and sophisticated systems to manage and protect networks. Virtualized Desktop Infrastructure growth is increasing bandwidth requirements. Appliances are becoming more specialized so more are required. Connecting the tools without impacting network availability and managing all the appliances at 10Gbps link speeds is now becoming its own specialty.

A Gartner report, “Emerging Technology Analysis: Hosted Virtual Desktops” says the number of virtual desktops worldwide will increase to 66 million by 2014. While this growth of virtual technology is efficient for businesses, it adds complexity to network and application management. The need for greater visibility into network performance and application performance will increase just as dramatically as the growth of network bandwidth and virtual desktops.

Boiling it all down, there is a need to pursue simplicity in this ever more complicated environment. Time spent chasing network issues when the problem is with an application is time wasted. Time spent drilling down through layers and layers of analysis on 10Gbps link traffic can be frustrating while clients are experiencing outages or response time issues. Resolving performance issues proactively and optimizing network performance are more worthy pursuits than troubleshooting problems.

A side note on the business perspective of simple proactive network management…A team focused on trouble shooting is considered a cost center. A team focused on improving network performance and IT ROI is considered a strategic asset to the company.

So, in pursuit of a simple answer, what about a unified system providing end-to-end performance visibility across the network, allowing quick isolation of the root cause of performance issues? What about a solution that solves complex application issues simply? What about a couple of simple tools that are easy to deploy and take only a few RUs of rack space? What about connecting all your 1Gbps links through a port aggregator rolling them up to a few high-speed links for consolidated management? What about proactive network management, resolving issues before the clients even notice problems?

The Network Critical AFS port aggregator and the Visual Networks VPM Xpress 10G combine to provide a complete yet simple solution for link aggregation, network and application management. The AFS and Xpress solution allows network managers in virtual environments, carrier and cloud networks an efficient, simple solution to proactive network and application management.

Simple is good. Follow the links below for more information:

View the Network Critical AFS port aggregator here
Download the Network Critical Aggregating Filtering System (AFS) datasheet here
View the Visual Networks VPM Xpress 10G here
Download the Visual Networks VPM Xpress brochure here

Posted by on Jan 31, 2012

Vice President of Business Development for Network CriticalFull Bio

Managing 10Gb Networks - Key Enabler for Managing "Big Data"

bojan.simic — Mon, 23 Jan 2012 23:16:38 +0000

Topic:

Application Performance Monitoring

Managing 10Gb Networks - Key Enabler for Managing "Big Data"
The need to manage "Big Data" is a major concern for many organizations in 2012, as companies seek to deploy a number of new technologies and approaches to address their business requirements. Some of these projects include:

Each of these trends are causing more data to be transferred across the network and are the key reasons many organizations are viewing 10Gb network connections as a critical business requirement today. TRAC’s recent research shows a wider adoption across industry sectors, when only a few years ago there was a lot of talk in the industry about the need for 10Gb networks, even though at the time it was largely reserved for the Service Provider and Government sectors. Today, deployment of 10Gb network is a major enabler of key IT initiatives.

The ability to manage 10Gb networks has also become one of the key differentiators between vendors that are providing solutions for network performance monitoring. For example, as TRAC was conducting research for network performance, we ran across several instances where customers reported that they decided to switch their provider of network monitoring because the solution started dropping packets once they deployed on 10Gb networks. As a result, the majority of networking vendors have come up with some type of 10G solution, but there are still major differences between their effectiveness in 10G environments. The major difference between capabilities of these solutions is that many of them provide 10Gb interface, but only a few of them can actually handle 10Gb worth of network traffic. Additionally, some of the technologies that are driving adoption of 10Gb networks are based on protocols, such as UDP and RDP, which are known for generating smaller packets. This makes it more challenging to monitor network and application performance and not all of these solutions are showing the same effectiveness in these types of environments.

While deployments of 10Gb is still considered an emerging trend, TRAC’s recent research indicates that organizations are concerned about the future and are placing high importance on deploying network performance monitoring solutions with proven 10Gb capabilities today. For organizations deploying technologies such as virtualization, collaboration applications, business intelligence or Web 2.0 applications many are realizing that a 10Gb connection without deployment of a network solution designed to truly handle 10Gb traffic is limiting the full potential of these key IT initiatives.

TRAC recommends organizations deploying 10Gb networks consider a network solution that not only has a 10Gb interface but a proven ability to handle 10Gb traffic.

Posted by on Jan 23, 2012

President and Principal Analyst TRAC ResearchFull Bio

Have You Ever Just Wanted to (Trouble)shoot Your End-Users?

ward.cobleigh — Thu, 17 Nov 2011 08:00:00 +0000

Topic:

IT Best Practices

We asked, you answered. Next on the list of your biggest application performance problems: Users complain about slow applications.

It happens before you’ve had your first cup of coffee on Monday morning. It happens when you are walking out the door Friday evening. The phone rings, the trouble ticket comes in, the random user drops by to let you know – “It’s slow”. And there it is, the dreaded Layer-8 problem: The bane of our existence and the reason for our existence all rolled into one complaining user.

One reason why this scenario can be a source of frustration is the difficulty involved in simply validating that this user actually has a legitimate issue. What does “slow” mean? When did it get slow? How slow is it? Is it slow for everybody or just this poor soul? Where do you start?

Well, let’s start here:

If you know the user’s IP address and the application that’s giving them trouble, Visual Performance Manager™ instantly provides a comparison between the End-User Response Time (EURT) for that one user, compared to everyone else at that same site, running that same application. This validates the user’s complaint and gives you a sense for the severity of the issue. Visual Performance Manager also allows you to go back in time to see when this problem started occurring.

Now what? How can we identify the problem domain, i.e., is this a network issue, a server issue, or something specific to this application? Well, given that this particular problem is only impacting one user, we could make an educated guess that is isn’t a network issue but fortunately we don’t have to rely on educated guesses.

Visual Performance Manager breaks the EURT into three components:

App Response Time – the time required for an application server to begin responding to a client’s request
Data Transfer Time – the total time required to send the application payload required to satisfy the client’s request
Network Round Trip – network latency

In this example the App Response Time (Blue) is so high that the Data Transfer Time (Yellow) and Network Round Trip (Red) are scaled right off the graph. So we know we have a real problem and – educated guess confirmed – it isn’t a network problem.

Where do we go next? If you want to hear (and see) the rest of the story, please check out this brief video which shows you exactly how Visual Performance Manager can be used to take you from the up-front identification of an end-user’s performance problem all the way down to the specific root cause in just a few clicks.

And remember; don’t take “troubleshooting” literally. HR normally frowns on that sort of thing…

Posted by on Nov 17, 2011

Director, Solutions Marketing & Project Management Edge TechnologiesFull Bio

Whose Job is it Anyway?

aidan.lynch — Fri, 11 Nov 2011 21:26:11 +0000

Topic:

IT Best Practices

The 3rd highest vote in our Twitpoll for the worst application performance problem is “fighting with other IT groups over who is at fault!” Let’s see how Visual Performance Manager can help!
In Douglas Adams’ The Hitchhikers Guide to the Galaxy series, there was a technology that could make anything invisible. This technology was based on the “Somebody else’s problem” (SEP) field: once you make it somebody else’s problem, you cease to see it anymore and it therefore becomes invisible.

Dealing with IT-related problems is, in my experience, a fine example of the SEP technique in action. The network guy gets blamed first, and no matter how much he complains, he will still be go-to guy for all problems in the IT sphere. It’s up to him, then, to prove that it’s Somebody Else’s Problem. I’ve even seen examples of a server team claiming innocence and blaming the network, only to have the network engineers push the problem back to them the next day. But don’t get me wrong, I’m not criticizing: when so many parts of the infrastructure are interlinked, outsourced, optimized and virtualized, is it any wonder that you can’t tell them apart anymore?

While an IT problem spends its time in horizontal escalation hell, the problem is not being fixed. Even worse, it places a cost on the wider team that has a knock-on effect on so many other jobs – it might take just one person five minutes to fix it, but it could take ten people and many hours to decide who that one person is.

So, how do you quickly find the owner of a problem that may be in the network, application or server? Any solution to this must give an insight into how each of those three areas is performing, and in a way that’s recognizable to all three teams.

Visual Performance Manager offers a solution to this mayhem with the method is uses to measure and display the End User’s Response Time. Instead of just saying “the user waited 800 milliseconds for a response”, it also tells you “The data took 100ms to transfer, the round trip time for network packets was just 30ms, but the application itself took 700ms to respond”. These three elements of response time immediately give you a direction in solving the problem. If Network Round-trip is high, then you know to look to the network for congestion, QoS issues, routing problems, etc. If Application Response Time is high, then you know to look to the servers and applications involved.

Visual Performance Manager’s Response Time trend for an application: “the application is slow” is not enough, you need to know “why is it slow” (click to view larger).

A quick check of Visual Performance Manager’s Server Health statistics will identify or rule out the server CPU, RAM and Disk as the cause, and then we’re clear exactly whose job it is. The application guy can take it from there, and use Visual Performance Manager’s powerful analytics to find the root cause for the slowness.

Server Health trends showing a CPU at maximum and memory utilization at 100% puts the server team in the frame.(click to view larger)

Because the basic triage in Visual Performance Manager is so simple, anybody can do it. The network guy wastes no time in being able to show that it’s Somebody Else’s Problem. The application guy has the proof he needs to go and chase the root cause – and with Visual Performance Manager he can find that root cause in just a few clicks.

Posted by on Nov 11, 2011

Product Planner, Visual Network SystemsFull Bio

Quit Blaming The Network!

belinda.yung-rubke — Thu, 10 Nov 2011 20:15:42 +0000

Topic:

IT Best Practices

In our Twitpoll, you have voted the second worst application performance problem is that the network is blamed. OK, network guys (generic), I am sure you can cite lots of statistics, instances, and experiences that the network is NOT to be blamed for application performance problem in greater than 80% of the time!

A few years ago, many of our network customers were looking for ways to prove that it is not the network’s fault in order to throw the problems back at the application support groups. Today, attitudes have definitely changed from being antagonistic between network operations and application support teams to one of cooperation to solve problems for the business users.

In this new spirit of cooperation, the network is not a bad place to start to triage a problem. This is not to say the network is the first place to start looking for the root cause of the problem. It is simply a location where the interaction of many systems can be observed.

I had the opportunity to observe the network and application support team members, from a retail business, collaborating to solve an application problem related to their pharmacy. The trouble ticket came in about the poor response time of a prescription drug application affecting the retail chain’s ability to fill prescriptions for their customers in many locations.

Using Visual Performance Manager, they were able to very quickly exonerate the network by looking at the end user response time of the multi-tier application. The team continued to triage the problem by looking deeper into the specific transactions that were causing the problem and quickly isolated the issue to a database call.

It is very easy to identify the root cause of application performance issues with Visual Performance Manager, see the video example!

Posted by on Nov 10, 2011

Director of Marketing, Visual Network SystemsFull Bio

What’s Typical isn’t Typical

kent.laver — Thu, 03 Nov 2011 23:43:41 +0000

Topic:

IT Best Practices

We’ve all been asked “What’s typical?” And more often than not the answer isn’t that simple. For example the answer to “What’s it typically take to drive across town?” will usually depend on the time of day. Driving across town at rush hour, afternoon and evening are very different.

Application performance is even worse. When troubleshooting user’s performance problems we often want to compare that user’s performance against the “typical” performance. This can quickly confirm whether or not the user actually has a problem and can also tell us how severe that problem is. This is why many Application Performance Management (APM) product’s support features that add “Typical” or “Baseline”performance data into charts and tables. But there can be many different answers to “What’s typical?”And using the wrong one can be very misleading. Unfortunately it’s just too easy for an APM product to take an easy way out by drawing a line on a chart and labeling it “Typical”. Buyers beware!

Let’s consider a specific case: Does a remote user complaining about their Order Entry response time actually have a problem? We want to compare their current performance against the “typical” performance for Order Entry. But application response time can be very different based on the time of day. If the user is seeing their problem during busiest times then in order to get useful information we need to compare that to the typical performance during those same times. Anything else will be misleading. So your APM solution has to let you select the time of day to use when it is displaying the “typical” performance.

Unfortunately there are other gotcha’s with “typical” that can also send us off in the wrong direction. Here’s another one. I wrote above that this was a remote user. Well where is “remote”? It makes a difference. The typical end user response time for users located in Atlanta, Canada, Europe and Asia can all be very different. So when our APM system shows us the typical Order Entry response time is this the “typical” for Atlanta, Canada or where? It makes a difference.

We face exactly the same challenge in environments where applications are hosted on multiple different servers and/or in different locations. Typical performance for user access to one server can be totally different for access to another server.

The bottom line is pretty simple. It’s easy for an APM product to draw a line in a chart and call it “typical”. But that doesn’t mean their data is useful. The Typical Performance Indicator in Visual Performance Manager supports all these considerations. It automatically analyzes performance over the previous weeks to report typical performance for every metric, for all configured times of the day and week, and for every combination of application, site and server. Using the Visual Performance Manager Typical Performance Indicator you will know whether or not the user actually has a problem and how severe that problem is.

End User Response Time of a business critical application is trended and compared to Typical Performance Indicator. (click to view larger)

Posted by on Nov 03, 2011

Visual Network Systems ArchitectFull Bio

Don’t Know If There Is An Application Performance Problem?

belinda.yung-rubke — Thu, 27 Oct 2011 23:20:33 +0000

Topic:

Application Performance Monitoring

Visual Network Systems organized a Twitpoll over the last few weeks to get a vote on the worst application performance problem you have encountered. The votes are in! We will be posting a series of blogs to address the issues you have voted starting with the worst application performance problem.

50% of you voted that the worst problem is “We don’t know there is an application performance problem.”

Most of the IT customers and prospects I have talked to would like to know, before their users do, that there is a problem with an application. Ideally, by the time the first trouble ticket comes in, they are already working on the issue and can tell the user they know about the problem. You see, this is a matter of pride, knowing what is going on in your own house and not have someone tell you something is wrong.

But, knowing there is a problem with an application before it affects the users is easier said than done. We, the vendor community, did not make it any easier to alert and alarm the operations team. Most performance management products on the market can generate alerts based on pre-defined thresholds. In fact, these products generate so many alerts that it is not uncommon for the operations team to turn off this function because the information is useless.

Visual Performance Manager (VPM) took a different approach. From day one, VPM automatically collects performance metrics from the actual application to develop a baseline of the End-User Response Time, the most important metric.

The most common question asked is how long it takes to develop a baseline. The answer depends on how often the application is used. The busier the application the shorter time it takes to establish a baseline. Applications that do not have a lot of use will take longer to establish their baselines. You should ask yourself if an application is rarely used, it is probably not as high a priority to keep track of its response time.

When we designed the baseline and alarms system, we interviewed many people in Operations to understand how they use alerts, thresholds and baselines. The net of the feedback was that most alerts are not useful and they definitely do not want more alarms. VPM only provides baselines for the most important metrics, even though it collects many more. The most important one that impacts an end-user, is End-User Response Time. This metric is collected for all applications that are delivered to the end-users.

When the End-User Response Time baseline of an application is established, deviations from normal will be flagged. The screen below shows the status of a list of applications being monitored. Green means the application is performing according to its normal behavior. Yellow means the performance has degraded and red means the application has severely degraded performance compared to normal. The Status page also shows the sites that are affected by the performance degradation.

This information helps the Operations team be proactive in addressing application performance problems. When they see a “Yellow”, they can start the investigation by clicking on the yellow block to access the Alarm screen. In addition to providing the duration of each incident, the incidents can be filtered to focus on the problematic application.

Operations can further troubleshoot the application problem by clicking directly on the application to look at the performance trend. Indeed the end-user response time has increased during the time block in question.

You can then investigate which application transaction is causing the End-User Response Time to increase. With a single click of a mouse, we can see the transactions that have exceeded the normal End-User Response Time.

In this simple example, the Operations team can get ahead and start to work on application performance problems before they get the first trouble ticket.

Posted by on Oct 27, 2011

Director of Marketing, Visual Network SystemsFull Bio

Using a bucket to save yourself in a sinking boat, are you nuts?

scott.allen — Thu, 27 Oct 2011 19:11:30 +0000

Topic:

Application Performance Monitoring

Using a bucket to save yourself in a sinking boat, are you nuts?

If you’re in the middle of the ocean on a boat that’s sinking fast and all you have is a 10 gallon bucket there are two guarantees:

1.You will fill that bucket as fast and as furious as you possibly can to dump out the water

2. You will sink anyway. Its simple math applied to a very serious situation. A bucket that scoops up 10 gallons of water every 5 seconds can’t keep up with water entering through the hole at a much faster rate.

What you need is a vacuum that pumps out water at a faster rate than water coming in, thus allowing you to find the leak, fix it and float to safety. As with the sinking boat analogy, having an application performance management solution that cannot keep up with high levels of traffic will result in your inability to address performance issues with no hope in sight! Many application performance management platforms give their customers little teeny buckets to scoop up the boatload of data required so solve critical application performance issues.

I recently discovered that a highly touted APM vendor in the market places very little value on their solution with regards to capturing data and keeping up with the traffic. A typical mid to large web application environment generates 250,000 to 300,000 requests per minute. If the application includes a database, such as Oracle or Microsoft SQL, the requests can easily jump up to 700,000 to 800,000 per minute.

This vendor’s new Web Transaction Analysis module can, at best, keep up with 300,000 requests per minute or 1.75Gbps of total analyzed throughput with their highest performing hardware appliance and with capture-to-disk disabled!

Are you kidding me? How is their solution supposed to assemble transactions in a coherent way, on a super-fast 10Gb network, if a database is part of the application architecture, well enough to deliver an APM solution?

Their solution just cannot collect enough data and fast enough to consistently identify and solve problems in a multi-tiered, multi-gigabit and 10Gb core network that processes millions and millions of packets per second! This is something akin to ten dudes with sippy cups trying to rescue the Titanic and ultimately having to leave it sitting at the bottom of the ocean floor.

Having been in the performance management market most of my career, it no longer surprises me when APM vendors take shortcuts where data acquisition is concerned. They spend most of the effort in creating colorful charts and graphs that do not provide useful information to manage application performance. What still surprises me is the sheer and increasing number of vendors who make this fundamental mistake. Inconsistent and inadequate data will catch these vendors in the end as customers begin to see the flaws of poorly designed solutions.

Visual Network Systems is the exception. Our industry leading application performance management solution starts with solid fundamentals in data acquisition and we do not take short cuts! Our high performance 10Gb application performance appliance can analyze 1,000,000 requests per minute or 7Gbps of total analyzed throughput on a sustained basis.

Even our low-end hardware appliance can handle 500,000 requests per minute or 4Gbps total throughput on a sustained basis. Our solution is designed to handle the real-world application traffic that your enterprise, cloud and virtual environments will invariably throw our way!

If you are ready for true advancement in application performance management, see us at http://www.visualnetworksystems.com/opnet.

Posted by on Oct 27, 2011

VP Marketing, Visual Networks SystemsFull Bio

The Other Art of Deception

david.oliver — Thu, 20 Oct 2011 22:00:29 +0000

Topic:

IT Best Practices

As businesses rely more on IT to provide data services, one expectation is that the data itself be maintained in a secure manner. In the last decade, IT management reporting solutions have grown rich with detail, providing additional data points by which to ensure not only delivery, but also security.

Depending on the vendor in question, quite often they tout the level to which they report on security events, with security being the primary focus. Many clients believe that sound traffic analysis provides even better security reporting than typical Network Behavior Analysis (NBA) solutions. The primary reason is that security events that impact the most number of users, also impact the infrastructure, and it’s VERY easy to correlate the security event to the traffic.

Let’s take a look at some common security breaches and see how traffic analysis can identify them.

Social Engineering types of breaches are the hardest to pinpoint. Typically, only a few users are targeted and affected. A recent study reported that having up-to-date mail filters was the number one solution to preventing Trojan horses from replicating. There are many anti-spyware/malware solutions on the market that are all very effective. The resolution to staff not responding to so called “friendly IT support calls” is training. The above points illustrate the reason infrastructure data is not the best metric to observe and to prevent social engineering attacks.

Denial of Service and Brute Force attacks however are extremely easy to locate through infrastructure data, using primarily NetFlow. The NetFlow solution needs to be specifically geared towards traffic analysis, which keeps and reports on all the flows very efficiently. Quite simply, these types of attacks exhibit very few behaviors. Denial of Service or Buffer overflow, will typically originate from many hosts running a script triggering requests to a single host or IP address. Some of these requests can be further filtered to TCP flags because most DOS / Buffer attacks comprise of packets with only the SYN flag set.

When filtering by SYN flag only, the difference between “normal” and “suspicious” is dramatic in the following screen shot.

Virus or Worm activities show up as several- to-many in reporting. This means the few hosts that have been compromised are attempting to replicate themselves by scanning the network, and running the same exploit script. Denial of Service and Brute Force attacks do not generate a large volume of traffic, and will not show up in the culling mechanisms of many TOP-N reporting solutions.

In the following screen, there are two likely explanations for high conversation rate. Sending at a high rate could mean an attack is launched, a worm is propagated or it is running peer-to-peer software (serving files). A client receiving at a high rate could mean it is being attacked or downloading files illegally.

Several solutions on the market brag that they too can report on all the flows, all the time, but do not cut the muster in actual production environments. When evaluating solutions, be sure to put them through the paces to prove they can perform under the extreme scenarios for your environment.

Traffic never lies. There are no false positives. Analysis with all traffic represented will show you what is occurring on your network right now, without fault. Signature based solutions provide the analysis for you, but it can be wrong. Every signature written is based on behaviors exhibited by yesterday’s exploit. How useful is that, when the next swarm of intelligent exploits has learned from, and evolved beyond existing sets of logic? IT staff are highly intelligent and specialized individuals, and should have meaningful accurate data, not someone else’s incorrect interpretation.

Posted by on Oct 20, 2011

David Oliver, Sr. Product Manager, Visual Network SystemsFull Bio