Skip to content

Commit aea15c0

Browse files
committed
Added documentation for supporting cluster metrics monitors that can monitor remote clusters. Added documentation for configuring query and bucket monitors through the UI that can query remote indexes. These are experimental for v2.12.
Signed-off-by: AWSHurneyt <[email protected]>
1 parent 0835baa commit aea15c0

File tree

5 files changed

+12
-5
lines changed

5 files changed

+12
-5
lines changed

_observing-your-data/alerting/per-cluster-metrics-monitors.md

Lines changed: 7 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -68,7 +68,8 @@ Painless scripts define triggers for cluster metrics monitors, similar to per qu
6868

6969
The cluster metrics monitor supports up to **ten** triggers.
7070

71-
In the following example, a JSON object creates a trigger that sends an alert when the cluster health is yellow. `script` points the `source` to the Painless script `ctx.results[0].status == \"yellow\`.
71+
In the following example, the monitor is configured to call the cluster health API for two clusters, (`cluster-1`, and `cluster-2`). The trigger condition will create an alert when either of the clusters' `status` is not `green`.
72+
`script` points the `source` to the Painless script `for (cluster in ctx.results[0].keySet()) if (ctx.results[0][cluster].status != \"green\") return true`. See [Trigger variables]({{site.url}}{{site.baseurl}}/observing-your-data/alerting/triggers/#trigger-variables) for more `painless ctx` variable options.
7273

7374
```json
7475
{
@@ -88,7 +89,8 @@ In the following example, a JSON object creates a trigger that sends an alert wh
8889
"api_type": "CLUSTER_HEALTH",
8990
"path": "_cluster/health/",
9091
"path_params": "",
91-
"url": "http://localhost:9200/_cluster/health/"
92+
"url": "http://localhost:9200/_cluster/health/",
93+
"cluster": ["cluster-1", "cluster-2"]
9294
}
9395
}
9496
],
@@ -100,7 +102,7 @@ In the following example, a JSON object creates a trigger that sends an alert wh
100102
"severity": "1",
101103
"condition": {
102104
"script": {
103-
"source": "ctx.results[0].status == \"yellow\"",
105+
"source": "for (cluster in ctx.results[0].keySet()) if (ctx.results[0][cluster].status != \"green\") return true",
104106
"lang": "painless"
105107
}
106108
},
@@ -110,14 +112,14 @@ In the following example, a JSON object creates a trigger that sends an alert wh
110112
]
111113
}
112114
```
115+
The dashboards interface supports selecting clusters to monitor, and the desired API.
113116

114-
See [Trigger variables]({{site.url}}{{site.baseurl}}/observing-your-data/alerting/triggers/#trigger-variables) for more `painless ctx` variable options.
117+
<img src="{{site.url}}{{site.baseurl}}/images/alerting/cross-cluster-cluster-metrics-monitors.png" alt="Cluster metrics monitor" width="700"/>
115118

116119
### Limitations
117120

118121
Per cluster metrics monitors have the following limitations:
119122

120-
- You cannot create monitors for remote clusters.
121123
- The OpenSearch cluster must be in a state where an index's conditions can be monitored and actions can be executed against the index.
122124
- Removing resource permissions from a user will not prevent that user’s preexisting monitors for that resource from executing.
123125
- Users with permissions to create monitors are not blocked from creating monitors for resources for which they do not have permissions; however, those monitors will not run.

_observing-your-data/alerting/per-query-bucket-monitors.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,10 @@ Per query monitors are a type of alert monitor that can be used to identify and
1313

1414
Per bucket monitors are a type of alert monitor that can be used to identify and alert on specific buckets of data that are created by a query against an OpenSearch index.
1515

16+
Both monitor types support querying remote indexes using the same `cluster-name:index-name` pattern used by [cross-cluster search](https://opensearch.org/docs/latest/security/access-control/cross-cluster-search/), or using the new dashboards interface.
17+
18+
<img src="{{site.url}}{{site.baseurl}}/images/alerting/cross-cluster-per-query-per-bucket-monitors.png" alt="Cluster metrics monitor" width="700"/>
19+
1620
## Creating a per query or per bucket monitor
1721

1822
To create a per query monitor, follow these steps:

_observing-your-data/alerting/settings.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -54,6 +54,7 @@ Setting | Default | Description
5454
`plugins.alerting.alert_history_retention_period` | 60d | The amount of time to keep history indexes before automatically deleting them.
5555
`plugins.alerting.destination.allow_list` | ["chime", "slack", "custom_webhook", "email", "test_action"] | The list of allowed destinations. If you don't want to allow users to a certain type of destination, you can remove it from this list, but we recommend leaving this setting as-is.
5656
`plugins.alerting.filter_by_backend_roles` | "false" | Restricts access to monitors by backend role. See [Alerting security]({{site.url}}{{site.baseurl}}/monitoring-plugins/alerting/security/).
57+
`plugins.alerting.remote_monitoring_enabled` | "false" | Toggles whether cluster metrics monitors support executing against remote clusters.
5758
`plugins.scheduled_jobs.sweeper.period` | 5m | The alerting feature uses its "job sweeper" component to periodically check for new or updated jobs. This setting is the rate at which the sweeper checks to see if any jobs (monitors) have changed and need to be rescheduled.
5859
`plugins.scheduled_jobs.sweeper.page_size` | 100 | The page size for the sweeper. You shouldn't need to change this value.
5960
`plugins.scheduled_jobs.sweeper.backoff_millis` | 50ms | The amount of time the sweeper waits between retries---increases exponentially after each failed retry.
Loading
Loading

0 commit comments

Comments
 (0)