Overview
Setup Alerts
Actions
Events
This feature allows users to configure the system to alert them when various metrics breach a defined threshold for a specified period of time.
Most of the alerts are evaluated in real-time on the probes themselves. For example, if there is a delay alert configured that triggers when delay exceeds 500msec for 5 minutes, this is evaluated separately on each probe the alert is configured for. As soon as the alert is triggered on the probe, an event is raised and sent to the cloud. There is no delay in waiting for results to be posted to the cloud and analysed.
Setup Alerts
- Under Settings > Alerts, select Add New Alert
In the above alert, we wanted to notify our Tech Support team (see Actions on how to set that up) each time inbound bandwidth exceeded 5mbps after 5 minutes
Each Field Explained
| Field | Definition |
| Name | The name you want to set for your alert which is easy for you to identify i.e. High bandwidth outbound throughput |
| Definition | The condition that you want to set for your alert (refer to table below for the list of conditions that can be set and their definitions) followed by an operator i.e. >, <, =, etc. as well as a threshold which is dependent on the metric you select i.e. delay uses msec, bandwidth uses mb, etc. |
| Duration | Duration of condition to run until you want it to alert i.e. have the bandwidth exceed 2mbps for 5 minutes until it alerts |
| Filter Type | This can either be set for all probes to utilize this alert or specific probes. By default, this is set to All Probes |
| Action | The action that you would like to occur once the conditions have been met i.e. E-mail Technical Support |
The available metrics that make up a condition are as follows:
| Condition | Definition |
| Quality: delay | The round trip delay (in msec) between spoke probes and the hub probe in the network. |
| Quality: jitter | The jitter (in msec) between spoke probes and the hub probe in the network. |
| Quality: loss | The loss (in %) between spoke probes and the hub probe in the network. |
| Quality: availability | The time (in %) the link between spoke probes and the hub probe in the network is available. |
| Quality: capacity (in) | The inbound capacity (in kbps) between spoke probes and the hub probe in the network. |
| Quality: capacity (out) | The outbound capacity (in kbps) between spoke probes and the hub probe in the network. |
| Quality: capacity (in+out) | The sum of inbound and outbound capacity (in Mbps) between spoke probes and the hub probe in the network. |
| Visibility: data transfer (in) | The total inbound data transfer (in MB) of a probe. |
| Visibility: data transfer (out) | The total outbound data transfer (in MB) of a probe. |
| Visibility: data transfer (in+out) | The total (inbound plus outbound) data transfer (in MB) of an probe. |
| Visibility: throughput (in) | The total inbound throughput (in Mbps) of a probe. |
| Visibility: throughput (out) | The total outbound throughput (in Mbps) of a probe. |
| Visibility: throughput (in+out) | The total (inbound plus outbound) throughput (in Mbps) of a probe. |
| Visibility: Experience Score | The experience score is inspired by Apdex and is a measure of user experience between 0 (poor) and 100 (excellent). Crowd sourced information is used to determine what “normal” is for each application. This information is used to calculate an experience score using the Apdex formula. Low scores mean users are waiting longer for the application. High scores indicate fast application response times. |
| Visibility: Response Time | Response time tracks how long each transaction took to complete, measured from the first packet of the request to the last packet of the response. Since it’s measured for each transaction, the value will be application-dependant. |
| Visibility: Network Delay | The portion of the response time (above) that can be attributed to the network. |
| Visibility: Server Delay | The portion of the response time (above) that can be attributed to the server. |
| Visibility: Retransmitted Packets | Retransmitted packets is a count of the number of packets that need to be retransmitted. Packets generally have to be retransmitted when they are lost or dropped in the network between the client and the server. |
| Visibility: Repeated Retransmissions | Repeated retransmitted is a count of the number of occurrences 3 or more consecutive packets needed to be retransmitted. Occasional, sporadic packet retransmissions may not cause serious application performance problems, however, when these retransmissions occur on a sequence of packets, the performance impact is far greater. |
| Visibility: Out of Order Packets | Out of Order packets occur when packets arrive in a different order from which they were sent. Out-of-order packets are caused when packets follow multiple paths through a network or via parallel processing paths within network equipment. |
| Visibility: Zero Window Packets | Zero Window Packets occur when a client or server advertises a zero value for its window size. This indicates that the TCP receive buffer is full and it cannot receive any more data resulting in a stalled connection. |
| Visibility: TCP Receive Window | The size (in bytes) of the TCP receive buffer for that has not been processed by the application. The size of the TCP Receive Window is advertised using the window size value field in the TCP header. |
| System: probe offline | Triggers when a probe goes offline. |
2. When you are finished, select Apply and the new alert will be saved.
Actions
- Go into Settings > Actions and select Add Action
In the above example, we wanted to setup an action that would e-mail the support team in any alert we assign this action to
Each Field Explained
| Field | Definition |
| Name | The name of your custom action that you're creating i.e. E-mail support team |
| Action Type | The action you would like to occur once it's been set up on an alert, currently it can be either be send an e-mail or use PagerDuty |
| Acknowledgments | This can either disable or enable sending an e-mail when an alert has been acknowledged, by default it's enabled |
| Clear Notifications | This can either disable or enable sending an e-mail when an alert has been cleared, by default it's enabled |
| Consolidate | This can group events that are similar so only a single notification will be sent, by default this is disabled |
| Destination | This is where you can specify what e-mail address you want your alerts sent through to i.e. support_team@company.com |
2. Once you have created your action, select Apply and you will then be able to select this in your custom alerts
Events
Active Events
A list of current, active events can be viewed by navigating to the Events, Active page. While alerts are active, they will be shown here, so this page can be used to display any current network issues. 
Alerts can also be acknowledged, so in a team environment, it is clear who is looking into the various issues. The filter bar at the top of this page can also be used to only show active alerts for individual probes or groups of probes (using tags).
Historical Events
All events in time can be viewed by navigating to the Events, Log page. This shows when each event was raised, cleared and acknowledged (if applicable).
The time selection and filter bar at the top of this page can be used to view only alerts raised by an individual probe or group of probes (using tags), over a certain time period.
See Also
Sinefa Best Practise Guide
How to integrate Sinefa Alerts with PagerDuty
Comments
0 comments
Article is closed for comments.