Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

If you want an overview of how quickly your organization's critical applications respond, you can add the Application Performance Overview widget to a dashboard.
The widget can show information about any application—including web-based activities—that your PerformanceGuard administrator has defined.
You can use the widget to find out if individual computers or locations experience longer response times than others. This can help you identify, for example, if network problems cause an application to work slowly when particular colleagues use it.
Application Dashboard

The PerformanceGuard application dashboard (DASHBOARDS > Application Dashboard) gives you an overview of the status of important applications in your organization.
The application dashboard shows you whether applications perform on an acceptable level. If not, it will show you the extent to which your organization is affected. You can drill down to see exactly which subnets and computers affected.
Typical examples of applications are Exchange servers, domain controllers, DNS, file servers, or any other business-critical applications. It's your PerformanceGuard administrator who defines which applications you can view.
It's possible to view multiple types of status for a single application. For example, you can monitor availability as well as response times for the same application, if your PerformanceGuard administrator has set that up.
Colors Show Application Status
On the application dashboard an application can have one of four states:

  1. Normal (green): Everything is fine.

  1. Warning (yellow): Some users are affected.

  1. Error (orange): A higher number of users are affected.

  1. Critical (red): An even higher number of users are affected.


The thresholds that define when the status changes are set up by your PerformanceGuard administrator.
Why is it possible to see a green status, even though it says that some users are affected?  This may happen if, for example, your administrator has decided that 3 users must be affected before the status should change.
Status Is Updated Every Minute
Watch the thin blue line at the top of the application dashboard to see the amount of time that remains until the next update.
If you don't want to wait, click the Update Now icon to update the application dashboard manually.
Drill Down to View Affected Users
With the application dashboard you can quickly drill down from a general application status to the individual affected users and computers:

  1. Click the application status:

  1. You can now see which locations/networks are affected, and how many users are affected at each location/network:


Click a location/network name to drill further down.

  1. You can now see which computers are affected at the selected location/network:


Click the name of a computer to view details about the individual computer.
Special user rights may be required to view details about individual computers in your organization. Ask your PerformanceGuard administrator if in doubt.
Video: Use Application Dashboard
Can't you view the video?  Do you use Internet Explorer? Older versions of Internet Explorer may have difficulty displaying video content. This will often be the case if your computer runs Windows XP, which can't use the latest versions of Internet Explorer. Try to view this help in a browser like Chrome instead. Do you use Firefox? If the video is "black," the video will often load if you click the Pause button. If not, try to view this help in a browser like Chrome instead.
Set Up the Application Dashboard
You can only do this if you're a PerformanceGuard administrator.
See Application Dashboard Setup for Administrators.
Frequently Asked Questions About Availability
The application dashboard is able to show the availability of applications, 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.
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.
Application Report
In addition to the normal IP traffic reports aggregated by location, you can also view aggregated IP traffic data per computer per application.
Aggregation is the gathering of separate data in a summarized form. If, for example, you have performance data about a computer from every minute that computer has been online, you can aggregate that data into an average from every hour. That way, you won 'tneed to store so much data, but you'll still be able to view trends in the computer's performance. Read more in Aggregation of Data.
In PerformanceGuard the term application doesn't necessarily mean a single software program. Instead it means a collection of things that your organization finds it meaningful to measure the performance of together. Therefore, your PerformanceGuard administrator must have defined these things and set up trend aggregation before you can use application reporting; see Set Up Application Reporting.
If we assume that everything has been set up, here is how to run an application report:

  1. Select ANALYZE > Computers > Application Report.
  2. Select the required application (remember that an application can be a collection of things that your organization finds it meaningful to measure the performance of together).
  3. In the Agents menu, select required group of computers.
  4. Select required interval. If the predefined intervals don't suit you, select Custom to specify your own interval.
  5. Click the Run button.
  6. After a short while you can select between downloading your application report as an Excel spreadsheet, adding it to a report, or exporting it.

Application View
The application view graph (ANALYZE > Graphs > Time View > Application View) shows the availability and response times of applications that are automatically contacted by representative PerformanceGuard agents at regular intervals. This requires that your organization has set up application pings. See Monitor Availability, Latency and Response Times with Application Ping for details about how to create and activate an application ping.
This graph is useful because ... it lets you verify application availability and response times over time, as experienced by all or individual parts of your organization.

  1. Application Ping: Select required application ping. Application pings may be based on ICMP pings, HTTP requests or traceroutes. The type of application ping is listed in brackets after the application ping name.
  2. Agents: Select the group of computers that the graph should be based on.
  3. Interval: Select the period of time that the graph should cover. If the predefined intervals don't suit you, select Custom to specify your own interval.
  4. Availability Detail: Controls how often availability should be calculated for the graph.
  5. Y-axis Min and Max: Specify the range that you require for the graph's vertical axis. If you leave the fields empty, the range will automatically reflect the minimum and maximum values found in the data.
  6. Disconnect samples: The samples in the graph will by default be Automatic. If you don't want this you can select Connect All or set them to Disconnect All .

