Manage Thresholds and Events

You can only do this if you're a PerformanceGuard administrator.

An event is a threshold violation on an individual computer or server, for example a response time that isn't acceptable.

PerformanceGuard detects events based on event rules. Event rules define what it should take for PerformanceGuard to register an event.

Example of a simple event rule: Register an event if it takes more than 90 seconds to start up any of your organization's computers.
Example of a complex event rule: Register an event if a computer at your organization's Berlin location experiences a response time that's higher than 1 millisecond when it tries to get a file from file server X, Y or Z on port 139 or 445.

When events happen, you can view them on the dashboards in PerformanceGuard.

In PerformanceGuard you manage events through a set of rules that determine how each event will be processed if it occurs. Together the rules form a chain—the event management chain:

If similar events happen on multiple computers within a short time, it's often the sign of problems. In such cases you can also automatically get an e-mail from PerformanceGuard, so you can react quickly.

Event Management Chain

Let's pretend that you are the PerformanceGuard administrator in an organization where CPU usage on computers should ideally not be higher than 95%:

  • The PerformanceGuard agent on your office computer sends performance data to PerformanceGuard. The same applies for all other computers in the organization.

  • In PerformanceGuard you set up an event rule . The event rule defines what must happen in order for an event to occur. In your case an event will occur if CPU usage exceeds 95% on any of your organization's computers. You give the event rule a severity level of Informational.

  • If the data meets the event rule's criteria, an informational event occurs. Event rules apply to data from one computer at a time only, and each event that occurs is therefore related to one computer only. Each occurred event is unaware of other events that have occurred based on the same event rule.

  • You then set up an alert rule . The alert rule defines if and how occurrences of your event will be processed. In your case you define that PerformanceGuard should react if more than 25% of the computers at your organization's Headquarters location experience the event within a three-minute period. In other words, you use the alert rule to filter the occurred events, so that PerformanceGuard will only react if there is a pattern of some significance to you.

  • If the events meet the alert rule's criteria, PerformanceGuard will react and raise an alert .

  • Now you set up a notification rule . The notification rule defines the criteria that must be met in order for PerformanceGuard to automatically generate a notification. It also defines whether the notification should be sent out via e-mail, displayed on the location dashboard, or both. In your case, you define that a notification should be generated if there is an alert of the severity level Warning that is related to your organization's Headquarters location. You also define that the notification should be displayed on the location dashboard and sent via e-mail to personnel at the Headquarters IT Helpdesk.

  • If the notification rule's criteria are met, the notification is generated and delivered on the location dashboard and sent to recipients via e-mail as required.

Built-in Event Rules

PerformanceGuard comes with some built-in event rules, for example one that says that it must take a maximum of 90 seconds for your computers to start up. If it takes longer, PerformanceGuard will register an event for each affected computer.

Most of the built-in event rules automatically work from the moment you install PerformanceGuard.

  • If you're a regular PerformanceGuard user, you'll typically see events when you work with dashboards. Events get their names from the event rules.

  • If you're a PerformanceGuard administrator, you can manage and edit the event rules: Select Administration > Event Management > Event Rules.

Three of the Built-in Event Rules Need Information Before they'll Work

You can only do this if you're a PerformanceGuard administrator.

There's a built-in event rule called DNS Response Time that says that DNS servers should respond in less than 50 milliseconds. However, before that event rule will work, you need to tell PerformanceGuard which of your servers are DNS servers. The event rule is intelligent enough to automatically look for servers in a group called DNS, but if the DNS group doesn't contain any servers, the event rule won't work.

So, you need to place your DNS servers in the DNS group:

Select ADMINISTRATION > Server > Groups and click the menu next to the DNS group to add members to the group.

In principle you also need to tell the event rule which ports to look at, but PerformanceGuard knows that DNS uses port 53, so it has automatically placed port 53 in a DNS port group and selected that group for the event rule.

PerformanceGuard has two similar built-in event rules for domain controller and file server response times. Those two event rules also need information about which servers you want them to cover, so again you must place your domain controllers and file servers in the relevant groups.

