You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Centrally manage {{agent}}s in {{fleet}} [manage-agents-in-fleet]
10
+
# Centrally manage {{agents}} in {{fleet}} [manage-agents-in-fleet]
11
11
12
-
13
-
::::{admonition}
14
12
The {{fleet}} app in {{kib}} supports both {{agent}} infrastructure management and agent policy management. You can use {{fleet}} to:
15
13
16
-
* Manage {{agent}} binaries and specify settings installed on the host that determine whether the {{agent}} is enrolled in {{fleet}}, what version of the agent is running, and which agent policy is used.
17
-
* Manage agent policies that specify agent configuration settings, which integrations are running, whether agent monitoring is turned on, input settings, and so on.
14
+
- Manage {{agent}} binaries and specify settings installed on the host that determine whether the agent is enrolled in {{fleet}}, what version of the agent is running, and which agent policy is used.
15
+
- Manage agent policies that specify agent configuration settings, which integrations are running, whether agent monitoring is turned on, input settings, and more.
18
16
19
17
Advanced users who don’t want to use {{fleet}} for central management can use an external infrastructure management solution and [install {{agent}} in standalone mode](/reference/fleet/install-standalone-elastic-agent.md) instead.
20
18
21
-
::::
22
-
23
-
24
19
::::{important}
25
20
{{fleet}} currently requires a {{kib}} user with `All` privileges on {{fleet}} and {{integrations}}. Since many Integrations assets are shared across spaces, users need the {{kib}} privileges in all spaces. Refer to [Required roles and privileges](/reference/fleet/fleet-roles-privileges.md) to learn how to create a user role with the required privileges to access {{fleet}} and {{integrations}}.
26
-
27
21
::::
28
22
23
+
To learn how to add {{agents}} to {{fleet}}, refer to [Install {{fleet}}-managed {{agents}}](/reference/fleet/install-fleet-managed-elastic-agent.md).
29
24
30
-
To learn how to add {{agent}}s to {{fleet}}, refer to [Install {{fleet}}-managed {{agent}}s](/reference/fleet/install-fleet-managed-elastic-agent.md).
31
-
32
-
To use {{fleet}} go to **Management > {{fleet}}** in {{kib}}. The following table describes the main management actions you can perform in {{fleet}}:
25
+
Find **{{fleet}}** in the {{kib}} navigation menu, or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). The following table describes the main management actions you can perform in {{fleet}}:
33
26
34
27
| Component | Management actions |
35
28
| --- | --- |
36
-
|[{{fleet}} settings](/reference/fleet/fleet-settings.md)| Configure global settings available to all {{agent}}s managed by {{fleet}},including {{fleet-server}} hosts and output settings. |
37
-
|[{{agent}}s](/reference/fleet/manage-agents.md)| Enroll, unenroll, upgrade, add tags, and view {{agent}} status and logs. |
29
+
|[{{fleet}} settings](/reference/fleet/fleet-settings.md)| Configure global settings available to all {{agents}} managed by {{fleet}},including {{fleet-server}} hosts and output settings. |
30
+
|[{{agents}}](/reference/fleet/manage-agents.md)| Enroll, unenroll, upgrade, add tags, and view {{agent}} status and logs. |
38
31
|[Policies](/reference/fleet/agent-policy.md)| Create and edit agent policies and add integrations to them. |
39
32
|[{{fleet}} enrollment tokens](/reference/fleet/fleet-enrollment-tokens.md)| Create and revoke enrollment tokens. |
40
33
|[Uninstall tokens](/solutions/security/configure-elastic-defend/prevent-elastic-agent-uninstallation.md)| ({{elastic-defend}} integration only) Access tokens to allow uninstalling {{agent}} from endpoints with Agent tamper protection enabled. |
41
34
|[Data streams](/reference/fleet/data-streams.md)| View data streams and navigate to dashboards to analyze your data. |
42
35
36
+
## Global {{fleet}} management
43
37
38
+
In {{fleet}} deployments where {{agents}} are installed in diverse locations and where data must be stored in local clusters, operators need a unified view of all agents and a central management interface for tasks like upgrades, policy organization, and metrics collection. {{fleet}} offers features to facilitate this deployment model:
44
39
40
+
-[Remote {{es}} output](/reference/fleet/remote-elasticsearch-output.md): Configure {{agents}} to send data to remote {{es}} clusters while still sending their check-in payloads to the management cluster. This allows {{fleet}} on the management cluster to maintain a global view of all agents while the ingested data is routed to the agents' respective local clusters.
41
+
-[Automatic integrations synchronization](/reference/fleet/automatic-integrations-synchronization.md) {applies_to}`stack: ga 9.1.0`: Install an integration once in the management cluster and use {{fleet}} to synchronize and update the integration across all remote clusters. This enables you to initiate services like [OSquery](integration-docs://reference/osquery-intro.md) from the management cluster, and to collect and display responses from dispersed agents in {{fleet}} on the central management cluster.
45
42
46
-
47
-
48
-
43
+
:::{image} images/manage-agents-global-fleet.png
44
+
:alt: A diagram showing Elastic Agents connected to remote data clusters and to a Fleet management cluster
Copy file name to clipboardExpand all lines: reference/fleet/upgrade-elastic-agent.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -101,6 +101,7 @@ You can do rolling upgrades to avoid exhausting network resources when updating
101
101
102
102
5. Upgrade the agents.
103
103
104
+
Note that agents in a rollout period have the status `Updating` until the upgrade is complete, even if the upgrade has not started yet.
104
105
105
106
## Schedule an upgrade [schedule-agent-upgrade]
106
107
@@ -245,7 +246,9 @@ To configure an automatic rollout of a new minor or patch version to a percentag
245
246
7. You can then add a different target version, and specify the percentage of agents you want to be upgraded to that version. The total percentage of agents to be upgraded cannot exceed 100%.
246
247
8. Click **Save**.
247
248
248
-
Once the configuration is saved, an asynchronous task runs every 30 minutes, gradually upgrading the agents in the policy to the specified target version.
249
+
Once the configuration is saved, an asynchronous task runs every 30 minutes, upgrading the agents in the policy to the specified target version.
250
+
251
+
If the number of agents to be upgraded is greater than or equal to 10, a rollout period is automatically applied. The rollout duration is either 10 minutes or `nAgents * 0.03` seconds, whichever is greater.
249
252
250
253
In case of any failed upgrades, the upgrades are retried with exponential backoff mechanism until the upgrade is successful, or the maximum number of retries is reached. Note that the maximum number of retries is the number of [configured retry delays](#auto-upgrade-settings).
For a comparison of EDOT and APM data streams, refer to [Comparison with classic APM data streams](opentelemetry://reference/compatibility/data-streams.md#comparison-with-classic-apm-data-streams).
39
+
38
40
### Availability [apm-collect-data-availability]
39
41
40
42
| Language | Elastic Distributions of OpenTelemetry (EDOT) | Elastic APM agent |
# Quickstart: Send data to the Elastic Cloud Managed OTLP Endpoint
9
+
# Quickstart: Send data to the {{motlp}}
10
10
11
-
In this quickstart guide, you'll learn how to use the [{{ecloud}} Managed OTLP Endpoint](opentelemetry://reference/motlp.md)to send logs, metrics, and traces to Elastic.
11
+
The {{motlp}} is a fully managed offering exclusively for Elastic Cloud users that simplifies OpenTelemetry data ingestion. It provides an endpoint for OpenTelemetry SDKs and Collectors to send telemetry data, with Elastic handling scaling, data processing, and storage. Refer to [{{motlp}}](opentelemetry://reference/motlp.md)for more information.
12
12
13
-
::::{warning}
14
-
This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features.
15
-
::::
13
+
This endpoint is designed for the following use cases:
14
+
15
+
* Logs & Infrastructure Monitoring: Logs forwarded in OTLP format and host and Kubernetes metrics in OTLP format.
16
+
* APM: Application telemetry in OTLP format.
17
+
18
+
In this quickstart guide, you'll learn how to use the {{motlp}} to send logs, metrics, and traces to Elastic.
16
19
17
20
## Prerequisites
18
21
19
22
* An {{obs-serverless}} project. To learn more, refer to [create an Observability project](/solutions/observability/get-started.md).
20
23
* A system forwarding logs, metrics, or traces in OTLP (any EDOT Collector or SDK—EDOT or community).
21
24
22
-
### Limitations
25
+
##Get started
23
26
24
-
* The {{ecloud}} Managed OTLP Endpoint only supports histograms with delta temporality. Cumulative histograms are dropped.
25
-
* Latency distributions based on histogram values have limited precision due to the fixed boundaries of explicit bucket histograms.
27
+
## Send data to Elastic
26
28
27
-
## Get started
29
+
Follow these steps to send data to Elastic using the {{motlp}}.
28
30
29
-
### Get your native OTLP endpoint credentials
31
+
::::::{stepper}
30
32
31
-
1.[Create a new Observability project](/solutions/observability/get-started.md), or open an existing one.
33
+
:::::{step} Check the requirements
32
34
33
-
1. In your {{obs-serverless}} project, go to **Add Data**.
35
+
To use the {{motlp}} you need the following:
34
36
35
-
1. Under **What do you want to monitor?** select **Application**, and then under **Monitor your application using** select **OpenTelemetry**.
37
+
* An Elastic Observability Serverless project. Security projects are not yet supported.
38
+
* An OTLP-compliant shipper capable of forwarding logs, metrics, or traces in OTLP format. This can include the OpenTelemetry Collector (EDOT, Contrib, or other distributions), OpenTelemetry SDKs (EDOT, upstream, or other distributions), or any other forwarder that supports the OTLP protocol.
36
39
37
-
:::{note}
38
-
Follow this flow for all use cases, including logs and infrastructure monitoring.
39
-
:::
40
+
:::::
40
41
41
-
1. Copy the `OTEL_EXPORTER_OTLP_ENDPOINT` URL. Replace `.apm` with `.ingest` and save this value for later.
42
+
:::::{step} Locate your {{motlp}}
42
43
43
-
### Create an API key
44
+
To retrieve your {{motlp}} endpoint address and an API key, follow these steps:
44
45
45
-
1. Click **Create an API Key** to generate a new API key. Copy this value for later.
46
-
1. (Optional) Test your new API key by sending an empty JSON object to the `/v1/traces` endpoint. For example:
46
+
1. In {{ecloud}}, create an Observability project or open an existing one.
47
+
2. Select your project's name and then select **Manage project**.
48
+
3. Locate the **Connection alias** and select **Edit**.
% ## commented out until mOTLP on ECH is available
52
+
% ### Elastic Cloud on Elasticsearch ({{ech}})
53
+
% 1. Open your deployment in the Elastic Cloud console.
54
+
% 2. Navigate to **Integrations** and find **OpenTelemetry** or **Managed OTLP**.
55
+
% 3. Copy the endpoint URL shown.
56
+
% ## Self-Managed
57
+
% For self-managed environments, you can deploy and expose an OTLP-compatible endpoint using the EDOT Collector as a gateway. Refer to [EDOT deployment docs](https://www.elastic.co/docs/reference/opentelemetry/edot-collector/modes#edot-collector-as-gateway).
58
+
%
59
+
% :::{note}
60
+
% Please reach out to support, and then Engineering can look into increasing it based on the license tier or for experimentation purposes.
61
+
% :::
55
62
56
-
The response should be similar to:
63
+
:::::
57
64
58
-
```txt
59
-
{"partialSuccess":{}}%
60
-
```
65
+
:::::{step} Create an API key
61
66
62
-
### Send data to your Elastic Cloud Managed OTLP endpoint
67
+
Generate an API key with appropriate ingest privileges to authenticate OTLP traffic:
63
68
64
-
* [I have an EDOT Collector/SDK running](#otel-sdk-running)
65
-
* [I need an EDOT Collector/SDK](#no-sdk-running)
66
-
* [I just want to use the instrumentation](#instrumentation-please)
69
+
1. In {{ecloud}}, go to **Manage project** → **API Keys**.
70
+
2. Select **Create API Key**.
71
+
3. Name the key. For example, `otlp-client`.
72
+
4. Edit the optional security settings.
73
+
5. Select **Create API Key**.
74
+
6. Copy the key to the clipboard.
75
+
76
+
Add this key to your final API key string. For example:
77
+
78
+
```
79
+
Authorization: ApiKey <your-api-key>
80
+
```
67
81
68
-
#### I have an EDOT Collector/SDK running [otel-sdk-running]
82
+
:::{important}
83
+
The API key copied from Kibana does not include the `ApiKey` scheme. Always prepend `ApiKey ` before using it in your configuration or encoding it for Kubernetes secrets. For example:
69
84
70
-
If you have an OpenTelemetry Collector or SDK exporting telemetry data,
71
-
configure it with the endpoint and API key generated in the previous steps.
85
+
- Correct: `Authorization: ApiKey abc123`
86
+
- Incorrect: `Authorization: abc123`
87
+
:::
72
88
73
-
**OpenTelemetry Collector configuration**
89
+
:::::
74
90
75
-
Configure your EDOT Collector as follows:
91
+
:::::{step} Send data to the {{motlp}}
92
+
93
+
The final step is to use the {{motlp}} endpoint and your Elastic API key to send data to {{ecloud}}.
94
+
95
+
::::{tab-set}
96
+
97
+
:::{tab-item} OpenTelemetry Collector example
98
+
To send data to the {{motlp}} from the {{edot}} Collector or the upstream Collector, configure the `otlp` exporter:
Configure your OTel SDK with the following environment variables:
126
+
:::{tab-item} Kubernetes example
127
+
You can store your API key in a Kubernetes secret and reference it in your OTLP exporter configuration. This is more secure than hardcoding credentials.
#### I just want to use the instrumentation [instrumentation-please]
171
+
## Differences from the Elastic APM Endpoint
123
172
124
-
See [application use-cases](opentelemetry://reference/edot-sdks/index.md) for more information.
173
+
The Elastic Cloud Managed OTLP Endpoint ensures that OpenTelemetry data is stored without any schema translation, preserving both OpenTelemetry semantic conventions and resource attributes. It supports ingesting OTLP logs, metrics, and traces in a unified manner, ensuring consistent treatment across all telemetry data. This marks a significant improvement over the [existing functionality](/solutions/observability/apm/use-opentelemetry-with-apm.md), which primarily focuses on traces and the APM use case.
125
174
126
175
## Troubleshoot
127
176
128
-
**Api Key prefix not found**
177
+
The following sections provide troubleshooting information for the {{motlp}}.
178
+
179
+
### I don't have a Collector or SDK running
180
+
181
+
Don't have a collector or SDK running? Spin up an EDOT collector in just a few steps:
You must format your API key as `"Authorization": "ApiKey <api-key-value-here>"` or `"Authorization=ApiKey <api-key>"` depending on whether you're using a collector or SDK. See [I have an EDOT Collector/SDK running](#otel-sdk-running) for more information.
197
+
You must format your API key as `"Authorization": "ApiKey <api-key-value-here>"` or `"Authorization=ApiKey <api-key>"` depending on whether you're using a collector or SDK.
139
198
140
-
**Error: too many requests**
199
+
### Error: too many requests
141
200
142
-
The Managed endpoint has per-project rate limits in place. If you hit this limit, reach out to our [support team](https://support.elastic.co).
201
+
The Managed OTLP endpoint has per-project rate limits in place. If you hit this limit, reach out to our [support team](https://support.elastic.co). Refer to [Rate limiting](opentelemetry://reference/motlp.md#rate-limiting) for more information.
0 commit comments