Connected samples
Disconnected samples
Response time is plotted as a red line, availability is drawn in green.

If no data is available for a time period, the availability line isn't broken. Instead the missing time period gets the same value as the previous period.
When you view the graph, you'll also see a Statistics table below the graph. Note that the Statistics table shows the weighted average for the graph's samples. That means that each value to be averaged is assigned a weight based on the number of occurrences of that value.
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.
Is performance good or bad? That depends on the type of work that you do in your organization, but you can often follow our rules of thumb.
Compare Web Activities

With the Compare Transaction bar chart (ANALYZE > Graphs > Combined Bar Charts > Compare Transactions) you can view the performance of multiple web activities based on a transaction filter.
This graph is useful because ... you can compare web-based 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.

  1. Transaction filter: List of defined transaction filters that contain data.

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.

  1. Server & Port: Select required server and port combination.

You can only select server/port combinations for which the selected transaction filter has yielded results. Therefore, the option All does not include every server/port combination known by PerformanceGuard, but only all server/port combinations for which the selected transaction has yielded results.

  1. X-axis Min and Max: Enter the required range for the bar chart's horizontal axis. If you leave the fields empty, the range will automatically reflect the minimum and maximum values found in the data.
  2. Type: Determines which type of data the bar chart will contain. You can view descriptions of the available types in Graph Terms & Definitions.
  3. Agents: Select the group of computers that the bar chart should be based on. Super groups, that is groups of groups, are enclosed in <>.
  4. Interval: Select the period of time that the graph should cover. If the predefined intervals don't suit you, select Custom to specify your own interval.
  5. Transaction: Select one or more transaction tags from the selected transaction filter. To select multiple tags, press CTRL on your keyboard while you select.