PerformanceGuard already knows which ports domain controllers and file servers typically use, but you can change the ports if you want: Select ADMINISTRATION > Port > Groups.

Create Your Own Event Rules

You can only do this if you're a PerformanceGuard administrator.


If the built-in event rules don't cover your needs, you can set up your own event rules.

  1. Select ADMINISTRATION > Event Management > Event Rules.
  2. Click the New Event Rule button and select the required type of event rule.

    Some of the event rules have prerequisites: For example, if you want to create one of the Transaction event rules to monitor web-based work processes, you must have set up at least one Web Application.
  3. When you have selected your event rule, fill out the Basic Information and Trigger Values sections. Most of the fields are self-explanatory, so we'll focus on the few that aren't. Different event rules have different fields, so you may not see all of the following fields when you set up your event rule:
    • Trigger Period: The period of time for which the threshold must be violated before PerformanceGuard should register an event. You can use this setting to limit the number of events, for example if you're not interested in events based on short peaks.

      PerformanceGuard looks at the average value within the trigger period. If, for example, you have specified a lower threshold of 95 and a trigger period of three minutes, the event will happen if the average value is equal to or greater than 95 for three consecutive minutes.
    • Monitored Process: You can only specify one process per event rule. You don't need to write an .exe extension, like outlook.exe. It's OK to just write outlook.
    • Lower Threshold:This threshold determines the value that must be exceeded in order for the event to happen.

      A few event rules look out for values that go below the threshold. This is the case if you create event rules about available memory, or if you create the event rule Computer - Network Offline (where the threshold defines the minimum number of computers that must have dropped off the network within the delivery interval in order for a network to be considered online). In those cases it's still the Lower Threshold field that you should fill out.
    • Upper Threshold: Only relevant if you want to create several near-identical event rules that each cover specific intervals, for example 70-79, 80-89 and 90-100.
  4. Don't fill out the Event Information section if you're just going to use your event rule in dashboard widgets. PerformanceGuard only needs the information if you're going to use your event rules for more advanced things, like automatically getting e-mails when events happen.
  5. Click the Create button.

Get E-Mail when Events Happen

If similar events happen on multiple computers within a short time, it's often the sign of problems. In such cases you and/or your colleagues can automatically get an e-mail from PerformanceGuard.

It's slightly complicated to set up automatic e-mails based on events, but it's also extremely flexible. If you follow these instructions, you'll be fine.

