Alert Rules are probably the most important part of this system and to you. Alert Rules link Alert Integrations and Monitors allowing you to be notified when a Monitor is not in your preferred state.
You can configure Alert Rules to link multiple alerting methods (Alert integrations) to multiple monitors of a single type. For example you are able to link an API Monitor to Slack which means when the API Monitor is in a undesired state it will send a slack message letting you know.
ICMP
ICMP will always alert when it is down or unreachable. It has a configurable alert score which defines the number of iterations before it alerts. A simple calculation defines this alerting rule:alertscore * 5 seconds = seconds before alerting
Example of alert score 3:3 * 5 seconds = 15 seconds
You would want to consider setting this grater than 1 because the internet is naturally unstable and this may get fired a lot when your service is actually fine but the ICMP route was not.
Recommendation: > 2
We would recommend that you set this above 2. In our testing this has been our most reliable setting. In experience the alert score of 2 has let us know when a "network blip" has happened and when a service has been down fully.
TCP
TCP monitors the state of the port but is categorised into two states for alerting:
1. Open
2. Closed or Filtered/Rejected
You are able to configure Alert Rules for TCP with an alert score and port state. If both conditions are met alerts will be triggered for the Alert Rule.
The configured Port State in an Alert Score is respected as this is the state I would like to alert on. For example:
If I monitor an IP address on port 22, it is currently returning open. I configure an Alert Rule to trigger when Alert Score = 2 & Port State is Closed or Filtered/Rejected it will alert me when that port enters the Closed state and on the second iteration of checking that state.
Please read about ICMP above to understand Alert Scores.
Recommendation: Alert Score: > 2, Port State: as desired
We would recommend that you set this above 2 for the same reasons defined above in ICMP. The Port State is up to you it depends if you expect a port to be open or closed.
SSL
When monitoring an SSL Certificate we check the validity of an SSL Cert and notify you when the certificate is going to expire or has expired.
Every SSL Certificate is checked every 30 seconds to ensure we capture state changes as soon as possible. When configured an Alert Rule for SSL will alert the user 1 month, 2 weeks, 1 week, 3 days, 2 days, 1 day before expiry and on the day of expiry.
DNS
DNS Domain Alert Rules are designed to check the valid states of a DNS Record. It will check the live DNS Records from different providers and notify the user if this record is not in the expected state. As an example of this:
We want to make sure that db.example.com is set to 192.168.0.4 publicly. When this alert rule is configured for this domain it will check that what we're seeing from the different providers is consistent with db.example.com=192.168.0.4. In the event that db.example.com returns 192.168.0.5 an alert would fire informing you this has changed and what it's changed to.
API
API monitoring uses the HTTP Response Codes to determine if that state of the system. This is configured on the creation of an API / HTTP(S) check. Alert Rules then validate that the returned HTTP Response Code from executing that request is the same as the configured HTTP code in the system.
An good example is checking that https://google.com is still available. Running this command will give you the status of website:
- Windows: Invoke-WebRequest -URI http://www.google.com | findstr StatusCode
- Linux/MAC: curl -I http://www.example.org | grep HTTP
This would output something like:HTTP/1.1 200 OK or StatusCode : 200
This would then be used to compare does Returned Code = Expected Code for all locations and if not then an alert will be created.
