| title | seoTitle | description | date | weight |
|---|---|---|---|---|
E-mail Integration |
iLert: E-mail Integration for Alerting | Incident Response | Uptime |
This page describes how to integrate iLert with any tool that can send emails. |
2018-12-29T05:02:05.000Z |
1 |
Email integration is the easiest way to integrate iLert with your monitoring system. Each email alert source in iLert has its own email address (e.g. [email protected]). As soon as your monitoring system sends an e-mail to this address, iLert will create an incident.
- Go to Alert sources and click on Add a new alert source
- Enter a name and select an escalation policy
- Chose Email as integation type
- Enter an email address for the alert source
- Save the email alert source
Your email alert source is now active. Any email sent to the email address will create an incident in iLert and trigger the alerting process using the alert source's escalation policy. The default setting creates an incident in iLert for each incoming email. The next section explains advanced settings, such as deduplicating or filtering emails.
By default, iLert creates a new incident for every email sent to the alert source's email address. You can fine-tune this behavior by
- adding email filter, which lets you filter emails based on defined conditions
- modifying incident creation options
Email filters allow you to ignore emails based on the content of the email's subject, body, or from address.
| Option | Description |
|---|---|
| Open a new incident for every email | Each email sent to the alert source's email address will create a new incident. |
| Open a new incident for every new email subject |
Incidents are de-duplicated based on the subject of the emails. Case sensivitiy
and whitespaces are ignored. Deduplication considers only the emails of
open incidents.
If, for example, a monitoring system sends two e-mails in succession with the same subject, a new incident is created for the first e-mail and the second e-mail is appended to the created incident in the event log. |
Open a new incident only if all incidents in this alert source are in RESOLVED or ACCEPTED OR RESOLVEDstate |
An email sent to the alert source's email address will only open
a new incident if an open incident does not already exist; otherwise, the
email will be appended to the last open incident.
Example: You get alerted at 3 A.M. in the morning and accept the incident and decide to look at the problem the next morning. In the meantime, if a new (potentially critical) issue is reported to iLert, a new incident will be notified again. In this scenario, you need to chose ACCEPTED ir RESOLVED in
the dropdown list. |
| Open and resolve incidents based incident keys extracted from emails | Use defined rules to link emails to the same incident based on matching substrings in the email subject or body. See Automatically resolve Incidents with Emails |
{% page-ref page="automatically-resolve-incidents-with-emails.md" %}
Does iLert also process e-mails that are sent by forwarding to an alert source address?
Yes, iLert evaluates the TO , CC and BCC fields as well as the DELIVERED-TO header when processing email.
My monitoring system sends emails when an issue is recovered (e.g. RECOVERY emails in Nagios). Can iLert use these emails to resolve previously created incidents?
Yes, see Automatically resolve Incidents with Emails for further information
I need more examples that illustrate regex incident key extraction from emails, where can I find them?
Take a look here