PerformanceGuard agents are the tools that report the status and performance of individual computers to PerformanceGuard. You must install a PerformanceGuard agent on each computer that you want to monitor.

You can install agents manually or through a software distribution system. If in doubt, see Install PerformanceGuard Agents.

One of the big advantages of PerformanceGuard is that you don't have to configure the agents that you have installed on your organization's computers. That's all taken care of automatically: When you deploy agents, they immediately connect to PerformanceGuard and get basic configurations. You can of course change those configurations later if required.

You manage agent configurations through agent configuration groups. PerformanceGuard comes with two built-in agent configuration groups with settings based on typical customer needs. Your organization's agents automatically become members of those groups.

If you want to adjust the built-in agent configuration groups, or set up your own ones, see Manage Agent Configuration Groups and Agent Configuration Group Settings.

Which servers are the most important ones in your organization? Are they also the ones that you're likely to want to monitor with PerformanceGuard? Are those servers all located inside your organization, or do you use servers on the internet too?

You need to ask yourself this, because your users communicate with thousands of servers, and PerformanceGuard will detect all of those servers. That's fine, but do you want to have to scroll through lists of thousands of servers every time you want to view something in the PerformanceGuard web interface? No.

Fortunately, PerformanceGuard helps you: It automatically places the 30 most used servers on a list known as the Monitored Servers list. It's servers on that list that you can select from when you want to view something about servers in PerformanceGuard.

It's a good idea to review and edit the Monitored Servers list (ADMINISTRATION > Server > Server List), because:

