diff options
| author | Promise Akpan <akpanpromise@hotmail.com> | 2019-08-15 12:06:39 +0100 |
|---|---|---|
| committer | Chris Akritidis <43294513+cakrit@users.noreply.github.com> | 2019-08-15 13:06:39 +0200 |
| commit | f5006d51e8caf9148d393eb68d53dc9fcd28b7b6 (patch) | |
| tree | 03b757236d6b45e46813a4a875c77dc775e5f896 /health | |
| parent | 69172fd57472df75d877f43de2dcc693c48ab5c0 (diff) | |
Fix Markdown Lint warnings (#6664)
* make remark access all directories
* detailed fix after autofix by remark lint
* cross check autofix for this set of files
* crosscheck more files
* crosschecking and small fixes
* crosscheck autofixed md files
Diffstat (limited to 'health')
21 files changed, 256 insertions, 244 deletions
diff --git a/health/README.md b/health/README.md index a03c7eec7e..848c1bc3ba 100644 --- a/health/README.md +++ b/health/README.md @@ -38,11 +38,11 @@ killall -USR2 netdata There are 2 entities: -1. **alarms**, which are attached to specific charts, and +1. **alarms**, which are attached to specific charts, and -1. **templates**, which define rules that should be applied to all charts having a - specific `context`. You can use this feature to apply **alarms** to all disks, - all network interfaces, all mysql databases, all nginx web servers, etc. +2. **templates**, which define rules that should be applied to all charts having a + specific `context`. You can use this feature to apply **alarms** to all disks, + all network interfaces, all mysql databases, all nginx web servers, etc. Both of these entities have exactly the same format and feature set. The only difference is the label `alarm` or `template`. @@ -168,27 +168,27 @@ lookup: METHOD AFTER [at BEFORE] [every DURATION] [OPTIONS] [of DIMENSIONS] Everything is the same with [badges](../web/api/badges/). In short: -- `METHOD` is one of `average`, `min`, `max`, `sum`, `incremental-sum`. - This is required. +- `METHOD` is one of `average`, `min`, `max`, `sum`, `incremental-sum`. + This is required. -- `AFTER` is a relative number of seconds, but it also accepts a single letter for changing - the units, like `-1s` = 1 second in the past, `-1m` = 1 minute in the past, `-1h` = 1 hour - in the past, `-1d` = 1 day in the past. You need a negative number (i.e. how far in the past - to look for the value). **This is required**. +- `AFTER` is a relative number of seconds, but it also accepts a single letter for changing + the units, like `-1s` = 1 second in the past, `-1m` = 1 minute in the past, `-1h` = 1 hour + in the past, `-1d` = 1 day in the past. You need a negative number (i.e. how far in the past + to look for the value). **This is required**. -- `at BEFORE` is by default 0 and is not required. Using this you can define the end of the - lookup. So data will be evaluated between `AFTER` and `BEFORE`. +- `at BEFORE` is by default 0 and is not required. Using this you can define the end of the + lookup. So data will be evaluated between `AFTER` and `BEFORE`. -- `every DURATION` sets the updated frequency of the lookup (supports single letter units as - above too). +- `every DURATION` sets the updated frequency of the lookup (supports single letter units as + above too). -- `OPTIONS` is a space separated list of `percentage`, `absolute`, `min2max`, `unaligned`, - `match-ids`, `match-names`. Check the badges documentation for more info. +- `OPTIONS` is a space separated list of `percentage`, `absolute`, `min2max`, `unaligned`, + `match-ids`, `match-names`. Check the badges documentation for more info. -- `of DIMENSIONS` is optional and has to be the last parameter. Dimensions have to be separated - by `,` or `|`. The space characters found in dimensions will be kept as-is (a few dimensions - have spaces in their names). This accepts Netdata simple patterns and the `match-ids` and - `match-names` options affect the searches for dimensions. +- `of DIMENSIONS` is optional and has to be the last parameter. Dimensions have to be separated + by `,` or `|`. The space characters found in dimensions will be kept as-is (a few dimensions + have spaces in their names). This accepts Netdata simple patterns and the `match-ids` and + `match-names` options affect the searches for dimensions. The result of the lookup will be available as `$this` and `$NAME` in expressions. The timestamps of the timeframe evaluated by the database lookup is available as variables @@ -259,6 +259,7 @@ Format: warn: EXPRESSION crit: EXPRESSION ``` + Check [Expressions](#expressions) for more information. --- @@ -306,40 +307,41 @@ Format: delay: [[[up U] [down D] multiplier M] max X] ``` -- `up U` defines the delay to be applied to a notification for an alarm that raised its status - (i.e. CLEAR to WARNING, CLEAR to CRITICAL, WARNING to CRITICAL). For example, `up 10s`, the - notification for this event will be sent 10 seconds after the actual event. This is used in - hope the alarm will get back to its previous state within the duration given. The default `U` - is zero. +- `up U` defines the delay to be applied to a notification for an alarm that raised its status + (i.e. CLEAR to WARNING, CLEAR to CRITICAL, WARNING to CRITICAL). For example, `up 10s`, the + notification for this event will be sent 10 seconds after the actual event. This is used in + hope the alarm will get back to its previous state within the duration given. The default `U` + is zero. + +- `down D` defines the delay to be applied to a notification for an alarm that moves to lower + state (i.e. CRITICAL to WARNING, CRITICAL to CLEAR, WARNING to CLEAR). For example, `down 1m` + will delay the notification by 1 minute. This is used to prevent notifications for flapping + alarms. The default `D` is zero. -- `down D` defines the delay to be applied to a notification for an alarm that moves to lower - state (i.e. CRITICAL to WARNING, CRITICAL to CLEAR, WARNING to CLEAR). For example, `down 1m` - will delay the notification by 1 minute. This is used to prevent notifications for flapping - alarms. The default `D` is zero. +- `mutliplier M` multiplies `U` and `D` when an alarm changes state, while a notification is + delayed. The default multiplier is `1.0`. -- `mutliplier M` multiplies `U` and `D` when an alarm changes state, while a notification is - delayed. The default multiplier is `1.0`. +- `max X` defines the maximum absolute notification delay an alarm may get. The default `X` + is `max(U * M, D * M)` (i.e. the max duration of `U` or `D` multiplied once with `M`). -- `max X` defines the maximum absolute notification delay an alarm may get. The default `X` - is `max(U * M, D * M)` (i.e. the max duration of `U` or `D` multiplied once with `M`). + Example: - Example: + `delay: up 10s down 15m multiplier 2 max 1h` - `delay: up 10s down 15m multiplier 2 max 1h` + The time is `00:00:00` and the status of the alarm is CLEAR. - The time is `00:00:00` and the status of the alarm is CLEAR. + | time of event | new status | delay | notification will be sent|why| + |-------------|----------|:---:|-------------------------|---| + | 00:00:01 | WARNING | `up 10s` | 00:00:11|first state switch| + | 00:00:05 | CLEAR | `down 15m x2` | 00:30:05|the alarm changes state while a notification is delayed, so it was multiplied| + | 00:00:06 | WARNING | `up 10s x2 x2` | 00:00:26|multiplied twice| + | 00:00:07 | CLEAR | `down 15m x2 x2 x2` | 00:45:07|multiplied 3 times.| - time of event|new status|delay|notification will be sent|why - -------------|----------|:---:|-------------------------|--- - 00:00:01 | WARNING | `up 10s` | 00:00:11 |first state switch - 00:00:05 | CLEAR | `down 15m x2`| 00:30:05 |the alarm changes state while a notification is delayed, so it was multiplied - 00:00:06 | WARNING | `up 10s x2 x2` | 00:00:26 |multiplied twice - 00:00:07|CLEAR|`down 15m x2 x2 x2`|00:45:07|multiplied 3 times. + So: - So: - - `U` and `D` are multiplied by `M` every time the alarm changes state (any state, not just - their matching one) and a delay is in place. - - All are reset to their defaults when the alarm switches state without a delay in place. + - `U` and `D` are multiplied by `M` every time the alarm changes state (any state, not just + their matching one) and a delay is in place. + - All are reset to their defaults when the alarm switches state without a delay in place. --- @@ -353,9 +355,9 @@ Format: repeat: [off] [warning DURATION] [critical DURATION] ``` -* `off`: Turns off the repeating feature for the current alarm. This is effective when the default repeat settings has been enabled in health configuration. -* `warning DURATION`: Defines the interval when the alarm is in WARNING state. Use `0s` to turn off the repeating notification for WARNING mode. -* `critical DURATION`: Defines the interval when the alarm is in CRITICAL state. Use `0s` to turn off the repeating notification for CRITICAL mode. +- `off`: Turns off the repeating feature for the current alarm. This is effective when the default repeat settings has been enabled in health configuration. +- `warning DURATION`: Defines the interval when the alarm is in WARNING state. Use `0s` to turn off the repeating notification for WARNING mode. +- `critical DURATION`: Defines the interval when the alarm is in CRITICAL state. Use `0s` to turn off the repeating notification for CRITICAL mode. --- @@ -391,9 +393,9 @@ Expressions can have variables. Variables start with `$`. Check below for more i There are two special values you can use: -- `nan`, for example `$this != nan` will check if the variable `this` is available. A variable can be `nan` if the database lookup failed. All calculations (i.e. addition, multiplication, etc) with a `nan` result in a `nan`. +- `nan`, for example `$this != nan` will check if the variable `this` is available. A variable can be `nan` if the database lookup failed. All calculations (i.e. addition, multiplication, etc) with a `nan` result in a `nan`. -- `inf`, for example `$this != inf` will check if `this` is not infinite. A value or variable can be infinite if divided by zero. All calculations (i.e. addition, multiplication, etc) with a `inf` result in a `inf`. +- `inf`, for example `$this != inf` will check if `this` is not infinite. A value or variable can be infinite if divided by zero. All calculations (i.e. addition, multiplication, etc) with a `inf` result in a `inf`. --- @@ -413,25 +415,27 @@ crit: $this > (($status == $CRITICAL) ? (85) : (95)) ``` The above say: -* If the alarm is currently a warning, then the threshold for being considered a warning - is 75, otherwise it's 85. -* If the alarm is currently critical, then the threshold for being considered critical - is 85, otherwise it's 95. +- If the alarm is currently a warning, then the threshold for being considered a warning + is 75, otherwise it's 85. + +- If the alarm is currently critical, then the threshold for being considered critical + is 85, otherwise it's 95. Which in turn, results in the following behavior: -* While the value is rising, it will trigger a warning when it exceeds 85, and a critical - alert when it exceeds 95. -* While the value is falling, it will return to a warning state when it goes below 85, - and a normal state when it goes below 75. +- While the value is rising, it will trigger a warning when it exceeds 85, and a critical + alert when it exceeds 95. -* If the value is constantly varying between 80 and 90, then it will trigger a warning the - first time it goes above 85, but will remain a warning until it goes below 75 (or goes above 85). +- While the value is falling, it will return to a warning state when it goes below 85, + and a normal state when it goes below 75. -* If the value is constantly varying between 90 and 100, then it will trigger a critical alert - the first time it goes above 95, but will remain a critical alert goes below 85 (at which - point it will return to being a warning). +- If the value is constantly varying between 80 and 90, then it will trigger a warning the + first time it goes above 85, but will remain a warning until it goes below 75 (or goes above 85). + +- If the value is constantly varying between 90 and 100, then it will trigger a critical alert + the first time it goes above 95, but will remain a critical alert goes below 85 (at which + point it will return to being a warning). --- @@ -443,21 +447,21 @@ Example: [variables for the `system.cpu` chart of the registry](https://registry _Hint: If you don't know how to find the CHART_NAME, you can read about it [here](../docs/Charts.md#charts)._ - Netdata supports 3 internal indexes for variables that will be used in health monitoring. + <details markdown="1"><summary>The variables below can be used in both chart alarms and context templates.</summary> Although the `alarm_variables` link shows you variables for a particular chart, the same variables can also be used in templates for charts belonging to the same [context](../docs/Charts.md#contexts). The reason is that all charts of a given contexts are essentially identical, with the only difference being the [family](../docs/Charts.md#families) that identifies a particular hardware or software instance. Charts and templates do not apply to specific families anyway, unless if you explicitly limit an alarm with the [alarm line `families`](#alarm-line-families). </details> - - **chart local variables**. All the dimensions of the chart are exposed as local variables. The value of $this for the other configured alarms of the chart also appears, under the name of each configured alarm. +- **chart local variables**. All the dimensions of the chart are exposed as local variables. The value of $this for the other configured alarms of the chart also appears, under the name of each configured alarm. Charts also define a few special variables: - - `$last_collected_t` is the unix timestamp of the last data collection - - `$collected_total_raw` is the sum of all the dimensions (their last collected values) - - `$update_every` is the update frequency of the chart - - `$green` and `$red` the threshold defined in alarms (these are per chart - the charts - inherits them from the the first alarm that defined them) + - `$last_collected_t` is the unix timestamp of the last data collection + - `$collected_total_raw` is the sum of all the dimensions (their last collected values) + - `$update_every` is the update frequency of the chart + - `$green` and `$red` the threshold defined in alarms (these are per chart - the charts + inherits them from the the first alarm that defined them) Chart dimensions define their last calculated (i.e. interpolated) value, exactly as shown on the charts, but also a variable with their name and suffix `_raw` that resolves @@ -465,43 +469,43 @@ Although the `alarm_variables` link shows you variables for a particular chart, that resolves to unix timestamp the dimension was last collected (there may be dimensions that fail to be collected while others continue normally). - - **family variables**. Families are used to group charts together. For example all `eth0` +- **family variables**. Families are used to group charts together. For example all `eth0` charts, have `family = eth0`. This index includes all local variables, but if there are overlapping variables, only the first are exposed. - - **host variables**. All the dimensions of all charts, including all alarms, in fullname. +- **host variables**. All the dimensions of all charts, including all alarms, in fullname. Fullname is `CHART.VARIABLE`, where `CHART` is either the chart id or the chart name (both are supported). - - **special variables*** are: +- **special variables\*** are: - - `$this`, which is resolved to the value of the current alarm. + - `$this`, which is resolved to the value of the current alarm. - - `$status`, which is resolved to the current status of the alarm (the current = the last - status, i.e. before the current database lookup and the evaluation of the `calc` line). - This values can be compared with `$REMOVED`, `$UNINITIALIZED`, `$UNDEFINED`, `$CLEAR`, - `$WARNING`, `$CRITICAL`. These values are incremental, ie. `$status > $CLEAR` works as - expected. + - `$status`, which is resolved to the current status of the alarm (the current = the last + status, i.e. before the current database lookup and the evaluation of the `calc` line). + This values can be compared with `$REMOVED`, `$UNINITIALIZED`, `$UNDEFINED`, `$CLEAR`, + `$WARNING`, `$CRITICAL`. These values are incremental, ie. `$status > $CLEAR` works as + expected. - - `$now`, which is resolved to current unix timestamp. + - `$now`, which is resolved to current unix timestamp. ## Alarm Statuses Alarms can have the following statuses: - - `REMOVED` - the alarm has been deleted (this happens when a SIGUSR2 is sent to Netdata +- `REMOVED` - the alarm has been deleted (this happens when a SIGUSR2 is sent to Netdata to reload health configuration) - - `UNINITIALIZED` - the alarm is not initialized yet +- `UNINITIALIZED` - the alarm is not initialized yet - - `UNDEFINED` - the alarm failed to be calculated (i.e. the database lookup failed, +- `UNDEFINED` - the alarm failed to be calculated (i.e. the database lookup failed, a division by zero occurred, etc) - - `CLEAR` - the alarm is not armed / raised (i.e. is OK) +- `CLEAR` - the alarm is not armed / raised (i.e. is OK) - - `WARNING` - the warning expression resulted in true or non-zero +- `WARNING` - the warning expression resulted in true or non-zero - - `CRITICAL` - the critical expression resulted in true or non-zero +- `CRITICAL` - the critical expression resulted in true or non-zero The external script will be called for all status changes. @@ -545,10 +549,10 @@ The above applies the **template** to all charts that have `context = apache.req calc: $now - $last_collected_t ``` -- `$now` is a standard variable that resolves to the current timestamp. +- `$now` is a standard variable that resolves to the current timestamp. -- `$last_collected_t` is the last data collection timestamp of the chart. - So this calculation gives the number of seconds passed since the last data collection. +- `$last_collected_t` is the last data collection timestamp of the chart. + So this calculation gives the number of seconds passed since the last data collection. ``` every: 10s @@ -563,8 +567,8 @@ The alarm will be evaluated every 10 seconds. If these result in non-zero or true, they trigger the alarm. -- `$this` refers to the value of this alarm (i.e. the result of the `calc` line. - We could also use `$apache_last_collected_secs`. +- `$this` refers to the value of this alarm (i.e. the result of the `calc` line. + We could also use `$apache_last_collected_secs`. `$update_every` is the update frequency of the chart, in seconds. @@ -675,4 +679,4 @@ You can find how Netdata interpreted the expressions by examining the alarm at ` It's currently not possible to schedule notifications from within the alarm template. For those scenarios where you need to temporary disable notifications (for instance when running backups triggers a disk alert) you can disable or silence notifications are runtime. The health checks can be controlled at runtime via the [health management api](../web/api/health/#health-management-api). -[]() +[](<>) diff --git a/health/notifications/README.md b/health/notifications/README.md index 8c7ab66f75..a0065729a3 100644 --- a/health/notifications/README.md +++ b/health/notifications/README.md @@ -7,9 +7,9 @@ You can change the default script globally by editing `/etc/netdata/netdata.conf `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. @@ -23,23 +23,23 @@ Each role may have one or more destinations. 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 slack.com channel `#alarms` and `#systems`. +5. messages to Discord channels `#alarms` and `#systems`. ## Configuration Edit [`/etc/netdata/health_alarm_notify.conf`](health_alarm_notify.conf) by running `/etc/netdata/edit-config health_alarm_notify.conf`: -- 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). -2. **recipients** per **role** per **notification method** +2. **recipients** per **role** per **notification method** ## Testing Notifications @@ -62,8 +62,10 @@ export NETDATA_ALARM_NOTIFY_DEBUG=1 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 - ``` + +```sh +bash -x /usr/libexec/netdata/plugins.d/alarm-notify.sh test +``` + Then look in the output for the alarm-notify.sh calls and run the one you want to trace with `bash -x`. -[]() +[](<>) diff --git a/health/notifications/alerta/README.md b/health/notifications/alerta/README.md index 2826fe7737..a34d2b796c 100644 --- a/health/notifications/alerta/README.md +++ b/health/notifications/alerta/README.md @@ -26,7 +26,9 @@ configurations are out os scope of this tutorial but information about different deployment scenaries can be found in the [docs][3]. [1]: https://hub.docker.com/r/alerta/alerta-web/ + [2]: http://alerta.readthedocs.io/en/latest/gettingstarted/tutorial-1-deploy-alerta.html + [3]: http://docs.alerta.io/en/latest/deployment.html ## Send alarms to Alerta @@ -42,7 +44,9 @@ Step 2. configure Netdata to send alarms to Alerta On your system run: - $ /etc/netdata/edit-config health_alarm_notify.conf +```sh +/etc/netdata/edit-config health_alarm_notify.conf +``` and modify the file as below: @@ -70,13 +74,15 @@ DEFAULT_RECIPIENT_ALERTA="Production" We can test alarms using the standard approach: - $ /opt/netdata/netdata-plugins/plugins.d/alarm-notify.sh test +```sh +/opt/netdata/netdata-plugins/plugins.d/alarm-notify.sh test +``` Note: Netdata will send 3 alarms, and because last alarm is "CLEAR" you will not see them in main Alerta page, you need to select to see "closed" alarma in top-right lookup. A little change in `alarm-notify.sh` that let us test each state one by one will be useful. -For more information see [https://docs.alerta.io](https://docs.alerta.io) +For more information see <https://docs.alerta.io> -[]() +[](<>) diff --git a/health/notifications/awssns/README.md b/health/notifications/awssns/README.md index 7bb3487143..ed838dacb9 100644 --- a/health/notifications/awssns/README.md +++ b/health/notifications/awssns/README.md @@ -2,23 +2,25 @@ As part of it's AWS suite, Amazon provides a notification broker service called 'Simple Notification Service' or SNS. Amazon SNS works kind of similarly to Netdata's own notification system, allowing dispatch of 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. +- Email addresses. +- Mobile Phones via SMS. +- HTTP or HTTPS web hooks. +- AWS Lambda functions. +- AWS SQS queues. +- Mobile applications via push notifications. To get this working, you will need: -* The Amazon Web Services CLI tools. Most distributions provide these with the package name `awscli`. -* An actual home directory for the user you run Netdata as, instead of just using `/` as a home directory. Setup of this is distribution specific. `/var/lib/netdata` is the recommended directory (because the permissions will already be correct) if you are using a dedicated user (which is how most distributions work). -* An Amazon SNS topic to send notifications to with one or more subscribers. The [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.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. If you're really paranoid, you can create one for each system or group of systems. +- The Amazon Web Services CLI tools. Most distributions provide these with the package name `awscli`. +- An actual home directory for the user you run Netdata as, instead of just using `/` as a home directory. Setup of this is distribution specific. `/var/lib/netdata` is the recommended directory (because the permissions will already be correct) if you are using a dedicated user (which is how most distributions work). +- An Amazon SNS topic to send notifications to with one or more subscribers. The [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.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. If you're really paranoid, you can create one for each system or group of systems. Once you have all the above, run the following command as the user Netdata runs under: - aws configure +``` +aws configure +``` THis will prompt you for the access key and secret key for accessing Amazon SNS (as well as the default region and output format, but you can leave those blank because we don't use them). @@ -26,8 +28,8 @@ Once that's done, you're ready to go and can specify the desired topic ARN as a Notes: - * Netdata's native email notification support is far better in almost all respects than it's support through Amazon SNS. If you want email notifications, use the native support, not SNS. - * If you need to change the notification format for SNS notifications, you can do so by specifying the format in `AWSSNS_MESSAGE_FORMAT` in the configuration. This variable supports all the same vairiables you can use in custom notifications. - * While Amazon SNS supports sending differently formatted messages for different delivery methods, Netdata does not currently support this functionality. +- Netdata's native email notification support is far better in almost all respects than it's support through Amazon SNS. If you want email notifications, use the native support, not SNS. + - If you need to change the notification format for SNS notifications, you can do so by specifying the format in `AWSSNS_MESSAGE_FORMAT` in the configuration. This variable supports all the same vairiables you can use in custom notifications. + - While Amazon SNS supports sending differently formatted messages for different delivery methods, Netdata does not currently support this functionality. -[]() +[](<>) diff --git a/health/notifications/custom/README.md b/health/notifications/custom/README.md index 80210572b2..18df795419 100644 --- a/health/notifications/custom/README.md +++ b/health/notifications/custom/README.md @@ -39,45 +39,45 @@ The following is a sample `custom_sender` function in `health_alarm_notify.conf` 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 +- `${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}` |