You can only do this if you're a PerformanceGuard administrator.
You must have set up the PerformanceGuard SMTP e-mail notification service before you begin.
  1. Select ADMINISTRATION > Event Management > Event Rules, click the New event rule button, and select the required type of event rule.

    Some of the event rules have prerequisites: For example, if you want to create one of the Transaction event rules to monitor web-based work processes, you must have set up at least one Web Application.
  2. When you have selected the type of event rule you want, fill out the required fields. Most of the fields are self-explanatory, so we'll focus on the few that aren't. Different event rules have different fields, so you may not see all of the following fields when you set up your event rule:
    • Trigger Period: The period of time for which the threshold must be violated before PerformanceGuard should register an event. You can use this setting to limit the number of events, for example if you're not interested in events based on short peaks.

      PerformanceGuard looks at the average value within the trigger period. If, for example, you have specified a lower threshold of 95 and a trigger period of three minutes, the event will happen if the average value is equal to or greater than 95 for three consecutive minutes.
    • Monitored Process: You can only specify one process per event rule. You don't need to write an .exe extension, like outlook.exe. It's OK to just write outlook.
    • Lower Threshold:This threshold determines the value that must be exceeded in order for the event to happen.

      A few event rules look out for values that go below the threshold. This is the case if you create event rules about available memory, or if you create the event rule Computer - Network Offline (where the threshold defines the minimum number of computers that must have dropped off the network within the delivery interval in order for a network to be considered online). In those cases it's still the Lower Threshold field that you should fill out.
    • Upper Threshold: Only relevant if you want to create several near-identical event rules that each cover specific intervals, for example 70-79, 80-89 and 90-100.
    • Event Categories: Only relevant if you create multiple event rules, and you want to group them into areas of interest. If you want to know more, read Use Categories to Group Events and Alerts in the following.
    • Event Severity: You can use the severity to determine how the event will be processed by PerformanceGuard. In your case, you've already decided what should happen, so just select the default severity, Normal.

      If you used the Upper Threshold field to create near-identical event rules that each cover specific intervals, for example 70-79, 80-89 and 90-100, you can use the severity to differentiate between them. Example: You create an event rule that's triggered by 90-95% CPU usage, and you select the severity Warning for that rule. You then create another event rule that's triggered if CPU usage is above 95%, and you select the severity Critical for that rule.
  3. When you've created your event rule, pause for a moment and read this—it'll help you understand why the next steps are necessary:
    • Remember that an event happens on an individual computer. One event on one computer is not always important enough for you to react.
    • That's why you can use alerts to ensure that there's a critical mass of events before you react. For example, you can say that a certain number of computers must have had an event for a certain period of time before you want to react. If that happens, PerformanceGuard will register an alert.
    • You set alerts up through rules, just like you did with events.
  4. Now select Alert Rules in the menu and click the Create new alert rule.
  5. When you've created your alert rule, select Notification Recipients in the menu. Are the people who should receive e-mail notifications on the list?
    • If yes, continue to the next step.
    • If no, use the New Notification Recipient button and add the required people.

      Ignore the Email summary reports field.
      If you use the Test button, the recipient should receive an e-mail with the subject Test message from PerformanceGuard. If the test goes wrong, check two things: 1) That you have entered the correct e-mail address, and 2) that you have set up the SMTP e-mail notification service correctly.
  6. Select Notification Rules in the menu, click the Create new notification rule button, and fill out the fields. Here, we'll just mention two of them:
    • Minimum Alert Severity: Select the same alert severity as you did in step 4, Normal.
    • Recipients: You must actively select the required recipients so that their names get highlighted in the list.

When you've created your notification rule, you're ready.

 What does an e-mail notification look like?

It contains timestamped details about the alert and event as well as information about what made the event happen on each affected computer. Click the thumbnail to view an example:

Really Simple Way to View Events and Alerts

If you can live without automatic e-mails or dashboard updates, you can view events on a simple list: Select REPORTING > Events.

Remember that an event happens on an individual computer. One event on one computer is not always important enough to cause concern. That's why you can use alerts to ensure that there's a critical mass of events before you want to know about it. For example, you can say that a certain number of computers must have had an event for a certain period of time before you want to know about it. If that happens, PerformanceGuard will register an alert.

If your organization uses alerts, you can view alerts on a simple list: Select REPORTING > Alerts.

Use Categories to Group Events and Alerts

You can only do this if you're a PerformanceGuard administrator.

If you have multiple event rules and/or alert rules, you can use categories to group events and alerts into areas of interest. It's not a requirement for events and alerts to work, but it can be convenient. That's because you can use the categories to determine how PerformanceGuard should react on certain categories of events and alerts.

PerformanceGuard comes with some built-in categories. For example, there are built-in event and alert categories for network-related issues. You can use those categories to, for example, make sure that your network people get e-mails if enough computers are affected by any network-related event.

If the built-in categories don't cover your needs, you can set up your own categories: Select ADMINISTRATION > Event Management > Event Categories or ... > Alert Categories.

Events and Alerts Are Also Used for KPI Reports

PerformanceGuard KPI (Key Performance Indicator) reports are based on alerts, and thus also on events. Notably, the alert rule setting Alert Period determines the downtime (also known as the unhealthy period) when PerformanceGuard calculates KPI values.

The built-in event rules and alert rules ensure that KPI reporting works, but you can adjust the settings to suit your organization's needs. Read more in Set Up Health KPI Report.

Search this documentation

On this page

In this section