forked from cloudfoundry/docs-running-cf
-
Notifications
You must be signed in to change notification settings - Fork 0
/
hm-notifications.html.md.erb
129 lines (97 loc) · 5.16 KB
/
hm-notifications.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
---
title: Configuring Health Monitor Notifications
owner: Notifications
---
This topic describes how to configure notifications from the Health Monitor (HM), which monitors the health of the virtual machines in a Cloud Foundry (CF) deployment.
The HM is a BOSH component that continuously monitors all BOSH-deployed virtual machines (VMs) in a deployment. Each BOSH-deployed VM produces a heartbeat every minute and sends it to the HM, along with status and lifecycle events.
Operators can configure the HM to send an alert through notification plugins by editing the BOSH manifest and redeploying.
##<a id='creds'></a>Step 1: Set Up BOSH Director Credentials
To enable HM notifications, you must provide the HM with credentials to access the BOSH Director. Perform the procedures below to give the HM the correct credentials.
1. Open your BOSH manifest and locate `hm: director_account` under `properties`:
```
hm:
director_account:
ca_cert: "CA-CERT"
client_id: UAA-CLIENT-ID
client_secret: UAA-CLIENT-SECRET
password: PASSWORD
user: USERNAME
```
1. To enable the HM to access the BOSH Director, do one of the following:
* Provide the `user` and `password` for a user that can access the BOSH Director, and remove the other lines under `director_account`.
* Provide a UAA client ID for `client_id`, a UAA client secret for `client_secret`, and a certificate to verify the UAA endpoint for `ca_cert`. Remove the other lines under `director_account`.
##<a id='config'></a>Step 2: Configure Notifications
Perform the procedures below to set the logging level of the HM and to configure how you receive notifications.
1. Locate the `loglevel` property in your BOSH manifest.
```
hm:
loglevel: info
```
This property sets the logging level of the HM. You can set `loglevel` to `fatal`, `error`, `warn`, `info`, or `debug`.
1. You can enable notifications by e-mail, PagerDuty, AWS CloudWatch, DataDog, OpenTSDB, and Graphite. Follow the instructions below for the appropriate plugin.
###<a id='email'></a> Configure Email
<%= vars.email_notifications %>
Replace the placeholders with the values appropriate for your deployment.
```
hm:
email_notifications: true
email_recipients: [email protected], [email protected]
smtp:
from: SENDER-ADDRESS
host: SENDER-SMTP-HOST
port: SENDER-SMTP-PORT
domain: SENDER-SMTP-DOMAIN
tls: TRUE-OR-FALSE
auth: SMTP-AUTH-TYPE
user: SMTP-USER
password: SMTP-PASSWORD
```
* `email_notifications`: Set to `true`.
* `email_recipients`: Provide a comma-delimited list of recipient addresses.
* `smtp.from`: Provide the email address of the sender of the notifications. For example, `[email protected]`.
* `smtp.host`: Provide the address of the SMTP server. For example, `smtp.example.com`.
* `smtp.port`: Provide the port of the SMTP server. For example, `25`, `465`, or `587`.
* `smtp.domain`: Provide the SMTP EHLO domain. This is typically the server's FQDN, such as `cloudfoundry.example.com`.
* `tls`: Set `tls` to `true` to enable automatic STARTTLS.
* `auth`: Provide the SMTP authentication type. Only `plain` is supported.
* `user`: If you set `auth` to `plain`, provide the username for SMTP authentication.
* `password`: If you set `auth` to `plain`, provide the password for SMTP authentication.
To customize the contents of your notification email, see the [Getting Started with the Notifications Service](../adminguide/notifications.html) topic.
###<a id='pagerduty'></a> Configure PagerDuty
Replace the placeholders with the values appropriate for your deployment.
```
hm:
pagerduty_enabled: true
pagerduty:
service_key: YOUR-PAGERDUTY-SERVICE-KEY
http_proxy: YOUR-HTTP-PROXY
```
* `pagerduty_enabled`: Set to `true`.
* `pagerduty.service_key`: Provide the PagerDuty service API key. For more information about how to generate an API key, see the PagerDuty [documentation](https://v2.developer.pagerduty.com/docs/events-api).
* `pagerduty.http_proxy`: Optionally, provide a HTTP proxy to connect to PagerDuty.
###<a id='cloudwatch'></a> Configure AWS CloudWatch
Replace the placeholders with the values appropriate for your deployment.
```
hm:
cloud_watch_enabled: true
aws:
access_key_id: YOUR-AWS-ACCESS-KEY-ID
secret_access_key: YOUR-SECRET-AWS-ACCESS-KEY
```
* `cloud_watch_enabled`: Set to `true`.
* `aws.access_key_id`: Provide the access key ID for your Amazon Web Services (AWS) account. For more information about Amazon CloudWatch, see the [CloudWatch documentation](https://aws.amazon.com/documentation/cloudwatch/).
* `aws.secret_access_key`: Provide the secret access key for your AWS account.
###<a id='datadog'></a> Configure DataDog
Replace the placeholders with the values appropriate for your deployment.
```
hm:
datadog_enabled: true
datadog:
api_key:
application_key:
pagerduty_service_name:
```
* `datadog_enabled`: Set to `true`.
* `datadog.api_key`: Provide the API key for DataDog. For more information about DataDog, see the [DataDog documentation](http://docs.datadoghq.com/api/).
* `datadog.application_key`: Provide the HM application key for DataDog.
* `datadog.pagerduty_service_name`: Provide the service name to alert in PagerDuty on HM events.