Skip to content

Document Synthetics multispace CCS settings #7571

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
alexandra5000 wants to merge 4 commits into
base: main
Choose a base branch
from
+68 −21
Open

Document Synthetics multispace CCS settings #7571

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
2d3ad0d
document Synthetics multispace settings
alexandra5000 Jul 24, 2026
41c918b
Merge branch 'main' into docs/synthetics-multispace-settings
alexandra5000 Jul 24, 2026
c9b6797
Fix Vale linting issues
alexandra5000 Jul 28, 2026
9cb9a19
Address Florent's review comments
alexandra5000 Jul 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 49 additions & 14 deletions solutions/observability/synthetics/configure-settings.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ applies_to:
products:
- id: cloud-serverless
- id: observability
description: Configure Synthetics settings including alerting rules, private locations, global parameters, data retention, project API keys, and cross-cluster search settings.
---

# Configure Synthetics settings [synthetics-settings]
Expand All @@ -18,19 +19,19 @@ There are several Synthetics settings you can adjust in Observability.

Alerting enables you to detect complex conditions using **rules** across Observability and send a notification using **connectors**.

When you create a new synthetic monitor, new default synthetics rules will be applied. To edit the default rules:
When you create a new synthetic monitor, Synthetics applies default rules to the monitor. To edit the default rules:

1. Click **Alerts** in the top bar.
1. Click **Alerts** in the application menu.
2. Select a rule to open a panel where you can edit the rule’s configuration:

* **Monitor status rule** for receiving notifications for errors and outages.
* **TLS certificate rule** for receiving notifications when one or more of your HTTP or TCP lightweight monitors has a TLS certificate expiring within a specified threshold or when it exceeds an age limit.
* **Monitor status rule** for receiving notifications for errors and outages
* **TLS certificate rule** for receiving notifications when one or more of your HTTP or TCP lightweight monitors has a TLS certificate expiring within a specified threshold or when it exceeds an age limit

However, the automatically created Synthetics internal alert is intentionally preconfigured, and some configuration options can’t be changed. For example, you can’t change how often it checks the rule.

If you need specific alerting behavior, set up a different rule. To view all existing rules or create a new rule:

1. Click **Alerts** in the top bar.
1. Click **Alerts** in the application menu.
2. Click **Manage rules** to go to the *Rules* page.

On the *Rules* page, you can manage the default synthetics rules including snoozing rules, disabling rules, deleting rules, and more.
Expand All @@ -41,7 +42,7 @@ On the *Rules* page, you can manage the default synthetics rules including snooz
:::

::::{note}
You can enable and disable default alerts for individual monitors in a few ways:
You can turn on and turn off default alerts for individual monitors in a few ways:

* In the Synthetics UI when you [create a monitor](/solutions/observability/synthetics/create-monitors-ui.md).
* In the Synthetics UI *after* a monitor is already created, on the **Monitors** page or on the **Edit monitor** page for the monitor.
Expand All @@ -50,9 +51,9 @@ You can enable and disable default alerts for individual monitors in a few ways:
::::

In the **Alerting** tab on the **Monitor** Settings page, you can:
- Enable or disable default rules.
- Add and configure connectors. Check all available connectors in [Action types](/solutions/observability/incident-management/create-an-apm-anomaly-rule.md).
- Set up email alerts, if you are running in Elastic Cloud. An SMTP connector will automatically be configured.
- Turn on or turn off default rules.
- Add and configure connectors. For available connectors, refer to [Action types](/solutions/observability/incident-management/create-an-apm-anomaly-rule.md).
- Set up email alerts, if you are running in Elastic Cloud. An SMTP connector is automatically configured.

:::{image} /solutions/images/observability-synthetics-settings-alerting.png
:alt: Alerting tab on the Synthetics Settings page in {{kib}}
Expand All @@ -63,7 +64,7 @@ In the **Alerting** tab on the **Monitor** Settings page, you can:

{{private-location}}s allow you to run monitors from your own premises.