What's a transaction tag?  The PerformanceGuard agents installed on your organization's computers look out for the things that your transaction filter specifies. When an agent detects one of those things, it generates a transaction tag and sends it to PerformanceGuard so that you are able to select it when you want to view a transaction graph or create SLA items. In other words, a transaction tag is a thing to look out for that one or more agents have positively found.
What if there are no tags to select?  If there are no tags to select, it's simply because none of the selected computers have made a web request that matches the selected transaction filter. When no computers have made such web requests, the PerformanceGuard agents on the computers have not yet generated any transaction tags, and that's the reason why there are not any tags that you can select.
In the PerformanceGuard web interface you can also view periodical trends in transaction response times, availability, etc. as well as detailed transaction data (that is transaction data that hasn't been aggregated into trend data).
Web Activities (Time View)
PerformanceGuard normally collects data on a TCP packet-basis, but if your organization has defined transaction filters, you can dig further down into web requests and return information about specific elements, such as URLs, cookies, etc.
This graph is useful because ... you can check 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 Transactions graph (ANALYZE > Graphs > Time View > Transactions) helps you with this.

  1. Transaction filter: Select required transaction filter.

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.
What does the prefix mean?  The prefix tells you about the type of transaction filter: IE is aimed at Internet Explorer. It monitors web requests as they are experienced in that browser. HTTP monitors directly on the network interface rather than in the browser. Response times for the HTTP type are thus often slightly lower than for the IE type.

  1. Server & Port: Select required server and port combination. You can only select server/port combinations for which the selected transaction filter is defined.
  2. Agents: Select the group of computers that the graph should be based on. Super groups, that is groups of groups, are enclosed in <>.
  3. Y-axis Min and Max: Enter the required range for the graph's vertical axis. If you leave the fields empty, the range will automatically reflect the minimum and maximum values found in the data.
  4. Type: Determines which type of data the graph will contain. You can view descriptions of the available types in Graph Terms & Definitions.
  5. Hide thresholds ...: Only relevant for one type of data: Transaction response time.

For such data, a threshold—that is a baseline that the displayed values must ideally be below—can be displayed as a horizontal line in the graph when:

    1. Your PerformanceGuard administrator has defined such thresholds
    2. You have selected one tag in the Transactions field (if you have selected multiple tags, threshold display is not available, because thresholds can be different across tags)

You may sometimes see more than one threshold on a graph. This is because your PerformanceGuard administrator is able to set up multiple thresholds for the same type of data. This can be useful in order to indicate different severities, for example if values above 80 are acceptable for short periods of time, whereas values above 90 require immediate attention.
On the graph each threshold has a name, so it is easy for you to see what the threshold is about.
Display of thresholds is by default on. When you generate or view a graph, you can toggle threshold display off by selecting Hide thresholds. This can be useful, for example if you think that a threshold blocks your view of the graph's data points.
If a graph has thresholds, the thresholds will also appear if you use the graph in a report, except when they're hidden.
Displayed thresholds are always the currently valid ones.

  1. Transaction: Select one or more transaction tags from the selected transaction filter. To select multiple tags, press CTRL on your keyboard while you select.

What's a transaction tag?  The PerformanceGuard agents installed on your organization's computers look out for the things that your transaction filter specifies. When an agent detects one of those things, it generates a transaction tag and sends it to PerformanceGuard so that you are able to select it when you want to view a transaction graph or create SLA items. In other words, a transaction tag is a thing to look out for that one or more agents have positively found.
What if there are no tags to select?  If there are no tags to select, it's simply because none of the selected computers have made a web request that matches the selected transaction filter. When no computers have made such web requests, the PerformanceGuard agents on the computers have not yet generated any transaction tags, and that's the reason why there are not any tags that you can select.

  1. Interval: Select the period of time that the graph should cover. If the predefined intervals don't suit you, select Custom to specify your own interval.
  2. Disconnect samples: The samples in the graph will by default be Automatic. If you don't want this you can select Connect All or set them to Disconnect All .

Connected samples
Disconnected samples
When you view the graph, you'll also see a Statistics table below the graph. Note that the Statistics table shows the weighted average for the graph's samples. That means that each value to be averaged is assigned a weight based on the number of occurrences of that value.
In the PerformanceGuard web interface you can also view periodical trends in transaction response times, availability, etc. Furthermore, you can compare transactions.
Web Activities (Trend View)
PerformanceGuard normally collects data on a TCP packet-basis, but if your organization has defined transaction filters, you can dig further down into web requests and return information about specific elements, such as URLs, cookies, etc.
This graph is useful because ... you can check how long it takes for computers on all or individual parts of your organization to get responses when they make web requests. This in turn can help you verify how efficiently users are able to work with web-based applications.
The Transactions trend view graph (ANALYZE > Graphs > Trend View > Transactions) reveals any periodical trends.

  1. Transaction filter: Select required transaction filter.

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.

  1. Server & Port: Select required server and port combination. You can only select server/port combinations for which the selected transaction filter is defined.
  2. Agents: Select the group of computers that the graph should be based on. Super groups, that is groups of groups, are enclosed in <>.
  3. Trend Period:

Example: If you select Day, the graph will display one data point per day.
An hour-based trend period is particularly useful when you view data from up to one week. A day-based trend period is useful when you view data from up to one month. A week-based trend period is useful when you view data from more than one month. A month-based trend period is useful when you view data from more than six months.

  1. Type: Determines which type of data the graph will contain. You can view descriptions of the available types in Graph Terms & Definitions.
  2. Hide thresholds ...: Only relevant for one type of data: Transaction response time.

For such data, a threshold—that is a baseline that the displayed values must ideally be below—can be displayed as a horizontal line in the graph when:

    1. Your PerformanceGuard administrator has defined such thresholds
    2. You have selected one tag in the Transactions field (if you have selected multiple tags, threshold display is not available, because thresholds can be different across tags)

You may sometimes see more than one threshold on a graph. This is because your PerformanceGuard administrator is able to set up multiple thresholds for the same type of data. This can be useful in order to indicate different severities, for example if values above 80 are acceptable for short periods of time, whereas values above 90 require immediate attention.
On the graph each threshold has a name, so it is easy for you to see what the threshold is about.
Display of thresholds is by default on. When you generate or view a graph, you can toggle threshold display off by selecting Hide thresholds. This can be useful, for example if you think that a threshold blocks your view of the graph's data points.
If a graph has thresholds, the thresholds will also appear if you use the graph in a report, except when they're hidden.
Displayed thresholds are always the currently valid ones.

  1. Transaction: Select one or more transaction tags from the selected transaction filter. To select multiple tags, press CTRL on your keyboard while you select.

What's a transaction tag?  The PerformanceGuard agents installed on your organization's computers look out for the things that your transaction filter specifies. When an agent detects one of those things, it generates a transaction tag and sends it to PerformanceGuard so that you are able to select it when you want to view a transaction graph or create SLA items. In other words, a transaction tag is a thing to look out for that one or more agents have positively found.
What if there are no tags to select?  If there are no tags to select, it's simply because none of the selected computers have made a web request that matches the selected transaction filter. When no computers have made such web requests, the PerformanceGuard agents on the computers have not yet generated any transaction tags, and that's the reason why there are not any tags that you can select.

  1. Interval: Select the period of time that the graph should cover.

What does the interval X days mean?  If you select X days, you can define your own period, for example 90 days (which would cover the last 90 days). This can be particularly useful if you are going to include the trend graph in a report: Many organizations generate monthly trend reports that each cover the last 90 days. This would not always be possible with the Last Quarter interval, but with the X days interval you can easily generate such reports.
If the predefined intervals don't suit you, select Custom to specify your own interval.

  1. Y-axis Min and Max: Enter the required range for the graph's vertical axis. If you leave the fields empty, the range will automatically reflect the minimum and maximum values found in the data.
  2. Disconnect samples: The samples in the graph will by default be Automatic. If you don't want this you can select Connect All or set them to Disconnect All .

Connected samples
Disconnected samples

  1. Fitted line: Include a fitted regression line (that is the best-fitting straight line through the graph's points).

Data is aggregated on a per-period basis. The available periods depends on the PerformanceGuard configuration (ADMINISTRATION > Reporting > Period).
Average values on trend graphs are based on a weighted average. That means that each value to be averaged is assigned a weight based on the number of occurrences of that value.
In the PerformanceGuard web interface you can also view detailed transaction data (that is transaction data that hasn't been aggregated into trend data). Furthermore, you can compare transactions.
Server/Port
The Server/Port bar chart (ANALYZE > Graphs > Combined Bar Charts > Server/Port) shows performance information about an application's response time, sent bytes, received bytes, etc. for a particular group of computers. By selecting multiple servers and services, you can compare the behavior of different applications.
In this context an application is one port on one server, for example TCP port 80 (http) on server www.w3.org.
This graph is useful because ... you can compare the performance of a single server across multiple ports, the performance of multiple servers on a specific port, etc.
By selecting multiple servers and services, you can compare the behavior of different applications.

  1. Servers: Select which servers to include in the chart. You can select multiple servers if you press the CTRL key while you select the required servers. Only monitored servers are listed, see server administration for details.
  2. Ports: Select which ports to include in the chart. You can select multiple ports if you press the CTRL key while you select the required ports. Only monitored ports are listed, see port administration for details.
  3. Agents: Select which group of computers that the bar chart should be based on.
  4. Type: Determines which type of data the bar chart will contain. The options are described in Graph Terms & Definitions.
  5. X-axis Min and Max: Enter the required range for the bar chart's horizontal axis. If you leave the fields empty, the range will automatically reflect the minimum and maximum values found in the data.
  6. Interval: Select the period of time that the graph should cover. If the predefined intervals don't suit you, select Custom to specify your own interval.

Is performance good or bad? That depends on the type of work that you do in your organization, but you can often follow our rules of thumb.
BTM Tags/Agents
With the BTM Tags/Agents bar chart (ANALYZE > Graphs > Combined Bar Charts > BTM Tags/Agents) you can compare transactions and groups of computers with respect to availability, response times and number of requests for transactions reported by the PerformanceGuard BTM feature. By selecting multiple tags and computer groups you can compare combinations of these tags and groups.
BTM, Business Transaction Monitoring, is a feature for monitoring complex activity that involve multiple steps and/or multiple servers. It essentially works as a stop watch that lets you record the time it takes to execute a complex activity. BTM is very flexible: PerformanceGuard simply provides a set of building blocks that your organization can use to integrate with other applications and define relevant transactions.
A transaction is some sort of complex activity that your organization wants to measure, for example how long time it takes to connect to a price database and update product prices. Due to the flexibility of BTM many types of activity can be measured as a transaction, depending on what's relevant in your organization. If the names of transactions and transaction groups in your organization are not immediately meaningful to you, ask your PerformanceGuard administrator for advice.
This graph is useful because ... you can compare transactions, including transactions across groups of computers. This way you can, for example, verify if all of your organization's locations are able to carry out transactions without problems or delays.

  1. Transaction group: Transactions may grouped, for example into finance transactions, human resources transactions, etc. If that's the case in your organization, select which group of transactions you want to base the graph on.
  2. Transaction: Select which transaction you want to base the graph on. If you selected a transaction group in the previous field, you can only select transactions from that group.
  3. Tags: Select which transaction tag (if any available) you want to view on the graph. You can select multiple tags by pressing the CTRL key while you select tags.

What's a tag?  A transaction tag is used to identify a variant of a transaction. For example, if you have a transaction called Print, you could have a Color tag for color prints and a Grayscale tag for non-color prints. Tags are not always used, so don't worry if you are not able to select any.

  1. Type: Determines which type of value the graph will contain, for example response times in seconds.
  2. Agents: Select which computer groups the bar chart should be based on. You can select multiple groups by pressing the CTRL key while selecting groups.
  3. X-axis Min and Max: Enter the required range for the bar chart's horizontal axis. If you leave the fields empty, the range will automatically reflect the minimum and maximum values found in the data.
  4. Interval: Select the period of time that the graph should cover. If the predefined intervals don't suit you, select Custom to specify your own interval.

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.

  • No labels