• Some of the servers that PerformanceGuard has automatically added may not be relevant for you to monitor, even though they are used a lot. For example, there may be proxy servers or print servers that you don't want to monitor. When that's the case, you can remove them from the Monitored Servers list.
• If some of the servers that are important to you are not on the Monitored Servers list, go to the Discovered Servers list (that's the list of all servers that PerformanceGuard has detected), select the required servers, and then add them to the Monitored Servers list.

Almost the same principle applies for network communication ports (ADMINISTRATION > Port > Port List): The Monitored Ports list contains 10 ports that are typically used a lot, but it's not automatically updated with the most used ports.

• If some of the ports that are important to you are not on the Monitored Ports list, go to the Discovered Ports list (that's the list of all ports on which PerformanceGuard has detected communication), select the required ports, and then add them to the Monitored Ports list.

When you're done, you'll have highly targeted lists of servers and ports, and that'll make it easy for you and your colleagues to view information on graphs, etc. in the PerformanceGuard web interface. If you ever need to investigate a server or port that isn't on the monitored list, you can simply add it from the discovered list.

PerformanceGuard dashboards provide overviews of related types of performance information.

The Dashboards are made up of Widgets. Widgets are smaller elements that each show a particular type of information.

When you place multiple widgets side-by-side on a dashboard, you get an excellent overview of related information. This can, for example, help you identify causes and effects in a single view.
See Dashboards and Widgets for a short introduction to dashboards and more detailed descriptions of each available widget.

PerformanceGuard can help you with many typical performance information needs. Note that this list is by no means exhaustive; you have many other options for finding information in PerformanceGuard.
This is what to do when you want to know ...

... If a Computer Has Problems

You get a call from a user. Her computer is slow—can you fix it, please? The first thing that you want to determine is whether the computer really is slow. If yes, the next thing you want to find out is what slows the computer down.
The Computer Overview dashboard (Dashboards > Computer Overview) has a Computer Event Timeline Widget that makes it easy to determine if a selected computer has had performance problems. If it has, the widget makes it easy to see exactly which problems the computer has had, and exactly when they happened.
The widget looks at events that have happened on the selected computer, and displays them as bubble markers on a timeline. Remember what an event is? It's a threshold violation, for example a response time that isn't acceptable. You can zoom in on relevant events and click the bubbles to view details.

... If a Problem Affects One or Multiple Computers

When a user calls you about a problem, you often need to determine the scale of the problem: Whether the user's computer is the only one that has the problem, or whether other computers have the same problem.
The Computer Overview dashboard (Dashboards > Computer Overview) tells you just that. When you look up a computer on that dashboard, its Computer and Neighborhood Status Widget compares the performance of the computer with the performance of other computers nearby.

Click the thumbnail to view an example where the problem clearly only affects a single computer.

... Who Uses Resources

PerformanceGuard helps you identify resource-consuming users and processes in seconds.

Who Uses Most CPU Power and RAM?

PerformanceGuard helps you quickly identify your "resource thieves:" processes and users who consume excessive amounts of resources like CPU power and RAM.

1. The quick overview: The Processes and Users graph (ANALYZE > Graphs > Combined Bar Charts > Processes & Users) provides the overview in an easy-to-view bar chart format, no matter whether you are looking for resource-consuming users or processes.

1. The details: The Process Resources hotspot (ANALYZE > Overview > Hotspots > Process Resources) provides detailed data about resource-consuming processes, and you can drill down to view which computers and user accounts ran a given process.

... Who Generates Most IP Traffic

Do you suspect that something is eating up your bandwidth? Or do you simply want to know if a particular application or location generates a lot of traffic? Would you like to know when traffic occurs? PerformanceGuard provides the answers:

Which Applications Generate Most IP Traffic?

In PerformanceGuard an application consists of a server/port combination, for example server.organization.org on TCP port 80 (HTTP).
The IP Traffic by Application time view graph (ANALYZE > Graphs > Time View > IP Traffic by application) shows which applications generated IP traffic, and when they did it. You can view this data for combinations of all servers and ports, groups of servers and ports, and individual servers and ports.
The graph is also available in a trend view variant. It contains the same type of information, but the trend variant is more suitable if you want to view data from more than the last few days.
If you simply want to find out if a particular program (such as Skype) generates a lot of traffic, it is often easier to look for the process (such as skype.exe) instead. See Which Processes Generate Most IP Traffic? in the following.

Which Processes Generate Most IP Traffic?

1. The quick overview: The Load Overview (ANALYZE > Overview > IP Traffic > Load Overview) is a pie chart that very quickly lets you find the processes that are responsible for the largest amounts of IP traffic. When you generate the pie chart, try to select Type = Processes and Data type = Load (Sent + Received Bytes).

1. The details: The Process Traffic hotspot (ANALYZE > Overview > HotSpots > Process Traffic) provides detailed data about traffic-generating processes, and you can drill down to view details about which servers the process communicated with as well as details about which computers and user accounts ran a given process.
2. The timing aspect: The IP Traffic by Process graph (ANALYZE > Graphs > Time View > IP Traffic by process) is ideal when you want to check if certain processes generate traffic at specific times. You can view this for all servers, for groups of servers, or for individual servers.

Which Locations Generate Most IP Traffic?

The IP Traffic by Location time view graph (ANALYZE > Graphs > Time View > IP Traffic by location) shows which locations that generated IP traffic, and when they did it. You can view this for individual servers and ports that the locations have communicated with.
The graph is also available in a trend view variant. It contains the same type of information, but the trend variant is more suitable if you want to view data from more than the last few days.
If you want to compare locations, select all the locations you require in the graph's Agents list. Don't simply select All agents because that won't let you view the traffic generated by individual locations.

... If Some Servers Are Overloaded

Look at server response times: If many of a server's responses are slow, it is typically because the server's hardware is not able to cope with the amount of work that the server has to do.

Do Servers Respond Quickly?

The Response Time Histogram displays response times for selected servers.
To view the histogram, select ANALYZE > Graphs > Statistics > Histogram.
The histogram consists of 10 individual bars.
Each bar represents the percentage of replies within a given milliseconds interval.
This way you can very quickly find out if a particular server is potentially overloaded—like the blue one in the example image.

In the example, we use the histogram to spot a potentially overloaded server. However, the main benefit of the histogram is that it helps you verify if a high average response time is caused by a major or a minor ratio of the total requests. This in turn can help you determine whether a high average response time is really a problem.
How can a high average response time not be a problem?  If a high average response time is caused by a few responses in the 2000-500000 milliseconds interval while the majority of responses are in the 0-10 milliseconds interval, the high average may not be a problem. This of course also depends on your type of organization, which types of applications and servers you run, how business-critical your applications are, etc.

Can Servers Handle Pressure?

The Response Times Versus Load graph (ANALYZE > Graphs > Statistics > Response Time Versus Load) can help you uncover otherwise hidden scaling problems.
If response times increase to a non-acceptable level when the number of requests per second increases, it's very likely the result of an overloaded server getting more requests than it can handle.

In the example (click thumbnail to view image in full size), the gray server responds quickly no matter how many requests it gets. However, the response times (horizontal axis) of the purple server dramatically increase when the server gets many requests (vertical axis)—a typical sign of an overloaded server that could benefit from a hardware upgrade in order to perform better at busy times.
In the example, the gray server responds quickly no matter how many requests it gets. However, the response times (horizontal axis) of the purple server dramatically increase when the server gets many requests (vertical axis)—a typical sign of an overloaded server that could benefit from a hardware upgrade in order to perform better at busy times.

... If Web-Based Applications Work Efficiently

The PerformanceGuard transaction filters feature is highly useful for monitoring web-based applications.
What's a transaction filter?  It's a definition of things to look out for in a web request—for example images so that you can measure how long it takes before all images on a web page are available for the user to view in his or her browser. Transaction filters are very flexible: PerformanceGuard administrators can define more or less any element of a web request as a thing to look out for.

How Long Does It Take to Get Responses?

The Web Activities (Time View) graph (ANALYZE > Graphs > Time View > Transactions) shows you how long it takes for computers on all or individual parts of your organization to get responses when they make web requests. This can help you verify how efficiently users are able to work with web-based applications.
The graph is also available in a trend view variant. It contains the same type of information, but the trend variant is more suitable if you want to view data from more than the last few days.

Does a Specific Element Cause Trouble?

The Compare Web Activities graph (ANALYZE > Graphs > Combined Bar Charts > Compare Transactions) lets you compare the various transactions under a single transaction filter. That way you can, for example, detect if a specific element of a web request takes longer to access than other elements.
In the example (click thumbnail to view image in full size), it is evident that one of the elements in the web request takes much longer to access than the other elements.

... If Network Latency Causes Trouble

The Traceroute Graph (ANALYZE > Overview > Trace Route > Trace Route Graph) helps you quickly detect any network latency.
A traceroute detects and captures the path that a network packet will travel from a given starting point (a computer that has the PerformanceGuard agent installed) to a specific destination.
While PerformanceGuard detects the route, it will also record the network latency between different routers along the route until reaching the final destination. The results are displayed as an easy-to-understand network map.

The traceroute graph requires that your organization has set up traceroutes. Read more about traceroutes and other similar types measurements in Monitor Availability, Latency and Response Times with Application Ping.

... If Performance Is Good or Bad

The answer to this question depends almost entirely on the type of work that you do in your organization. However, there are some rules of thumb, that it makes good sense to follow in almost any type of organization: See When Is Performance Good or Bad?

Frequently Asked Questions About Availability

Many PerformanceGuard graphs are able to show the availability of servers, etc., but what is availability?
When is something considered to be available?  To answer this we need to look at response times: If response times are so long that use of a service, website, transaction or similar becomes impossible, PerformanceGuard considers the service, etc. to be unavailable. By default, PerformanceGuard loses its patience with a service, etc. if it hasn't responded within 500,000 milliseconds (that's a little more than eight minutes). Everything that's not unavailable, is considered by PerformanceGuard to be available. So, if you see that a service has been 100% available during the last week, it means that it has not exceeded the acceptable response time limit during the last week. Do you measure availability of application pings (HTTP requests, ICMP ping and/or traceroutes)?For application pings, PerformanceGuard looks not only at acceptable response times, but also at whether a response is expected or not: If the response is unexpected, for example if the response has a response code of 404 Not Found, PerformanceGuard considers the service to be unavailable, even if the response was received within acceptable time.
How does PerformanceGuard calculate the availability %?  PerformanceGuard looks at the ratio between failed requests and all requests in percent. In other words: (all requests − failed requests) / all requests × 100
I just set up a new server. Nobody has used it yet. How can it be 100% available?  Bear in mind that PerformanceGuard looks at your new server based on how the PerformanceGuard agents experience it: If none of the computers with PerformanceGuard agents have used the new server, there have not been any unacceptably long response times, and the server has thus not been unavailable. Everything that's not unavailable, is considered by PerformanceGuard to be available, and that explains the 100% availability, even though nobody has yet used your new server.
When you're ready for more, simply try out the many different graphs, reports, dashboards, etc. Each of them have matching help, so just click the help icon if you need to know more.