In the **{{private-location}}s** tab, you can add and manage {{private-location}}s. After you [Set up {{fleet-server}} and {{agent}}](/solutions/observability/synthetics/monitor-resources-on-private-networks.md#synthetics-private-location-fleet-agent) and [Connect to the {{stack}} or your serverless Observability project](/solutions/observability/synthetics/monitor-resources-on-private-networks.md#synthetics-private-location-connect), this is where you will add the {{private-location}} so you can specify it as the location for a monitor created using the Synthetics UI or a Synthetics project.
In the **{{private-location}}s** tab, you can add and manage {{private-location}}s. After you [Set up {{fleet-server}} and {{agent}}](/solutions/observability/synthetics/monitor-resources-on-private-networks.md#synthetics-private-location-fleet-agent) and [Connect to the {{stack}} or your serverless Observability project](/solutions/observability/synthetics/monitor-resources-on-private-networks.md#synthetics-private-location-connect), this is where you add the {{private-location}} so you can specify it as the location for a monitor created using the Synthetics UI or a Synthetics project.

:::{image} /solutions/images/observability-synthetics-settings-private-locations.png
:alt: {{private-location}}s tab on the Synthetics Settings page in {{kib}}
Expand Down Expand Up @@ -113,19 +114,53 @@ In a serverless project, to create a Project API key you must be logged in as a
:::

- The **Elastic managed locations enabled** toggle controls whether your Synthetics monitors are permitted to run from Elastic's globally distributed, cloud-hosted testing infrastructure. If enabled, the key can push monitors to both Elastic-managed and private locations. If disabled, the key is restricted to private locations only.
- The **Spaces** drop-down allows you to select the Kibana Space where your API keys will be available.
- The **Spaces** menu allows you to select the space where your API keys are available.

## Remote clusters [synthetics-settings-remote-clusters]
```{applies_to}
stack: ga 9.5+
Comment thread
alexandra5000 marked this conversation as resolved.
serverless: unavailable
```

In the **Remote clusters** tab, you can configure {{ccs}} ({{ccs-init}}) settings so that Synthetics can include monitor data from remote {{es}} clusters alongside local monitors.

These are deployment-wide settings stored as a single shared configuration. You control which {{kib}} spaces have access to them using the **Spaces** field.

@mgiota mgiota Jul 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
These are deployment-wide settings stored as a single shared configuration. You control which {{kib}} spaces have access to them using the **Spaces** field.
These settings are stored as a single shared configuration — one per deployment, not a separate copy per space. Use the Spaces field to control which {{kib}} spaces it applies to.


### Source settings [synthetics-settings-remote-clusters-source]

Use the **Use all remote clusters** toggle and **Select remote clusters** combo box to control which remote clusters Synthetics queries:

@mgiota mgiota Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of and I suggest we use or:

Use the "Use all remote clusters" toggle or "Select remote clusters" combo box


- Turn on **Use all remote clusters** to include monitor data from all configured remote clusters.
- Turn off **Use all remote clusters** and use the **Select remote clusters** combo box to choose specific clusters. Each cluster is shown with a connected or disconnected status indicator.

To configure remote clusters, go to **{{stack-manage-app}} → Remote Clusters**.
Comment on lines +129 to +136

@florent-leborgne florent-leborgne Jul 27, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These 2 seem to be mutually exclusive and do the same thing: they control which remove clusters to fetch monitors from: turn on "Use all remote clusters", or pick individual clusters from the dropdown. Because the first option disables the second one. So we can simplify here.

@alexandra5000 alexandra5000 Jul 28, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rewrote it and simplified the "Remote clusters" section

@mgiota mgiota Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a small comment here (instead of and I suggest we use or)


### Spaces with access [synthetics-settings-remote-clusters-spaces]

Use the **Spaces** combo box to control which {{kib}} spaces can access these {{ccs-init}} settings. Select one or more specific spaces, or select **All spaces** to make the settings available across your entire deployment. Removing a space makes the settings inaccessible there, meaning that users in that space see default {{ccs-init}} settings instead.

::::{note}
The **Spaces** field shows the current sharing configuration when you open the tab. Clearing the field and saving leaves that configuration unchanged, meaning it does not remove access from existing spaces. To update which spaces have access, select the new spaces explicitly.

@mgiota mgiota Jul 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The **Spaces** field shows the current sharing configuration when you open the tab. Clearing the field and saving leaves that configuration unchanged, meaning it does not remove access from existing spaces. To update which spaces have access, select the new spaces explicitly.
The **Spaces** field shows the current sharing configuration when you open the tab — your current space by default. Clearing the field and saving leaves that configuration unchanged, meaning it does not remove access from existing spaces. To update which spaces have access, select the new spaces explicitly.

::::

::::{note}
<!-- TODO: Confirm which role/privilege grants access to edit these settings. The capability required is `uptime.configureSettings` — clarify which built-in role includes this. -->

@alexandra5000 alexandra5000 Jul 28, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mgiota Could you help with this? Is it available for every user? I'm not sure

@mgiota mgiota Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editing these settings requires the All privilege for the Synthetics and Uptime feature (Stack Management -> Roles -> Kibana privileges -> Observability). It's the same privilege that controls editing all other Synthetics settings. Users with only Read see the form as read-only. It's not available to every user by default.

To edit these settings, you must have the required Synthetics configuration privileges. If the form is read-only, contact your administrator.
::::

<!-- TODO: Confirm the default space scope when these settings are first saved on a new deployment. -->

@alexandra5000 alexandra5000 Jul 28, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mgiota What are the default settings? Maybe it's worth mentioning.

@mgiota mgiota Jul 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cross-cluster search is off by default. So until you configure it, only local monitors appear.

Space scope on first save: the settings are anchored to the space you're currently in when you first save. You can use the Spaces field to extend access to other spaces.

Default space
Image

Space b

Image


## Advanced [synthetics-settings-advanced]
```{applies_to}
serverless: ga
stack: ga 9.4+
serverless: ga
```

In the **Advanced** tab, you can configure advanced settings for your Synthetics deployment.

### Maintenance windows sync interval [synthetics-settings-advanced-sync-interval]
### {{maint-windows-cap}} sync interval [synthetics-settings-advanced-sync-interval]

Private location monitors are periodically synced to apply active maintenance window changes. The **Maintenance windows sync interval** setting controls how frequently this sync occurs.
Private location monitors are periodically synced to apply active maintenance window changes. The **{{maint-windows-cap}} sync interval** setting controls how frequently this sync occurs.

Use the **Sync interval (minutes)** field to set the interval. The default is 5 minutes, and valid values range from 5 to 1440 minutes. When you apply a new interval, an immediate sync is triggered so the change takes effect right away.

Expand Down
26 changes: 19 additions & 7 deletions solutions/observability/synthetics/scale-architect-synthetics-deployment.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,24 +9,36 @@ applies_to:
products:
- id: observability
- id: cloud-serverless
description: Advanced guidance for scaling and designing Elastic Synthetics deployments, including cross-cluster search support, tagging strategies, and custom dashboards.
---

# Scale and architect a Synthetics deployment [synthetics-scale-and-architect]

Use these advanced considerations when using the {{synthetics-app}} for large and complex use cases.
Use these advanced considerations when you use the {{synthetics-app}} for large and complex use cases.

% Stateful only for do not use... section

## Do not use the Synthetics UI with CCS/CCR [synthetics-no-ccs-ccr]
## Do not use the Synthetics UI with {{ccs-init}}/{{ccr-init}} [synthetics-no-ccs-ccr]

@florent-leborgne florent-leborgne Jul 27, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You added another section below but the difference is not made super clear. Maybe it would help to also add a reference to the actual integrated feature in here. Like "Do not use this pattern xxx, but instead use yyy". Or maybe combine these 2 into a single section that makes sense of the overall remote cluster + Synthetics story and recommendations.

@alexandra5000 alexandra5000 Jul 28, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a reference at the bottom of the "Do not use" section pointing 9.5+ users to the native CCS feature. For now I kept them as separate sections since they have different applies_to scopes.

@mgiota mgiota Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the difference is not made super clear. I would even rename the section and have one coherent CCS story, starting with what users can do and finishing with what they shouldn't do.

@mgiota mgiota Jul 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that the built-in CCS integration exists (9.5+), the old "don't use the Synthetics UI with CCS/CCR" guidance is misleading, so I've collapsed the two sections into one. It leads with the supported feature, makes clear the remote view is read-only, and points users to manage monitors on the remote {{kib}} directly.

Suggested change
## Do not use the Synthetics UI with {{ccs-init}}/{{ccr-init}} [synthetics-no-ccs-ccr]
## View monitor data from remote clusters [synthetics-ccs-settings]
{applies_to}`stack: ga 9.5+`
Before 9.5, the Synthetics UI couldn't display data from remote clusters through {{ccs-init}}/{{ccr-init}}, so this setup was discouraged — that's no longer the case. Synthetics now includes a built-in {{ccs}} integration that lets you view monitor data from remote {{es}} clusters alongside your local monitors, directly in the Synthetics UI.
This view is **read-only**: the integration queries each remote cluster's `synthetics-*` data indices at query time, but monitor definitions and settings stay as saved objects on the {{kib}} where they were created (saved objects aren't shared across clusters). To create, edit, or delete those monitors, manage them directly in the Synthetics UI on the remote {{kib}}.
To enable it, go to **{{synthetics-app}} → Settings → Remote clusters**. You can select which remote clusters to query and which {{kib}} spaces the settings apply to. Refer to [Remote clusters](/solutions/observability/synthetics/configure-settings.md#synthetics-settings-remote-clusters) for details.

```{applies_to}
stack: ga
```

In complex environments it’s common to have multiple task-specific {{stack}} deployments with one centralized overview cluster using CCS or CCR to centralize {{kib}} dashboards and apps. **Do not use this pattern with the Synthetics UI**. Instead, configure your synthetic monitors directly on the {{kib}} instance where you want to view and manage them.
In complex environments, it’s common to have multiple task-specific {{stack}} deployments with one centralized overview cluster using {{ccs}} or {{ccr}} to centralize {{kib}} dashboards and apps. **Do not use this pattern with the Synthetics UI**. Instead, configure your synthetic monitors directly on the {{kib}} instance where you want to view and manage them.

You may, however, use Dashboards and the Discover feature with CCS to view `synthetics-*` indices.
You can, however, use the Dashboards and the Discover apps with {{ccs-init}} to view `synthetics-*` indices.

The Synthetics UI does *not* work with CCS/CCR because it would limit the rich user experience that the Synthetics UI provides. Unlike the majority of {{kib}} apps, the Synthetics UI relies heavily on state stored in {{kib}} shared objects in order to provide a rich user experience. Because {{kib}} saved objects cannot be shared via CCS/CCR, the Synthetics UI will not show any user data even if CCS/CCR is configured.
The Synthetics UI does *not* work with {{ccs-init}}/{{ccr-init}} because it would limit the rich user experience that the Synthetics UI provides. Unlike the majority of {{kib}} apps, the Synthetics UI relies heavily on state stored in {{kib}} shared objects in order to provide a rich user experience. Because {{kib}} saved objects cannot be shared using {{ccs-init}}/{{ccr-init}}, the Synthetics UI doesn't show any user data even if you configure {{ccs-init}}/{{ccr-init}}.

@mgiota mgiota Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Synthetics UI does not work with {{ccs-init}}/{{ccr-init}}

This is not true. As of 9.5, you can view monitor data from remote clusters directly in the Synthetics UI using the dedicated Remote clusters feature. It reads remote monitor data over CCS and shows it read-only alongside your local monitors. You cannot manage remote monitors from that view, though. (Implementation in this Epic)

the Synthetics UI doesn't show any user data even if you configure {{ccs-init}}.

This sentence is also not true. With the CCS integration this is now possible. We don't get remote monitors data from a Saved Object, but we get it from the monitor's ping data instead and that's how we populate the UI.


{applies_to}`stack: ga 9.5+` To include monitor data from remote clusters, use the [built-in {{ccs}} integration](#synthetics-ccs-settings) instead.

## Use {{ccs-init}} to include monitor data from remote clusters [synthetics-ccs-settings]
```{applies_to}
stack: ga 9.5+
```

Synthetics supports a dedicated {{ccs}} integration that lets you include monitor data from remote {{es}} clusters alongside your local monitors. Unlike the {{ccs-init}}/{{ccr-init}} federation pattern described in [Do not use the Synthetics UI with {{ccs-init}}/{{ccr-init}}](#synthetics-no-ccs-ccr), this is a native Synthetics feature that works with {{kib}} saved objects and the Synthetics UI.

@mgiota mgiota Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not true. It works because it reads ping data, not saved objects.

Suggested change
Synthetics supports a dedicated {{ccs}} integration that lets you include monitor data from remote {{es}} clusters alongside your local monitors. Unlike the {{ccs-init}}/{{ccr-init}} federation pattern described in [Do not use the Synthetics UI with {{ccs-init}}/{{ccr-init}}](#synthetics-no-ccs-ccr), this is a native Synthetics feature that works with {{kib}} saved objects and the Synthetics UI.
Synthetics supports a dedicated {{ccs}} integration that lets you include monitor data from remote {{es}} clusters alongside your local monitors. This is a native Synthetics feature that reads ping data


To configure this, go to **{{synthetics-app}} → Settings → Remote clusters**. You can select which remote clusters to query and which {{kib}} spaces the settings apply to. Refer to [Remote clusters](/solutions/observability/synthetics/configure-settings.md#synthetics-settings-remote-clusters) for details.

## Synthetics UI does not support autodiscovery for infrastructure or {{k8s}} monitoring [synthetics-no-autodiscovery-for-k8s-infra]

Expand All @@ -41,8 +53,8 @@ For infrastructure or {{k8s}} uptime monitoring, use one of the following approa

## Manage large numbers of Synthetic monitors with tags [synthetics-tagging]

When managing larger numbers of synthetic monitors, use tags to keep them organized. Many of the views in the Synthetics UI are tag-aware and can group data by tag.
When you manage larger numbers of synthetic monitors, use tags to keep them organized. Many of the views in the Synthetics UI are tag-aware and can group data by tag.

## Create custom dashboards [synthetics-custom-dashboards]

If we don't provide a UI for your exact needs, you can use [dashboards](/explore-analyze/dashboards.md) to build custom visualizations. For a complete accounting of fields used by the Synthetics UI, refer to [{{heartbeat}}'s exported fields](beats://reference/heartbeat/exported-fields.md).
If the {{synthetics-app}} doesn't include a UI for your exact needs, you can use [dashboards](/explore-analyze/dashboards.md) to build custom visualizations. For a complete list of fields used by the Synthetics UI, refer to [{{heartbeat}}'s exported fields](beats://reference/heartbeat/exported-fields.md).
Loading