Event types are predefined types of events that you can base your event rules on:

AutoSteps

For AutoSteps activities registered in PerformanceGuard, the following event types exist:

• Availability: An event can occur if a transaction isn't responding.

   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.

• Response Time: An event can occur if one transaction response time exceeds a threshold value in milliseconds.

Citrix

For all monitored Citrix sessions you can set absolute thresholds for :

• Session Latency: An event can occur if latency exceeds a threshold value in milliseconds.
• Session Startup Time: An event can occur if startup time exceeds a threshold value in milliseconds.

Computer

Computer event types relate to computer/desktop activity:

• Any Process CPU Usage: If any process on a computer exceeds a CPU usage threshold value, an event can occur. This can be useful for detecting runaway processes or harmful software.
• Machine Resource Usage: If a computer exceeds a total CPU, memory or context switch threshold value, an event can occur.
• Network Offline: If, in a network group, the number of computers that send data goes below a certain limit, the network group is considered to be offline, and an event can occur. The number of computers in a network group must be more than three to trigger the event.
• Network Retransmissions: If the total number of TCP retransmissions for a computer exceeds a threshold value in percent, an event can occur.
• Process Resource Usage: If a named process exceeds a CPU or memory usage threshold value, an event can occur. This can be useful for monitoring important processes on servers and getting an early warning if processes begin to use excessive amounts of resources.
• Server Connections: If the rate of contacted IP addresses for one computer exceeds a threshold, an event can occur. This can be useful for detecting port scanners and worms.
• Startup Time: An event can occur if the startup time of a computer exceeds a threshold value in seconds.
• User Login Time: An event can occur if the login time of a user on a computer exceeds a threshold value in seconds.

IP Service

All IP services are identified by a server group and port group:

• Availability: An event can occur if a request didn't receive a response.

   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.

• Average RTT: An event can occur if the average round trip time (RTT) within a report interval for a TCP connection exceeds a threshold value in milliseconds.
• Protocol Response Time: An event can occur if the average protocol transaction response time within a report interval exceeds a threshold value in milliseconds.
• Response Time: An event can occur if the average response time within a report interval exceeds a threshold value in milliseconds.
• TCP Retransmissions: An event can occur if the percentage of TCP retransmissions within a report interval exceeds a threshold value.
• Application Online: Created automatically when defining applications in PerformanceGuard. An event is triggered when a computer reports communication with the application.

Ping & Traceroute

You can base events of these types on thresholds for:

• 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.

• Response Time

For more information about the PerformanceGuard ping and traceroute features, see Monitor Availability, Latency and Response Times with Application Ping.

Transaction

You can base events of this type on thresholds for:

• 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.

• Response Time

For more information about transaction measurement, see Monitor Complex Activity with AutoSteps.