Browse Source

Update Agent notification methods documentation (#14827)

* update health/notifications/README.md

* Alerta notification method documentation update

* Amazon SNS and some alerta changes

* notification methods imporvements

* alerta refinements

* awssns refinements

* custom alert refinements

* discord refinements

* email notifications documentation update

* flock notifications documentation update

* alerta edits

* awssns edits

* custom notification method edits

* discord edits

* email notification method edits

* flock edits

* IRC notifications update

* Kavenegar notifications documentation update

* matrix notifications documentation update

* messagebird notifications documentation update

* msteams notifications documentation update

* wording change

* twilio notifications documentation update

* telegram notifications documentation update

* syslog notifications update

* smstools3 notifications documentation update

* rocket.chat notifications documentation update

* pushover notifications documentation update

* pushbullet notifications documentation update

* prowl notifications documentation update

* pagerduty notifications documentation update

* remove comments from example configuration

* slight wording changes

* more notification methods documentation updates

* slack notification documentation update

* add config options to the notifications Introduction page

* crop image twilio

* crop image slack

* crop image pushover

* crop images pushbullet

* crop image messagebird

* crop image kavenegar
Fotis Voutsas 1 year ago
parent
commit
83b6939877

+ 163 - 47
health/notifications/README.md

@@ -1,71 +1,107 @@
-<!--
-title: "Agent alert notifications"
-description: "Reference documentation for Netdata's alarm notification feature, which supports dozens of endpoints, user roles, and more."
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/health/notifications/README.md"
-sidebar_label: "Agent alert notifications"
-learn_status: "Published"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
--->
-
 # Agent alert notifications
 
-The `exec` line in health configuration defines an external script that will be called once
-the alert is triggered. The default script is `alarm-notify.sh`.
+This is a reference documentation for Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
+
+The `script to execute on alarm` line in `netdata.conf` defines the external script that will be called once the alert is triggered.
+
+The default script is `alarm-notify.sh`.
 
-You can change the default script globally by editing `/etc/netdata/netdata.conf`.
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> - Please also note that after most configuration changes you will need to [restart the Agent](https://github.com/netdata/netdata/blob/master/docs/configure/start-stop-restart.md) for the changes to take effect.
+>
+> It is recommended to use this way for configuring Netdata.
+
+You can change the default script globally by editing `netdata.conf` and changing the `script to execute on alarm` in the `[health]` section.
 
 `alarm-notify.sh` is capable of sending notifications:
 
--   to multiple recipients
--   using multiple notification methods
--   filtering severity per recipient
+- to multiple recipients
+- using multiple notification methods
+- filtering severity per recipient
 
 It uses **roles**. For example `sysadmin`, `webmaster`, `dba`, etc.
 
-Each alert is assigned to one or more roles, using the `to` line of the alert configuration. Then `alarm-notify.sh` uses
-its own configuration file `/etc/netdata/health_alarm_notify.conf`. To edit it on your system, run
-`/etc/netdata/edit-config health_alarm_notify.conf` and find the destination address of the notification for each
-method.
+Each alert is assigned to one or more roles, using the `to` line of the alert  configuration. For example, here is the alert configuration for `ram.conf` that defaults to the role `sysadmin`:
+
+```conf
+    alarm: ram_in_use
+       on: system.ram
+    class: Utilization
+     type: System
+component: Memory
+       os: linux
+    hosts: *
+     calc: $used * 100 / ($used + $cached + $free + $buffers)
+    units: %
+    every: 10s
+     warn: $this > (($status >= $WARNING)  ? (80) : (90))
+     crit: $this > (($status == $CRITICAL) ? (90) : (98))
+    delay: down 15m multiplier 1.5 max 1h
+     info: system memory utilization
+       to: sysadmin
+```
+
+Then `alarm-notify.sh` uses its own configuration file `health_alarm_notify.conf`, which at the bottom of the file stores the recipients per role, for all notification methods.
+
+Here is an example, of the `sysadmin`'s role recipients for the email notification.  
+You can send the notification to multiple recipients by separating the emails with a space.
+
+```conf
+
+###############################################################################
+# RECIPIENTS PER ROLE
 
-Each role may have one or more destinations.
+# -----------------------------------------------------------------------------
+# generic system alarms
+# CPU, disks, network interfaces, entropy, etc
+
+role_recipients_email[sysadmin]="someone@exaple.com someoneelse@example.com"
+```
+
+Each role may have one or more destinations and one or more notification methods.
 
 So, for example the `sysadmin` role may send:
 
-1.  emails to admin1@example.com and admin2@example.com
-2.  pushover.net notifications to USERTOKENS `A`, `B` and `C`.
-3.  pushbullet.com push notifications to admin1@example.com and admin2@example.com
-4.  messages to slack.com channel `#alarms` and `#systems`.
-5.  messages to Discord channels `#alarms` and `#systems`.
+1. emails to admin1@example.com and admin2@example.com
+2. pushover.net notifications to USERTOKENS `A`, `B` and `C`.
+3. pushbullet.com push notifications to admin1@example.com and admin2@example.com
+4. messages to the `#alerts` and `#systems` channels of a Slack workspace.
+5. messages to Discord channels `#alerts` and `#systems`.
 
 ## Configuration
 
-Edit `/etc/netdata/health_alarm_notify.conf` by running `/etc/netdata/edit-config health_alarm_notify.conf`:
+You can edit `health_alarm_notify.conf` using the `edit-config` script to configure:
 
--   settings per notification method:
+- **Settings** per notification method:
 
-     all notification methods except email, require some configuration
-     (i.e. API keys, tokens, destination rooms, channels, etc).
+     All notification methods except email, require some configuration (i.e. API keys, tokens, destination rooms, channels, etc). Please check this section's content to find the configuration guides for your notification option of choice
 
--  **recipients** per **role** per **notification method**
+- **Recipients** per role per notification method
 
-```sh
-grep sysadmin /etc/netdata/health_alarm_notify.conf
-
-role_recipients_email[sysadmin]="${DEFAULT_RECIPIENT_EMAIL}"
-role_recipients_pushover[sysadmin]="${DEFAULT_RECIPIENT_PUSHOVER}"
-role_recipients_pushbullet[sysadmin]="${DEFAULT_RECIPIENT_PUSHBULLET}"
-role_recipients_telegram[sysadmin]="${DEFAULT_RECIPIENT_TELEGRAM}"
-role_recipients_slack[sysadmin]="${DEFAULT_RECIPIENT_SLACK}"
-...
-```
+     ```conf
+     role_recipients_email[sysadmin]="${DEFAULT_RECIPIENT_EMAIL}"
+     role_recipients_pushover[sysadmin]="${DEFAULT_RECIPIENT_PUSHOVER}"
+     role_recipients_pushbullet[sysadmin]="${DEFAULT_RECIPIENT_PUSHBULLET}"
+     role_recipients_telegram[sysadmin]="${DEFAULT_RECIPIENT_TELEGRAM}"
+     role_recipients_slack[sysadmin]="${DEFAULT_RECIPIENT_SLACK}"
+     ...
+     ```
+
+     Here you can change the `${DEFAULT_...}` values to the values of the recipients you want, separated by a space if you have multiple recipients.
 
-## Testing Notifications
+## Testing Alert Notifications
 
 You can run the following command by hand, to test alerts configuration:
 
 ```sh
 # become user netdata
-su -s /bin/bash netdata
+sudo su -s /bin/bash netdata
 
 # enable debugging info on the console
 export NETDATA_ALARM_NOTIFY_DEBUG=1
@@ -79,13 +115,93 @@ export NETDATA_ALARM_NOTIFY_DEBUG=1
 
 If you are [running your own registry](https://github.com/netdata/netdata/blob/master/registry/README.md#run-your-own-registry), add `export NETDATA_REGISTRY_URL=[YOUR_URL]` before calling `alarm-notify.sh`.
 
-Note that in versions before 1.16, the plugins.d directory may be installed in a different location in certain OSs (e.g. under `/usr/lib/netdata`). You can always find the location of the `alarm-notify.sh` script in `netdata.conf`.
+> If you need to dig even deeper, you can trace the execution with `bash -x`. Note that in test mode, `alarm-notify.sh` calls itself with many more arguments. So first do:
+>
+>```sh
+>bash -x /usr/libexec/netdata/plugins.d/alarm-notify.sh test
+>```
+>
+> And then look in the output for the alarm-notify.sh calls and run the one you want to trace with `bash -x`.
+
+## Global configuration options
+
+### Notification Filtering
+
+When you define recipients per role for notification methods, you can append `|critical` to limit the notifications that are sent.
+
+In the following examples, the first recipient receives all the alarms, while the second one receives only notifications for alarms that have at some point become critical.
+The second user may still receive warning and clear notifications, but only for the event that previously caused a critical alarm.
+
+```conf
+ email      : "user1@example.com user2@example.com|critical"
+ pushover   : "2987343...9437837 8756278...2362736|critical"
+ telegram   : "111827421 112746832|critical"
+ slack      : "alarms disasters|critical"
+ alerta     : "alarms disasters|critical"
+ flock      : "alarms disasters|critical"
+ discord    : "alarms disasters|critical"
+ twilio     : "+15555555555 +17777777777|critical"
+ messagebird: "+15555555555 +17777777777|critical"
+ kavenegar  : "09155555555 09177777777|critical"
+ pd         : "<pd_service_key_1> <pd_service_key_2>|critical"
+ irc        : "<irc_channel_1> <irc_channel_2>|critical"
+```
 
-If you need to dig even deeper, you can trace the execution with `bash -x`. Note that in test mode, `alarm-notify.sh` calls itself with many more arguments. So first do
+If a per role recipient is set to an empty string, the default recipient of the given
+notification method (email, pushover, telegram, slack, alerta, etc) will be used.
 
-```sh
-bash -x /usr/libexec/netdata/plugins.d/alarm-notify.sh test
+To disable a notification, use the recipient called: disabled
+This works for all notification methods (including the default recipients).
+
+### Proxy configuration
+
+If you need to send curl based notifications (pushover, pushbullet, slack, alerta,
+flock, discord, telegram) via a proxy, you should set these variables to your proxy address:
+
+```conf
+export http_proxy="http://10.0.0.1:3128/"
+export https_proxy="http://10.0.0.1:3128/"
+```
+
+### Notification images
+
+Images in notifications need to be downloaded from an Internet facing site.
+
+To allow notification providers to fetch the icons/images, by default we set the URL of the global public netdata registry.
+
+If you have an Internet facing netdata (or you have copied the images/ folder
+of netdata to your web server), set its URL here, to fetch the notification
+images from it.
+
+```conf
+images_base_url="http://my.public.netdata.server:19999"
 ```
 
- Then look in the output for the alarm-notify.sh calls and run the one you want to trace with `bash -x`. 
+### Date handling
+
+You can configure netdata alerts to send dates in any format you want via editing the `date_format` variable.
+
+This uses standard `date` command format strings. See `man date` for
+more info on what formats are supported.
+
+Note that this has to start with a '+', otherwise it won't work.
+
+- For ISO 8601 dates, use `+%FT%T%z`
+- For RFC 5322 dates, use `+%a, %d %b %Y %H:%M:%S %z`
+- For RFC 3339 dates, use `+%F %T%:z`
+- For RFC 1123 dates, use `+%a, %d %b %Y %H:%M:%S %Z`
+- For RFC 1036 dates, use `+%A, %d-%b-%y %H:%M:%S %Z`
+- For a reasonably local date and time (in that order), use `+%x %X`
+- For the old default behavior (compatible with ANSI C's `asctime()` function), leave the `date_format` field empty.
+
+### Hostname handling
+
+By default, Netdata will use the simple hostname for the system (the hostname with everything after the first `.` removed) when displaying the hostname in alert notifications.
+
+If you instead prefer to have Netdata use the host's fully qualified domain name, you can set `use_fdqn` to `YES`.
+
+This setting does not account for child systems for which the system you are configuring is a parent.
 
+> ### Note
+>
+> If the system's host name is overridden in `/etc/netdata.conf` with the `hostname` option, that name will be used unconditionally.

+ 54 - 64
health/notifications/alerta/README.md

@@ -1,86 +1,76 @@
-<!--
-title: "Alerta agent alert notifications"
-sidebar_label: "Alerta"
-description: "Send alarm notifications to Alerta to see the latest health status updates from multiple nodes in a single interface."
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/health/notifications/alerta/README.md"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
-learn_autogeneration_metadata: "{'part_of_cloud': False, 'part_of_agent': True}"
--->
+# Alerta Agent alert notifications
 
-# Alerta agent alert notifications
+Learn how to send notifications to Alerta using Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
 
-The [Alerta](https://alerta.io) monitoring system is a tool used to
-consolidate and de-duplicate alerts from multiple sources for quick
-‘at-a-glance’ visualisation. With just one system you can monitor
-alerts from many other monitoring tools on a single screen.
+> ### Note
+>
+> This file assumes you have read the [Introduction to Agent alert notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md), detailing how the Netdata Agent's alert notification method works.
 
-![Alerta dashboard](https://docs.alerta.io/_images/alerta-screen-shot-3.png "Alerta dashboard showing several alerts.")
+The [Alerta](https://alerta.io) monitoring system is a tool used to consolidate and de-duplicate alerts from multiple sources for quick ‘at-a-glance’ visualization.
+With just one system you can monitor alerts from many other monitoring tools on a single screen.
 
-Alerta's advantage is the main view, where you can see all active alarms with the most recent state. You can also view an alert history. You can send Netdata alerts to Alerta to see alerts coming from many Netdata hosts or also from a multi-host
-Netdata configuration. 
+![Alerta dashboard showing several alerts](https://docs.alerta.io/_images/alerta-screen-shot-3.png)
 
-## Deploying Alerta
+Alerta's advantage is the main view, where you can see all active alert with the most recent state.
+You can also view an alert history.
 
-The recommended setup is using a dedicated server, VM or container. If you have other NGINX or Apache servers in your organization,
-it is recommended to proxy to this new server.
+You can send Netdata alerts to Alerta to see alerts coming from many Netdata hosts or also from a multi-host Netdata configuration.
 
-You can install Alerta in several ways:
-- **Docker**: Alerta provides a [Docker image](https://hub.docker.com/r/alerta/alerta-web/) to get you started quickly.
-- **Deployment on Ubuntu server**: Alerta's [getting started tutorial](https://docs.alerta.io/gettingstarted/tutorial-1-deploy-alerta.html) walks you through this process. 
-- **Advanced deployment scenarios**: More ways to install and deploy Alerta are documented on the [Alerta docs](http://docs.alerta.io/en/latest/deployment.html).
+## Prerequisites
 
-## Sending alerts to Alerta
+You need:
 
-### Step 1. Create an API key (if authentication in Alerta is enabled)
+- an Alerta instance
+- an Alerta API key (if authentication in Alerta is enabled)
+- terminal access to the Agent you wish to configure
 
-You will need an API key to send messages from any source, if
-Alerta is configured to use authentication (recommended). 
+## Configure Netdata to send alert notifications to Alerta
 
-Create a new API key in Alerta: 
-1. Go to *Configuration* > *API Keys* 
-2. Create a new API key called "netdata" with `write:alerts` permission.
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> It is recommended to use this way for configuring Netdata.
 
-### Step 2. Configure Netdata to send alerts to Alerta
-1. Edit the `health_alarm_notify.conf` by running:
-```sh
-/etc/netdata/edit-config health_alarm_notify.conf
-```
+Edit `health_alarm_notify.conf`, changes to this file do not require restarting Netdata:
 
-2. Modify the file as below:
-```
-# enable/disable sending alerta notifications
-SEND_ALERTA="YES"
+1. Set `SEND_ALERTA` to `YES`.
+2. set `ALERTA_WEBHOOK_URL` to the API url you defined when you installed the Alerta server.
+3. Set `ALERTA_API_KEY` to your API key.  
+   You will need an API key to send messages from any source, if Alerta is configured to use authentication (recommended). To create a new API key:  
+   1. Go to *Configuration* > *API Keys*.
+   2. Create a new API key called "netdata" with `write:alerts` permission.
+4. Set `DEFAULT_RECIPIENT_ALERTA` to the default recipient environment you want the alert notifications to be sent to.  
+   All roles will default to this variable if left unconfigured.
 
-# here set your alerta server API url
-# this is the API url you defined when installed Alerta server, 
-# it is the same for all users. Do not include last slash.
-ALERTA_WEBHOOK_URL="http://yourserver/alerta/api"
+You can then have different recipient environments per **role**, by editing `DEFAULT_RECIPIENT_CUSTOM` with the environment name you want, in the following entries at the bottom of the same file:
 
-# Login with an administrative user to you Alerta server and create an API KEY
-# with write permissions.
-ALERTA_API_KEY="INSERT_YOUR_API_KEY_HERE"
-
-# you can define environments in /etc/alertad.conf option ALLOWED_ENVIRONMENTS
-# standard environments are Production and Development
-# if a role's recipients are not configured, a notification will be send to
-# this Environment (empty = do not send a notification for unconfigured roles):
-DEFAULT_RECIPIENT_ALERTA="Production"
+```conf
+role_recipients_alerta[sysadmin]="Systems"
+role_recipients_alerta[domainadmin]="Domains"
+role_recipients_alerta[dba]="Databases Systems"
+role_recipients_alerta[webmaster]="Marketing Development"
+role_recipients_alerta[proxyadmin]="Proxy"
+role_recipients_alerta[sitemgr]="Sites"
 ```
 
-## Test alarms
+The values you provide should be defined as environments in `/etc/alertad.conf` option `ALLOWED_ENVIRONMENTS`.
 
-We can test alarms using the standard approach:
+An example working configuration would be:
 
-```sh
-/opt/netdata/netdata-plugins/plugins.d/alarm-notify.sh test
-```
-
-> **Note** This script will send 3 alarms. 
-> Alerta will not show the alerts in the main page, because last alarm is "CLEAR".
-> To see the test alarms, you need to select "closed" alarms in the top-right lookup. 
+```conf
+#------------------------------------------------------------------------------
+# alerta (alerta.io) global notification options
 
-For more information see the [Alerta documentation](https://docs.alerta.io)
+SEND_ALERTA="YES"
+ALERTA_WEBHOOK_URL="http://yourserver/alerta/api"
+ALERTA_API_KEY="INSERT_YOUR_API_KEY_HERE"
+DEFAULT_RECIPIENT_ALERTA="Production"
+```
 
+## Test the notification method
 
+To test this alert notification method refer to the ["Testing Alert Notifications"](https://github.com/netdata/netdata/blob/master/health/notifications/README.md#testing-alert-notifications) section of the Agent alert notifications page.

+ 117 - 48
health/notifications/awssns/README.md

@@ -1,31 +1,29 @@
-<!--
-title: "Amazon SNS agent alert notifications"
-sidebar_label: "Amazon SNS"
-description: "hello"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/health/notifications/awssns/README.md"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
-learn_autogeneration_metadata: "{'part_of_cloud': False, 'part_of_agent': True}"
--->
-
-# Amazon SNS agent alert notifications
-
-As part of its AWS suite, Amazon provides a notification broker service called 'Simple Notification Service' (SNS). Amazon SNS works similarly to Netdata's own notification system, allowing to dispatch a single notification to multiple subscribers of different types. While Amazon SNS supports sending differently formatted messages for different delivery methods, Netdata does not currently support this functionality.
-Among other things, SNS supports sending notifications to:
-
--   Email addresses.
--   Mobile Phones via SMS.
--   HTTP or HTTPS web hooks.
--   AWS Lambda functions.
--   AWS SQS queues.
--   Mobile applications via push notifications.
-
-For email notification support, we recommend using Netdata's email notifications, as it is has the following benefits:
+# Amazon SNS Agent alert notifications
+
+Learn how to send notifications through Amazon SNS using Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
+
+> ### Note
+>
+> This file assumes you have read the [Introduction to Agent alert notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md), detailing how the Netdata Agent's alert notification method works.
+
+As part of its AWS suite, Amazon provides a notification broker service called 'Simple Notification Service' (SNS). Amazon SNS works similarly to Netdata's own notification system, allowing to dispatch a single notification to multiple subscribers of different types. Among other things, SNS supports sending notifications to:
+
+- email addresses
+- mobile Phones via SMS
+- HTTP or HTTPS web hooks
+- AWS Lambda functions
+- AWS SQS queues
+- mobile applications via push notifications
+
+> ### Note
+>
+> While Amazon SNS supports sending differently formatted messages for different delivery methods, Netdata does not currently support this functionality.
+
+For email notification support, we recommend using Netdata's [email notifications](https://github.com/netdata/netdata/blob/master/health/notifications/email/README.md), as it is has the following benefits:
 
 - In most cases, it requires less configuration.
 - Netdata's emails are nicely pre-formatted and support features like threading, which requires a lot of manual effort in SNS.
-- It is less resource intensive and more cost-efficient than SNS. 
+- It is less resource intensive and more cost-efficient than SNS.
 
 Read on to learn how to set up Amazon SNS in Netdata.
 
@@ -33,26 +31,97 @@ Read on to learn how to set up Amazon SNS in Netdata.
 
 Before you can enable SNS, you need:
 
--   The [Amazon Web Services CLI tools](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) (`awscli`).
--   An actual home directory for the user you run Netdata as, instead of just using `/` as a home directory. The setup depends on the distribution, but `/var/lib/netdata` is the recommended directory. If you are using Netdata as a dedicated user, the permissions will already be correct.
--   An Amazon SNS topic to send notifications to with one or more subscribers. The [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) section of the Amazon SNS documentation covers the basics of how to set this up. Make note of the **Topic ARN** when you create the topic.
--   While not mandatory, it is highly recommended to create a dedicated IAM user on your account for Netdata to send notifications. This user needs to have programmatic access, and should only allow access to SNS. For an additional layer of security, you can create one for each system or group of systems.
-
-## Enabling Amazon SNS
-
-To enable SNS:
-1. Run the following command as the user Netdata runs under:
-   ```
-   aws configure
-   ```
-2. Enter the access key and secret key for accessing Amazon SNS. The system also prompts you to enter the default region and output format, but you can leave those blank because Netdata doesn't use them.
-
-3. Specify the desired topic ARN as a recipient, see [SNS documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html#set-up-sns-topic-cli).
-4. Optional: To change the notification format for SNS notifications, change the `AWSSNS_MESSAGE_FORMAT` variable in `health_alarm_notify.conf`. 
-This variable supports all the same variables you can use in custom notifications.
-
-   The default format looks like this: 
-   ```bash
-   AWSSNS_MESSAGE_FORMAT="${status} on ${host} at ${date}: ${chart} ${value_string}"
-   ```
-   
+- The [Amazon Web Services CLI tools](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) (`awscli`).
+- An actual home directory for the user you run Netdata as, instead of just using `/` as a home directory.  
+  The setup depends on the distribution, but `/var/lib/netdata` is the recommended directory. If you are using Netdata as a dedicated user, the permissions will already be correct.
+- An Amazon SNS topic to send notifications to with one or more subscribers.  
+  The [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) section of the Amazon SNS documentation covers the basics of how to set this up. Make note of the **Topic ARN** when you create the topic.
+- While not mandatory, it is highly recommended to create a dedicated IAM user on your account for Netdata to send notifications.  
+  This user needs to have programmatic access, and should only allow access to SNS. For an additional layer of security, you can create one for each system or group of systems.
+- Terminal access to the Agent you wish to configure.
+
+## Configure Netdata to send alert notifications to Amazon SNS
+
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> It is recommended to use this way for configuring Netdata.
+
+Edit `health_alarm_notify.conf`, changes to this file do not require restarting Netdata:
+
+1. Set `SEND_AWSNS` to `YES`.
+2. Set `AWSSNS_MESSAGE_FORMAT` to the string that you want the alert to be sent into.
+
+   The supported variables are:
+
+   | Variable name               | Description                                                                      |
+   |:---------------------------:|:---------------------------------------------------------------------------------|
+   | `${alarm}`                  | Like "name = value units"                                                        |
+   | `${status_message}`         | Like "needs attention", "recovered", "is critical"                               |
+   | `${severity}`               | Like "Escalated to CRITICAL", "Recovered from WARNING"                           |
+   | `${raised_for}`             | Like "(alarm was raised for 10 minutes)"                                         |
+   | `${host}`                   | The host generated this event                                                    |
+   | `${url_host}`               | Same as ${host} but URL encoded                                                  |
+   | `${unique_id}`              | The unique id of this event                                                      |
+   | `${alarm_id}`               | The unique id of the alarm that generated this event                             |
+   | `${event_id}`               | The incremental id of the event, for this alarm id                               |
+   | `${when}`                   | The timestamp this event occurred                                                |
+   | `${name}`                   | The name of the alarm, as given in netdata health.d entries                      |
+   | `${url_name}`               | Same as ${name} but URL encoded                                                  |
+   | `${chart}`                  | The name of the chart (type.id)                                                  |
+   | `${url_chart}`              | Same as ${chart} but URL encoded                                                 |
+   | `${family}`                 | The family of the chart                                                          |
+   | `${url_family}`             | Same as ${family} but URL encoded                                                |
+   | `${status}`                 | The current status : REMOVED, UNINITIALIZED, UNDEFINED, CLEAR, WARNING, CRITICAL |
+   | `${old_status}`             | The previous status: REMOVED, UNINITIALIZED, UNDEFINED, CLEAR, WARNING, CRITICAL |
+   | `${value}`                  | The current value of the alarm                                                   |
+   | `${old_value}`              | The previous value of the alarm                                                  |
+   | `${src}`                    | The line number and file the alarm has been configured                           |
+   | `${duration}`               | The duration in seconds of the previous alarm state                              |
+   | `${duration_txt}`           | Same as ${duration} for humans                                                   |
+   | `${non_clear_duration}`     | The total duration in seconds this is/was non-clear                              |
+   | `${non_clear_duration_txt}` | Same as ${non_clear_duration} for humans                                         |
+   | `${units}`                  | The units of the value                                                           |
+   | `${info}`                   | A short description of the alarm                                                 |
+   | `${value_string}`           | Friendly value (with units)                                                      |
+   | `${old_value_string}`       | Friendly old value (with units)                                                  |
+   | `${image}`                  | The URL of an image to represent the status of the alarm                         |
+   | `${color}`                  | A color in  AABBCC format for the alarm                                          |
+   | `${goto_url}`               | The URL the user can click to see the netdata dashboard                          |
+   | `${calc_expression}`        | The expression evaluated to provide the value for the alarm                      |
+   | `${calc_param_values}`      | The value of the variables in the evaluated expression                           |
+   | `${total_warnings}`         | The total number of alarms in WARNING state on the host                          |
+   | `${total_critical}`         | The total number of alarms in CRITICAL state on the host                         |
+
+3. Set `DEFAULT_RECIPIENT_AWSSNS` to the Topic ARN you noted down upon creating the Topic.  
+   All roles will default to this variable if left unconfigured.
+
+You can then have different recipient Topics per **role**, by editing `DEFAULT_RECIPIENT_AWSSNS` with the Topic ARN you want, in the following entries at the bottom of the same file:
+
+```conf
+role_recipients_awssns[sysadmin]="arn:aws:sns:us-east-2:123456789012:Systems"
+role_recipients_awssns[domainadmin]="arn:aws:sns:us-east-2:123456789012:Domains"
+role_recipients_awssns[dba]="arn:aws:sns:us-east-2:123456789012:Databases"
+role_recipients_awssns[webmaster]="arn:aws:sns:us-east-2:123456789012:Development"
+role_recipients_awssns[proxyadmin]="arn:aws:sns:us-east-2:123456789012:Proxy"
+role_recipients_awssns[sitemgr]="arn:aws:sns:us-east-2:123456789012:Sites"
+```
+
+An example working configuration would be:
+
+```conf
+#------------------------------------------------------------------------------
+# Amazon SNS notifications
+
+SEND_AWSSNS="YES"
+AWSSNS_MESSAGE_FORMAT="${status} on ${host} at ${date}: ${chart} ${value_string}"
+DEFAULT_RECIPIENT_AWSSNS="arn:aws:sns:us-east-2:123456789012:MyTopic"
+```
+
+## Test the notification method
+
+To test this alert notification method refer to the ["Testing Alert Notifications"](https://github.com/netdata/netdata/blob/master/health/notifications/README.md#testing-alert-notifications) section of the Agent alert notifications page.

+ 133 - 75
health/notifications/custom/README.md

@@ -1,29 +1,128 @@
-<!--
-title: "Custom agent alert notifications"
-sidebar_label: "Custom endpoint"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/health/notifications/custom/README.md"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
-learn_autogeneration_metadata: "{'part_of_cloud': False, 'part_of_agent': True}"
--->
-
-# Custom agent alert notifications
-
-Netdata allows you to send custom notifications to any endpoint you choose.
-
-To configure custom notifications, you will need to customize `health_alarm_notify.conf`. Open the file for editing
-using [`edit-config`](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) from the [Netdata config
-directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory), which is typically at `/etc/netdata`.
+# Custom Agent alert notifications
+
+Netdata Agent's alert notification feature allows you to send custom notifications to any endpoint you choose.
+
+> ### Note
+>
+> This file assumes you have read the [Introduction to Agent alert notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md), detailing how the Netdata Agent's alert notification method works.
+
+## Prerequisites
+
+You need to have terminal access to the Agent you wish to configure.
+
+## Configure Netdata to send alert notifications to a custom endpoint
+
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> It is recommended to use this way for configuring Netdata.
+
+Edit `health_alarm_notify.conf`, changes to this file do not require restarting Netdata:
+
+1. Set `SEND_CUSTOM` to `YES`.
+2. The `DEFAULT_RECIPIENT_CUSTOM`'s value is dependent on how you handle the `${to}` variable inside the `custom_sender()` function.  
+   All roles will default to this variable if left unconfigured.
+3. Edit the `custom_sender()` function.  
+   You can look at the other senders in `/usr/libexec/netdata/plugins.d/alarm-notify.sh` for examples of how to modify the function in this configuration file.
+
+    The following is a sample `custom_sender()` function in `health_alarm_notify.conf`, to send an SMS via an imaginary HTTPS endpoint to the SMS gateway:
+
+    ```sh
+    custom_sender() {
+        # example human readable SMS
+        local msg="${host} ${status_message}: ${alarm} ${raised_for}"
+
+        # limit it to 160 characters and encode it for use in a URL
+        urlencode "${msg:0:160}" >/dev/null; msg="${REPLY}"
+
+        # a space separated list of the recipients to send alarms to
+        to="${1}"
+
+        for phone in ${to}; do
+          httpcode=$(docurl -X POST \
+                --data-urlencode "From=XXX" \
+                --data-urlencode "To=${phone}" \
+                --data-urlencode "Body=${msg}" \
+                -u "${accountsid}:${accounttoken}" \
+            https://domain.website.com/)
+
+          if [ "${httpcode}" = "200" ]; then
+            info "sent custom notification ${msg} to ${phone}"
+            sent=$((sent + 1))
+          else
+            error "failed to send custom notification ${msg} to ${phone} with HTTP error code ${httpcode}."
+          fi
+        done
+    }
+    ```
+
+    The supported variables that you can use for the function's `msg` variable are:
+
+    | Variable name               | Description                                                                      |
+    |:---------------------------:|:---------------------------------------------------------------------------------|
+    | `${alarm}`                  | Like "name = value units"                                                        |
+    | `${status_message}`         | Like "needs attention", "recovered", "is critical"                               |
+    | `${severity}`               | Like "Escalated to CRITICAL", "Recovered from WARNING"                           |
+    | `${raised_for}`             | Like "(alarm was raised for 10 minutes)"                                         |
+    | `${host}`                   | The host generated this event                                                    |
+    | `${url_host}`               | Same as ${host} but URL encoded                                                  |
+    | `${unique_id}`              | The unique id of this event                                                      |
+    | `${alarm_id}`               | The unique id of the alarm that generated this event                             |
+    | `${event_id}`               | The incremental id of the event, for this alarm id                               |
+    | `${when}`                   | The timestamp this event occurred                                                |
+    | `${name}`                   | The name of the alarm, as given in netdata health.d entries                      |
+    | `${url_name}`               | Same as ${name} but URL encoded                                                  |
+    | `${chart}`                  | The name of the chart (type.id)                                                  |
+    | `${url_chart}`              | Same as ${chart} but URL encoded                                                 |
+    | `${family}`                 | The family of the chart                                                          |
+    | `${url_family}`             | Same as ${family} but URL encoded                                                |
+    | `${status}`                 | The current status : REMOVED, UNINITIALIZED, UNDEFINED, CLEAR, WARNING, CRITICAL |
+    | `${old_status}`             | The previous status: REMOVED, UNINITIALIZED, UNDEFINED, CLEAR, WARNING, CRITICAL |
+    | `${value}`                  | The current value of the alarm                                                   |
+    | `${old_value}`              | The previous value of the alarm                                                  |
+    | `${src}`                    | The line number and file the alarm has been configured                           |
+    | `${duration}`               | The duration in seconds of the previous alarm state                              |
+    | `${duration_txt}`           | Same as ${duration} for humans                                                   |
+    | `${non_clear_duration}`     | The total duration in seconds this is/was non-clear                              |
+    | `${non_clear_duration_txt}` | Same as ${non_clear_duration} for humans                                         |
+    | `${units}`                  | The units of the value                                                           |
+    | `${info}`                   | A short description of the alarm                                                 |
+    | `${value_string}`           | Friendly value (with units)                                                      |
+    | `${old_value_string}`       | Friendly old value (with units)                                                  |
+    | `${image}`                  | The URL of an image to represent the status of the alarm                         |
+    | `${color}`                  | A color in  AABBCC format for the alarm                                          |
+    | `${goto_url}`               | The URL the user can click to see the netdata dashboard                          |
+    | `${calc_expression}`        | The expression evaluated to provide the value for the alarm                      |
+    | `${calc_param_values}`      | The value of the variables in the evaluated expression                           |
+    | `${total_warnings}`         | The total number of alarms in WARNING state on the host                          |
+    | `${total_critical}`         | The total number of alarms in CRITICAL state on the host                         |
+
+You can then have different `${to}` variables per **role**, by editing `DEFAULT_RECIPIENT_CUSTOM` with the variable you want, in the following entries at the bottom of the same file:
+
+```conf
+role_recipients_custom[sysadmin]="systems"
+role_recipients_custom[domainadmin]="domains"
+role_recipients_custom[dba]="databases systems"
+role_recipients_custom[webmaster]="marketing development"
+role_recipients_custom[proxyadmin]="proxy-admin"
+role_recipients_custom[sitemgr]="sites"
+```
 
-You can look at the other senders in `/usr/libexec/netdata/plugins.d/alarm-notify.sh` for examples of how to modify the `custom_sender()` function in `health_alarm_notify.conf`.
+An example working configuration would be:
 
-As with other notifications, you will also need to define the recipient list in `DEFAULT_RECIPIENT_CUSTOM` and/or the `role_recipients_custom` array.
+```conf
+#------------------------------------------------------------------------------
+# custom notifications
 
-The following is a sample `custom_sender` function in `health_alarm_notify.conf`, to send an SMS via an imaginary HTTPS endpoint to the SMS gateway:
+SEND_CUSTOM="YES"
+DEFAULT_RECIPIENT_CUSTOM=""
 
-```
- custom_sender() {
+# The custom_sender() is a custom function to do whatever you need to do
+custom_sender() {
     # example human readable SMS
     local msg="${host} ${status_message}: ${alarm} ${raised_for}"
 
@@ -35,63 +134,22 @@ The following is a sample `custom_sender` function in `health_alarm_notify.conf`
 
     for phone in ${to}; do
       httpcode=$(docurl -X POST \
-				    --data-urlencode "From=XXX" \
-				    --data-urlencode "To=${phone}" \
-				    --data-urlencode "Body=${msg}" \
-				    -u "${accountsid}:${accounttoken}" \
+            --data-urlencode "From=XXX" \
+            --data-urlencode "To=${phone}" \
+            --data-urlencode "Body=${msg}" \
+            -u "${accountsid}:${accounttoken}" \
         https://domain.website.com/)
 
-       if [ "${httpcode}" = "200" ]; then
-         info "sent custom notification ${msg} to ${phone}"
-         sent=$((sent + 1))
-       else
-         error "failed to send custom notification ${msg} to ${phone} with HTTP error code ${httpcode}."
-       fi
+      if [ "${httpcode}" = "200" ]; then
+        info "sent custom notification ${msg} to ${phone}"
+        sent=$((sent + 1))
+      else
+        error "failed to send custom notification ${msg} to ${phone} with HTTP error code ${httpcode}."
+      fi
     done
 }
 ```
 
-Variables available to the custom_sender:
-
--   `${to_custom}`          the list of recipients for the alarm
--   `${host}`               the host generated this event
--   `${url_host}`           same as `${host}` but URL encoded
--   `${unique_id}`          the unique id of this event
--   `${alarm_id}`           the unique id of the alarm that generated this event
--   `${event_id}`           the incremental id of the event, for this alarm id
--   `${when}`               the timestamp this event occurred
--   `${name}`               the name of the alarm, as given in Netdata health.d entries
--   `${url_name}`           same as `${name}` but URL encoded
--   `${chart}`              the name of the chart (type.id)
--   `${url_chart}`          same as `${chart}` but URL encoded
--   `${family}`             the family of the chart
--   `${url_family}`         same as `${family}` but URL encoded
--   `${status}`             the current status : REMOVED, UNINITIALIZED, UNDEFINED, CLEAR, WARNING, CRITICAL
--   `${old_status}`         the previous status: REMOVED, UNINITIALIZED, UNDEFINED, CLEAR, WARNING, CRITICAL
--   `${value}`              the current value of the alarm
--   `${old_value}`          the previous value of the alarm
--   `${src}`                the line number and file the alarm has been configured
--   `${duration}`           the duration in seconds of the previous alarm state
--   `${duration_txt}`       same as `${duration}` for humans
--   `${non_clear_duration}` the total duration in seconds this is/was non-clear
--   `${non_clear_duration_txt}` same as `${non_clear_duration}` for humans
--   `${units}`              the units of the value
--   `${info}`               a short description of the alarm
--   `${value_string}`       friendly value (with units)
--   `${old_value_string}`   friendly old value (with units)
--   `${image}`              the URL of an image to represent the status of the alarm
--   `${color}`              a color in #AABBCC format for the alarm
--   `${goto_url}`           the URL the user can click to see the Netdata dashboard
--   `${calc_expression}`    the expression evaluated to provide the value for the alarm
--   `${calc_param_values}`  the value of the variables in the evaluated expression
--   `${total_warnings}`     the total number of alarms in WARNING state on the host
--   `${total_critical}`     the total number of alarms in CRITICAL state on the host
-
-The following are more human friendly:
-
--   `${alarm}`              like "name = value units"
--   `${status_message}`     like "needs attention", "recovered", "is critical"
--   `${severity}`           like "Escalated to CRITICAL", "Recovered from WARNING"
--   `${raised_for}`         like "(alarm was raised for 10 minutes)"
-
+## Test the notification method
 
+To test this alert notification method refer to the ["Testing Alert Notifications"](https://github.com/netdata/netdata/blob/master/health/notifications/README.md#testing-alert-notifications) section of the Agent alert notifications page.

+ 52 - 34
health/notifications/discord/README.md

@@ -1,53 +1,71 @@
-<!--
-title: "Discord agent alert notifications"
-sidebar_label: "Discord"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/health/notifications/discord/README.md"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
-learn_autogeneration_metadata: "{'part_of_cloud': False, 'part_of_agent': True}"
--->
-
-# Discord agent alert notifications
+# Discord Agent alert notifications
+
+Learn how to send notifications to Discord using Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
+
+> ### Note
+>
+> This file assumes you have read the [Introduction to Agent alert notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md), detailing how the Netdata Agent's alert notification method works.
 
 This is what you will get:
 
 ![image](https://cloud.githubusercontent.com/assets/7321975/22215935/b49ede7e-e162-11e6-98d0-ae8541e6b92e.png)
 
-You need:
+## Prerequisites
 
-1.  The **incoming webhook URL** as given by Discord. Create a webhook by following the official [Discord documentation](https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks). You can use the same on all your Netdata servers (or you can have multiple if you like - your decision).
-2.  One or more Discord channels to post the messages to.
+You will need:
 
-Set them in `/etc/netdata/health_alarm_notify.conf` (to edit it on your system run `/etc/netdata/edit-config health_alarm_notify.conf`), like this:
+- The **incoming webhook URL** as given by Discord.  
+  Create a webhook by following the official [Discord documentation](https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks). You can use the same on all your Netdata servers (or you can have multiple if you like - your decision).
+- one or more Discord channels to post the messages to
+- terminal access to the Agent you wish to configure
 
-```
-###############################################################################
-# sending discord notifications
+## Configure Netdata to send alert notifications to Discord
 
-# note: multiple recipients can be given like this:
-#                  "CHANNEL1 CHANNEL2 ..."
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> It is recommended to use this way for configuring Netdata.
 
-# enable/disable sending discord notifications
-SEND_DISCORD="YES"
+Edit `health_alarm_notify.conf`, changes to this file do not require restarting Netdata:
 
-# Create a webhook by following the official documentation -
-# https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks
-DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/XXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+1. Set `SEND_DISCORD` to `YES`.
+2. Set `DISCORD_WEBHOOK_URL` to your webhook URL.
+3. Set `DEFAULT_RECIPIENT_DISCORD` to the channel you want the alert notifications to be sent to.  
+   You can define multiple channels like this: `alerts systems`.  
+   All roles will default to this variable if left unconfigured.
 
-# if a role's recipients are not configured, a notification will be send to
-# this discord channel (empty = do not send a notification for unconfigured
-# roles):
-DEFAULT_RECIPIENT_DISCORD="alarms"
-```
+   > ### Note
+   >
+   > You don't have to include the hashtag "#" of the channel, just its name.
 
-You can define multiple channels like this: `alarms systems`.
-You can give different channels per **role** using these (at the same file):
+You can then have different channels per **role**, by editing `DEFAULT_RECIPIENT_DISCORD` with the channel you want, in the following entries at the bottom of the same file:
 
-```
+```conf
 role_recipients_discord[sysadmin]="systems"
+role_recipients_discord[domainadmin]="domains"
 role_recipients_discord[dba]="databases systems"
 role_recipients_discord[webmaster]="marketing development"
+role_recipients_discord[proxyadmin]="proxy-admin"
+role_recipients_discord[sitemgr]="sites"
 ```
 
-The keywords `systems`, `databases`, `marketing`, `development` are discord.com channels (they should already exist within your discord server).
+The values you provide should already exist as Discord channels in your server.
+
+An example of a working configuration would be:
+
+```conf
+#------------------------------------------------------------------------------
+# discord (discordapp.com) global notification options
+
+SEND_DISCORD="YES"
+DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/XXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+DEFAULT_RECIPIENT_DISCORD="alerts"
+```
+
+## Test the notification method
+
+To test this alert notification method refer to the ["Testing Alert Notifications"](https://github.com/netdata/netdata/blob/master/health/notifications/README.md#testing-alert-notifications) section of the Agent alert notifications page.

+ 63 - 36
health/notifications/dynatrace/README.md

@@ -1,39 +1,66 @@
-<!--
-title: "Dynatrace agent alert notifications"
-sidebar_label: "Dynatrace Events"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/health/notifications/dynatrace/README.md"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
-learn_autogeneration_metadata: "{'part_of_cloud': False, 'part_of_agent': True}"
--->
-
-# Dynatrace agent alert notifications
+# Dynatrace Agent alert notifications
+
+Learn how to send notifications to Dynatrace using Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
+
+> ### Note
+>
+> This file assumes you have read the [Introduction to Agent alert notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md), detailing how the Netdata Agent's alert notification method works.
 
 Dynatrace allows you to receive notifications using their Events REST API.
 
-See [the Dynatrace documentation](https://www.dynatrace.com/support/help/extend-dynatrace/dynatrace-api/environment-api/events/post-event/) about POSTing an event in the Events API for more details.
-
-
-
-You need:
-
-1.  Dynatrace Server. You can use the same on all your Netdata servers but make sure the server is network visible from your Netdata hosts.
-The Dynatrace server should be with protocol prefixed (`http://` or `https://`). For example: `https://monitor.example.com`
-This is a required parameter.
-2.  API Token. Generate a secure access API token that enables access to your Dynatrace monitoring data via the REST-based API.
-Generate a Dynatrace API authentication token. On your Dynatrace server, go to **Settings** --> **Integration** --> **Dynatrace API** --> **Generate token**.
-See [Dynatrace API - Authentication](https://www.dynatrace.com/support/help/extend-dynatrace/dynatrace-api/basics/dynatrace-api-authentication/) for more details.
-This is a required parameter.
-3.  API Space. This is the URL part of the page you have access in order to generate the API Token. For example, the URL
-    for a generated API token might look like:
-    `https://monitor.illumineit.com/e/2a93fe0e-4cd5-469a-9d0d-1a064235cfce/#settings/integration/apikeys;gf=all` In that
-    case, my space is _2a93fe0e-4cd5-469a-9d0d-1a064235cfce_ This is a required parameter.
-4. Generate a Server Tag. On your Dynatrace Server, go to **Settings** --> **Tags** --> **Manually applied tags** and create the Tag.
-The Netdata alarm is sent as a Dynatrace Event to be correlated with all those hosts tagged with this Tag you have created.
-This is a required parameter.
-5. Specify the Dynatrace event. This can be one of `CUSTOM_INFO`, `CUSTOM_ANNOTATION`, `CUSTOM_CONFIGURATION`, and `CUSTOM_DEPLOYMENT`. 
-The default value is `CUSTOM_INFO`.
-This is a required parameter.
-6. Specify the annotation type. This is the source of the Dynatrace event. Put whatever it fits you, for example, 
-_Netdata Alarm_, which is also the default value.
+See [the Dynatrace documentation](https://www.dynatrace.com/support/help/dynatrace-api/environment-api/events-v2/post-event) about POSTing an event in the Events API for more details.
+
+## Prerequisites
+
+You will need:
+
+- A Dynatrace Server. You can use the same on all your Netdata servers but make sure the server is network visible from your Netdata hosts.
+  The Dynatrace server should be with protocol prefixed (`http://` or `https://`), for example: `https://monitor.example.com`.
+- An API Token. Generate a secure access API token that enables access to your Dynatrace monitoring data via the REST-based API.  
+  See [Dynatrace API - Authentication](https://www.dynatrace.com/support/help/extend-dynatrace/dynatrace-api/basics/dynatrace-api-authentication/) for more details.
+- An API Space. This is the URL part of the page you have access in order to generate the API Token.  
+  For example, the URL for a generated API token might look like: `https://monitor.illumineit.com/e/2a93fe0e-4cd5-469a-9d0d-1a064235cfce/#settings/integration/apikeys;gf=all` In that case, the Space is `2a93fe0e-4cd5-469a-9d0d-1a064235cfce`.
+- A Server Tag. To generate one on your Dynatrace Server, go to **Settings** --> **Tags** --> **Manually applied tags** and create the Tag.
+  The Netdata alarm is sent as a Dynatrace Event to be correlated with all those hosts tagged with this Tag you have created.
+- terminal access to the Agent you wish to configure
+
+## Configure Netdata to send alert notifications to Dynatrace
+
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> It is recommended to use this way for configuring Netdata.
+
+Edit `health_alarm_notify.conf`:
+
+1. Set `SEND_DYNATRACE` to `YES`.
+2. Set `DYNATRACE_SERVER` to the Dynatrace server with the protocol prefix, for example `https://monitor.example.com`.
+3. Set `DYNATRACE_TOKEN` to your Dynatrace API authentication token
+4. Set `DYNATRACE_SPACE` to the API Space, it is the URL part of the page you have access in order to generate the API Token. For example, the URL for a generated API token might look like: `https://monitor.illumineit.com/e/2a93fe0e-4cd5-469a-9d0d-1a064235cfce/#settings/integration/apikeys;gf=all` In that case, the Space is `2a93fe0e-4cd5-469a-9d0d-1a064235cfce`.
+5. Set `DYNATRACE_TAG_VALUE` to your Dynatrace Server Tag.
+6. `DYNATRACE_ANNOTATION_TYPE` can be left to its default value `Netdata Alarm`, but you can change it to better fit  your needs.
+7. Set `DYNATRACE_EVENT` to the Dynatrace `eventType` you want, possible values are:  
+   `AVAILABILITY_EVENT`, `CUSTOM_ALERT`, `CUSTOM_ANNOTATION`, `CUSTOM_CONFIGURATION`, `CUSTOM_DEPLOYMENT`, `CUSTOM_INFO`, `ERROR_EVENT`, `MARKED_FOR_TERMINATION`, `PERFORMANCE_EVENT`, `RESOURCE_CONTENTION_EVENT`. You can read more [here](https://www.dynatrace.com/support/help/dynatrace-api/environment-api/events-v2/post-event#request-body-objects)
+
+An example of a working configuration would be:
+
+```conf
+#------------------------------------------------------------------------------
+# Dynatrace global notification options
+
+SEND_DYNATRACE="YES"
+DYNATRACE_SERVER="https://monitor.example.com"
+DYNATRACE_TOKEN="XXXXXXX"
+DYNATRACE_SPACE="2a93fe0e-4cd5-469a-9d0d-1a064235cfce"
+DYNATRACE_TAG_VALUE="SERVERTAG"
+DYNATRACE_ANNOTATION_TYPE="Netdata Alert"
+DYNATRACE_EVENT="AVAILABILITY_EVENT"
+```
+
+## Test the notification method
+
+To test this alert notification method refer to the ["Testing Alert Notifications"](https://github.com/netdata/netdata/blob/master/health/notifications/README.md#testing-alert-notifications) section of the Agent alert notifications page.

+ 82 - 47
health/notifications/email/README.md

@@ -1,56 +1,83 @@
-<!--
-title: "Email agent alert notifications"
-sidebar_label: "Email"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/health/notifications/email/README.md"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
-learn_autogeneration_metadata: "{'part_of_cloud': True, 'part_of_agent': True}"
--->
+# Email Agent alert notifications
 
-# Email agent alert notifications
+Learn how to send notifications via Email using Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
 
-You need a working `sendmail` command for email alerts to work. Almost all MTAs provide a `sendmail` interface.
+> ### Note
+>
+> This file assumes you have read the [Introduction to Agent alert notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md), detailing how the Netdata Agent's alert notification method works.
 
-Netdata sends all emails as user `netdata`, so make sure your `sendmail` works for local users.
+Email notifications look like this:
 
-If you are using our Docker images, or are running Netdata on a system that does not have a working `sendmail`
-command, see [the section below about using msmtp in place of sendmail](#using-msmtp-instead-of-sendmail).
+<img src="https://user-images.githubusercontent.com/1905463/133216974-a2ca0e4f-787b-4dce-b1b2-9996a8c5f718.png" alt="Email notification screenshot" width="50%"></img>
 
-email notifications look like this:
+## Prerequisites
 
-![image](https://user-images.githubusercontent.com/1905463/133216974-a2ca0e4f-787b-4dce-b1b2-9996a8c5f718.png)
+You will need:
 
-## Configuration
+- A working `sendmail` command for email alerts to work. Almost all MTAs provide a `sendmail` interface.  
+  Netdata sends all emails as user `netdata`, so make sure your `sendmail` works for local users.
 
-To edit `health_alarm_notify.conf` on your system run `/etc/netdata/edit-config health_alarm_notify.conf`.
+   > ### Note
+   >
+   > If you are using our Docker images, or are running Netdata on a system that does not have a working `sendmail` command, see [the section below about using msmtp in place of sendmail](#using-msmtp-instead-of-sendmail).
+- terminal access to the Agent you wish to configure
 
-You can configure recipients in [`/etc/netdata/health_alarm_notify.conf`](https://github.com/netdata/netdata/blob/99d44b7d0c4e006b11318a28ba4a7e7d3f9b3bae/conf.d/health_alarm_notify.conf#L101).
+## Configure Netdata to send alerts via Email
 
-You can also configure per role recipients [in the same file, a few lines below](https://github.com/netdata/netdata/blob/99d44b7d0c4e006b11318a28ba4a7e7d3f9b3bae/conf.d/health_alarm_notify.conf#L313).
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> It is recommended to use this way for configuring Netdata.
 
-Changes to this file do not require a Netdata restart.
+Edit `health_alarm_notify.conf`, changes to this file do not require restarting Netdata:
 
-You can test your configuration by issuing the commands:
+1. You can change `EMAIL_SENDER` to the email address sending the notifications, the default is the system user Netdata runs as, usually being `netdata`.  
+   Supported formats are:
 
-```sh
-# become user netdata
-sudo su -s /bin/bash netdata
+   ```conf
+   EMAIL_SENDER="user@domain"
+   EMAIL_SENDER="User Name <user@domain>"
+   EMAIL_SENDER="'User Name' <user@domain>"
+   EMAIL_SENDER="\"User Name\" <user@domain>"
+   ```
 
-# send a test alarm
-/usr/libexec/netdata/plugins.d/alarm-notify.sh test [ROLE]
+2. Set `SEND_EMAIL` to `YES`.
+3. Set `DEFAULT_RECIPIENT_EMAIL` to the email address you want the email to be sent by default.  
+   You can define multiple email addresses like this: `alarms@example.com systems@example.com`.  
+   All roles will default to this variable if left unconfigured.
+4. There are also other optional configuration entries that can be found in the same section of the file.
+
+You can then have different email addresses per **role**, by editing `DEFAULT_RECIPIENT_EMAIL` with the email address you want, in the following entries at the bottom of the same file:
+
+```conf
+role_recipients_email[sysadmin]="systems@example.com"
+role_recipients_email[domainadmin]="domains@example.com"
+role_recipients_email[dba]="databases@example.com systems@example.com"
+role_recipients_email[webmaster]="marketing@example.com development@example.com"
+role_recipients_email[proxyadmin]="proxy-admin@example.com"
+role_recipients_email[sitemgr]="sites@example.com"
 ```
 
-Where `[ROLE]` is the role you want to test. The default (if you don't give a `[ROLE]`) is `sysadmin`.
+An example of a working configuration would be:
 
-Note that in versions before 1.16, the plugins.d directory may be installed in a different location in certain OSs (e.g. under `/usr/lib/netdata`). 
-You can always find the location of the alarm-notify.sh script in `netdata.conf`.
+```conf
+#------------------------------------------------------------------------------
+# email global notification options
+
+EMAIL_SENDER="example@domain.com"
+SEND_EMAIL="YES"
+DEFAULT_RECIPIENT_EMAIL="recipient@example.com"
+```
 
-## Filtering
+### Filtering
 
 Every notification email (both the plain text and the rich html versions) from the Netdata agent, contain a set of custom email headers that can be used for filtering using an email client. Example:
 
-```
+```conf
 X-Netdata-Severity: warning
 X-Netdata-Alert-Name: inbound_packets_dropped_ratio
 X-Netdata-Chart: net_packets.enp2s0
@@ -60,7 +87,7 @@ X-Netdata-Host: winterland
 X-Netdata-Role: sysadmin
 ```
 
-## Using msmtp instead of sendmail
+### Using msmtp instead of sendmail
 
 [msmtp](https://marlam.de/msmtp/) provides a simple alternative to a full-blown local mail server and `sendmail`
 that will still allow you to send email notifications. It comes pre-installed in our Docker images, and is available
@@ -68,21 +95,29 @@ on most distributions in the system package repositories.
 
 To use msmtp with Netdata for sending email alerts:
 
-1. If it’s not already installed, install msmtp. Most distributions have it in their package repositories with the
-   package name `msmtp`.
+1. If it’s not already installed, install msmtp. Most distributions have it in their package repositories with the package name `msmtp`.
 2. Modify the `sendmail` path in `health_alarm_notify.conf` to point to the location of `msmtp`:
-```
-# The full path to the sendmail command.
-# If empty, the system $PATH will be searched for it.
-# If not found, email notifications will be disabled (silently).
-sendmail="/usr/bin/msmtp"
-```
+
+   ```conf
+   # The full path to the sendmail command.
+   # If empty, the system $PATH will be searched for it.
+   # If not found, email notifications will be disabled (silently).
+   sendmail="/usr/bin/msmtp"
+   ```
+
 3. Login as netdata:
-```sh
-(sudo) su -s /bin/bash netdata
-```
+
+   ```sh
+   (sudo) su -s /bin/bash netdata
+   ```
+
 4. Configure `~/.msmtprc` as shown [in the documentation](https://marlam.de/msmtp/documentation/).
 5. Finally set the appropriate permissions on the `.msmtprc` file :
-```sh
-chmod 600 ~/.msmtprc
-```
+
+   ```sh
+   chmod 600 ~/.msmtprc
+   ```
+
+## Test the notification method
+
+To test this alert notification method refer to the ["Testing Alert Notifications"](https://github.com/netdata/netdata/blob/master/health/notifications/README.md#testing-alert-notifications) section of the Agent alert notifications page.

+ 49 - 25
health/notifications/flock/README.md

@@ -1,42 +1,66 @@
-<!--
-title: "Flock agent alert notifications"
-sidebar_label: "Flock"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/health/notifications/flock/README.md"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
-learn_autogeneration_metadata: "{'part_of_cloud': False, 'part_of_agent': True}"
--->
-
-# Flock agent alert notifications
+# Flock Agent alert notifications
+
+Learn how to send notifications to Flock using Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
+
+> ### Note
+>
+> This file assumes you have read the [Introduction to Agent alert notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md), detailing how the Netdata Agent's alert notification method works.
 
 This is what you will get:
 
 ![Flock](https://i.imgur.com/ok9bRzw.png)
 
-You need:
+## Prerequisites
+
+You will need:
+
+- The **incoming webhook URL** as given by flock.com  
+  You can use the same on all your Netdata servers (or you can have multiple if you like - your decision).  
+    Read more about flock webhooks and how to get one [here](https://admin.flock.com/webhooks).
+- Terminal access to the Agent you wish to configure
+
+## Configure Netdata to send alert notifications to Flock
+
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> It is recommended to use this way for configuring Netdata.
 
-The **incoming webhook URL** as given by flock.com. 
-You can use the same on all your Netdata servers (or you can have multiple if you like - your decision).
+Edit `health_alarm_notify.conf`, changes to this file do not require restarting Netdata:
 
-Get them here: <https://admin.flock.com/webhooks>
+1. Set `SEND_FLOCK` to `YES`.
+2. Set `FLOCK_WEBHOOK_URL` to your webhook URL.
+3. Set `DEFAULT_RECIPIENT_FLOCK` to the Flock channel you want the alert notifications to be sent to.  
+   All roles will default to this variable if left unconfigured.
 
-Set them in `/etc/netdata/health_alarm_notify.conf` (to edit it on your system run `/etc/netdata/edit-config health_alarm_notify.conf`), like this:
+You can then have different channels per **role**, by editing `DEFAULT_RECIPIENT_FLOCK` with the channel you want, in the following entries at the bottom of the same file:
 
+```conf
+role_recipients_flock[sysadmin]="systems"
+role_recipients_flock[domainadmin]="domains"
+role_recipients_flock[dba]="databases systems"
+role_recipients_flock[webmaster]="marketing development"
+role_recipients_flock[proxyadmin]="proxy-admin"
+role_recipients_flock[sitemgr]="sites"
 ```
-###############################################################################
-# sending flock notifications
 
-# enable/disable sending pushover notifications
-SEND_FLOCK="YES"
+The values you provide should already exist as Flock channels.
 
-# Login to flock.com and create an incoming webhook.
-# You need only one for all your Netdata servers.
-# Without it, Netdata cannot send flock notifications.
-FLOCK_WEBHOOK_URL="https://api.flock.com/hooks/sendMessage/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+An example of a working configuration would be:
+
+```conf
+#------------------------------------------------------------------------------
+# flock (flock.com) global notification options
 
-# if a role recipient is not configured, no notification will be sent
+SEND_FLOCK="YES"
+FLOCK_WEBHOOK_URL="https://api.flock.com/hooks/sendMessage/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
 DEFAULT_RECIPIENT_FLOCK="alarms"
 ```
 
+## Test the notification method
 
+To test this alert notification method refer to the ["Testing Alert Notifications"](https://github.com/netdata/netdata/blob/master/health/notifications/README.md#testing-alert-notifications) section of the Agent alert notifications page.

+ 32 - 49
health/notifications/gotify/README.md

@@ -1,66 +1,49 @@
-<!--
-title: "Gotify agent alert notifications"
-description: "Send alerts to your Gotify instance when an alert gets triggered in Netdata."
-sidebar_label: "Gotify"
-custom_edit_url: https://github.com/netdata/netdata/edit/master/health/notifications/gotify/README.md
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
-learn_autogeneration_metadata: "{'part_of_cloud': False, 'part_of_agent': True}"
--->
-
 # Gotify agent alert notifications
 
-[Gotify](https://gotify.net/) is a self-hosted push notification service created for sending and receiving messages in real time.
-
-## Configuring Gotify
+Learn how to send alerts to your Gotify instance using Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
 
-### Prerequisites
+> ### Note
+>
+> This file assumes you have read the [Introduction to Agent alert notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md), detailing how the Netdata Agent's alert notification method works.
 
-To use Gotify as your notification service, you need an application token. 
-You can generate a new token in the Gotify Web UI. 
+[Gotify](https://gotify.net/) is a self-hosted push notification service created for sending and receiving messages in real time.
 
-### Configuration
+This is what you will get:
 
-To set up Gotify in Netdata: 
+<img src="https://user-images.githubusercontent.com/103264516/162509205-1e88e5d9-96b6-4f7f-9426-182776158128.png" alt="Example alarm notifications in Gotify" width="70%">
 
-1. Switch to your [config
-directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md) and edit the file `health_alarm_notify.conf` using the edit config script.
- 
-   ```bash
-   ./edit-config health_alarm_notify.conf
-   ```
+## Prerequisites
 
-2. Change the variable `GOTIFY_APP_TOKEN` to the application token you generated in the Gotify Web UI. Change
-`GOTIFY_APP_URL` to point to your Gotify instance.
+You will need:
 
-   ```conf
-   SEND_GOTIFY="YES"
+- An application token. You can generate a new token in the Gotify Web UI.
+- terminal access to the Agent you wish to configure
 
-   # Application token
-   # Gotify instance url
-   GOTIFY_APP_TOKEN=XXXXXXXXXXXXXXX
-   GOTIFY_APP_URL=https://push.example.de/
-   ```
+## Configure Netdata to send alert notifications to Gotify
 
-   Changes to `health_alarm_notify.conf` do not require a Netdata restart. 
-   
-3. Test your Gotify notifications configuration by running the following commands, replacing `ROLE` with your preferred role:
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> It is recommended to use this way for configuring Netdata.
 
-   ```sh
-   # become user netdata
-   sudo su -s /bin/bash netdata
+Edit `health_alarm_notify.conf`, changes to this file do not require restarting Netdata:
 
-   # send a test alarm
-   /usr/libexec/netdata/plugins.d/alarm-notify.sh test ROLE
-   ```
+1. Set `SET_GOTIFY` to `YES`
+2. Set `GOTIFY_APP_TOKEN` to the app token you generated
+3. `GOTIFY_APP_URL` to point to your Gotify instance, for example `https://push.example.domain/`
 
-   🟢 If everything works, you'll see alarms in Gotify:
+An example of a working configuration would be:
 
-   ![Example alarm notifications in Gotify](https://user-images.githubusercontent.com/103264516/162509205-1e88e5d9-96b6-4f7f-9426-182776158128.png)
+```conf
+SEND_GOTIFY="YES"
+GOTIFY_APP_TOKEN="XXXXXXXXXXXXXXX"
+GOTIFY_APP_URL="https://push.example.domain/"
+```
 
-   🔴 If sending the test notifications fails, check `/var/log/netdata/error.log` to find the relevant error message:
+## Test the notification method
 
-   ```log 
-   2020-09-03 23:07:00: alarm-notify.sh: ERROR: failed to send Gotify notification for: hades test.chart.test_alarm is CRITICAL, with HTTP error code 401.
-   ```
+To test this alert refer to the ["Testing Alert Notifications"](https://github.com/netdata/netdata/blob/master/health/notifications/README.md#testing-alert-notifications) section of the Agent alert notifications page.

+ 66 - 61
health/notifications/irc/README.md

@@ -1,83 +1,88 @@
-<!--
-title: "IRC agent alert notifications"
-sidebar_label: "IRC"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/health/notifications/irc/README.md"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Integrations/Notify/Agent alert notifications"
-learn_autogeneration_metadata: "{'part_of_cloud': False, 'part_of_agent': True}"
--->
-
-# IRC agent alert notifications
+# IRC Agent alert notifications
+
+Learn how to send notifications to IRC using Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
+
+> ### Note
+>
+> This file assumes you have read the [Introduction to Agent alert notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md), detailing how the Netdata Agent's alert notification method works.
 
 This is what you will get:
 
-IRCCloud web client:\
+IRCCloud web client:  
 ![image](https://user-images.githubusercontent.com/31221999/36793487-3735673e-1ca6-11e8-8880-d1d8b6cd3bc0.png)
 
-Irssi terminal client:
+Irssi terminal client:  
 ![image](https://user-images.githubusercontent.com/31221999/36793486-3713ada6-1ca6-11e8-8c12-70d956ad801e.png)
 
-You need:
-
-1.  The `nc` utility. If you do not set the path, Netdata will search for it in your system `$PATH`.
-
-Set the path for `nc` in `/etc/netdata/health_alarm_notify.conf` (to edit it on your system run `/etc/netdata/edit-config health_alarm_notify.conf`), like this:
-
-```
-#------------------------------------------------------------------------------
-# external commands
-#
-# The full path of the nc command.
-# If empty, the system $PATH will be searched for it.
-# If not found, irc notifications will be silently disabled.
-nc="/usr/bin/nc"
+## Prerequisites
+
+You will need:
+
+- The `nc` utility.  
+   You can set the path to it, or Netdata will search for it in your system `$PATH`.
+- terminal access to the Agent you wish to configure
+
+## Configure Netdata to send alert notifications to IRC
+
+> ### Info
+>
+> This file mentions editing configuration files.  
+>
+> - To edit configuration files in a safe way, we provide the [`edit config` script](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) located in your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.  
+> Note that to run the script you need to be inside your Netdata config directory.
+>
+> It is recommended to use this way for configuring Netdata.
+
+Edit `health_alarm_notify.conf`, changes to this file do not require restarting Netdata:
+
+1. Set the path for `nc`, otherwise Netdata will search for it in your system `$PATH`:
+
+    ```conf
+    #------------------------------------------------------------------------------
+    # external commands
+    #
+    # The full path of the nc command.
+    # If empty, the system $PATH will be searched for it.
+    # If not found, irc notifications will be silently disabled.
+    nc="/usr/bin/nc"
+    ```
+
+2. Set `SEND_IRC` to `YES`
+3. Set `DEFAULT_RECIPIENT_IRC` to one or more channels to post the messages to.  
+   You can define multiple channels like this: `#alarms #systems`.  
+   All roles will default to this variable if left unconfigured.
+4. Set `IRC_NETWORK` to the IRC network which your preferred channels belong to.
+5. Set `IRC_PORT` to the IRC port to which a connection will occur.
+6. Set `IRC_NICKNAME` to the IRC nickname which is required to send the notification.  
+   It must not be an already registered name as the connection's `MODE` is defined as a `guest`.
+7. Set `IRC_REALNAME` to the IRC realname which is required in order to make he connection.
+
+You can then have different channels per **role**, by editing `DEFAULT_RECIPIENT_IRC` with the channel you want, in the following entries at the bottom of the same file:
+
+```conf
+role_recipients_irc[sysadmin]="#systems"
+role_recipients_irc[domainadmin]="#domains"
+role_recipients_irc[dba]="#databases #systems"
+role_recipients_irc[webmaster]="#marketing #development"
+role_recipients_irc[proxyadmin]="#proxy-admin"
+role_recipients_irc[sitemgr]="#sites"
 ```
 
-2.  Αn `IRC_NETWORK` to which your preferred channels belong to.   
-3.  One or more channels ( `DEFAULT_RECIPIENT_IRC` ) to post the messages to.   
-4.  An `IRC_NICKNAME` and an `IRC_REALNAME` to identify in IRC.   
+The values you provide should be IRC channels which belong to the specified IRC network.
 
-Set them in `/etc/netdata/health_alarm_notify.conf` (to edit it on your system run `/etc/netdata/edit-config health_alarm_notify.conf`), like this:
+An example of a working configuration would be:
 
-```
+```conf
 #------------------------------------------------------------------------------
 # irc notification options
 #
-# irc notifications require only the nc utility to be installed. 
-
-# multiple recipients can be given like this:
-#              "<irc_channel_1> <irc_channel_2> ..."
-
-# enable/disable sending irc notifications
 SEND_IRC="YES"
-
-# if a role's recipients are not configured, a notification will not be sent.
-# (empty = do not send a notification for unconfigured roles):
 DEFAULT_RECIPIENT_IRC="#system-alarms"
-
-# The irc network to which the recipients belong. It must be the full network.
 IRC_NETWORK="irc.freenode.net"
-
-# The irc nickname which is required to send the notification. It must not be 
-# an already registered name as the connection's MODE is defined as a 'guest'.
 IRC_NICKNAME="netdata-alarm-user"
-
-# The irc realname which is required in order to make the connection and is an
-# extra identifier.
 IRC_REALNAME="netdata-user"
 ```
 
-You can define multiple channels like this: `#system-alarms #networking-alarms`.\
-You can also filter the notifications like this: `#system-alarms|critical`.\
-You can give different channels per **role** using these (at the same file):  
-
-```
-role_recipients_irc[sysadmin]="#user-alarms #networking-alarms #system-alarms"
-role_recipients_irc[dba]="#databases-alarms"
-role_recipients_irc[webmaster]="#networking-alarms"
-```
-
-The keywords `#user-alarms`, `#networking-alarms`, `#system-alarms`, `#databases-alarms` are irc channels which belong to the specified IRC network.
-
+## Test the notification method
 
+To test this alert notification method refer to the ["Testing Alert Notifications"](https://github.com/netdata/netdata/blob/master/health/notifications/README.md#testing-alert-notifications) section of the Agent alert notifications page.

Some files were not shown because too many files changed in this diff