# Manage Thresholds and Events > Define event rules, alert rules, and notifications so PerformanceGuard reacts when performance becomes unacceptable. Source: https://docs.capaone.com/performanceguard/administration/manage-thresholds-and-events/ Product: PerformanceGuard — a separate CapaSystems product; do not apply this page to any other. :::caution 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. :::note[Important] **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. ::: :::note[Important] **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: ![](/attachments/performanceguard/9f147815-dd04-4772-b62b-daef0ba59c41.png) 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 ![](/attachments/performanceguard/930a7625-82f7-4dcf-baaa-63d96bd439f1.png) sends performance data ![](/attachments/performanceguard/8af0f193-6f67-448c-9871-502eae6825d1.png) to PerformanceGuard. The same applies for all other computers in the organization. - In PerformanceGuard you set up an event rule ![](/attachments/performanceguard/5e88325b-99f6-490d-8e19-0162382474fb.png) . 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 ![](/attachments/performanceguard/00befb95-2dfc-415b-b95b-5cff68341f00.png) 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 ![](/attachments/performanceguard/5e88325b-99f6-490d-8e19-0162382474fb.png) . 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 ![](/attachments/performanceguard/00befb95-2dfc-415b-b95b-5cff68341f00.png). - 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 ![](/attachments/performanceguard/09bcf35e-2580-4e47-af7b-2b1525ae7c44.png) is generated and delivered on the location dashboard and sent to recipients ![](/attachments/performanceguard/fd38a2e8-ddf8-42ec-a8fc-97ede0aff249.png) 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** :::caution 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. :::tip 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. :::tip 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** :::caution 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. :::caution 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 Applications](/performanceguard/administration/network-applications/web-applications/)**. ::: 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. :::caution 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. :::caution 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. :::caution You can only do this if you're a PerformanceGuard administrator. ::: :::caution You must have set up the PerformanceGuard [Manage SMTP Notification Service](/performanceguard/administration/more-setup/manage-smtp-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. :::caution 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 Applications](/performanceguard/administration/network-applications/web-applications/)**. ::: 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. :::caution 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. :::caution 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**. :::tip 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 [Alert Rules](/performanceguard/administration/manage-thresholds-and-events/alert-rules/). 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. :::caution Ignore the **Email summary reports** field. ::: :::tip 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 [Manage SMTP Notification Service](/performanceguard/administration/more-setup/manage-smtp-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. :::note[Important]
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: ![](/attachments/performanceguard/93888b87-6818-4dcd-91f7-fa865e16d521.png)
::: ## **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** :::caution 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](/performanceguard/administration/manage-custom-reports/set-up-health-kpi-report/).