-
Notifications
You must be signed in to change notification settings - Fork 152
Add OTLP docs #3360
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.
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
base: mw-tsds-final-countdown
Are you sure you want to change the base?
Add OTLP docs #3360
Changes from 2 commits
30a00fb
2e20d91
a570a5f
e86aefe
81eb866
4479c8c
355b3a6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,98 @@ | ||
--- | ||
navigation_title: "Ingest OTLP metrics" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I suggest nesting this under advanced topics, as it's not technically required and not applicable, e.g. in serverless. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd really prefer not to hide this in the advanced topics. Arguably, this is a less advanced way to send data to Elasticsearch as it doesn't require as much Elasticsearch-specific know-how like data streams, index templates, mappings, and time_series_metric/time_series_dimensions flags. I think this can greatly simplify the getting started experience for storing metrics in Elasticsearch. |
||
applies_to: | ||
stack: preview 9.2 | ||
theletterf marked this conversation as resolved.
Show resolved
Hide resolved
|
||
serverless: preview | ||
products: | ||
- id: elasticsearch | ||
--- | ||
|
||
# Ingest metrics via the OpenTelemetry Protocol (OTLP) | ||
theletterf marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
In addition to the ingestion of metrics data via the bulk API, | ||
theletterf marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
{{es}} offers an alternative way to ingest data via the [OpenTelemetry Protocol (OTLP)](https://opentelemetry.io/docs/specs/otlp). | ||
|
||
The endpoint is available under `/_otlp/v1/metrics`. | ||
|
||
Ingesting metrics data via this endpoint has the following advantages: | ||
theletterf marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
* Improved ingestion performance, especially if the data contains many resource attributes. | ||
* Simplified index mapping: | ||
there's no need to manually create an index template, or define dimensions and metrics. | ||
felixbarny marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
Using the OTLP endpoint, metrics are dynamically mapped using the metadata included in the OTLP requests. | ||
felixbarny marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
## How to send data to the OTLP endpoint | ||
|
||
To send data from an OpenTelemetry collector to the {{es}} OTLP endpoint, | ||
theletterf marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
use the [`OTLP/HTTP` exporter](https://github.com/open-telemetry/opentelemetry-collector/tree/main/exporter/otlphttpexporter). | ||
This is an example configuration: | ||
|
||
```yaml | ||
extensions: | ||
basicauth/elasticsearch: | ||
client_auth: | ||
username: <user> | ||
password: <password> | ||
exporters: | ||
otlphttp/elasticsearch: | ||
endpoint: <es_endpoint>/_otlp | ||
sending_queue: | ||
enabled: true | ||
sizer: requests | ||
queue_size: 5000 | ||
block_on_overflow: true | ||
batch: | ||
flush_timeout: 5s | ||
sizer: bytes | ||
min_size: 2_000_000 | ||
max_size: 5_000_000 | ||
auth: | ||
authenticator: basicauth/elasticsearch | ||
``` | ||
Note that at this point, only `encoding: proto` is supported, | ||
which the `OTLP/HTTP` exporter uses by default. | ||
|
||
theletterf marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
The supported options for `compression` are `gzip` (default value of the `OTLP/HTTP` exporter) and `none`. | ||
|
||
[//]: # (TODO we might actually also support snappy and zstd, test and update accordingly) | ||
theletterf marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
To track metrics in your custom application, | ||
use the [OpenTelemetry language SDK](https://opentelemetry.io/docs/getting-started/dev/) of your choice. | ||
|
||
## When not to use the {{es}} OTLP endpoint | ||
|
||
On Elastic Cloud, use the [Elastic Cloud Managed OTLP Endpoint](opentelemetry:/reference/motlp.md) instead of connecting directly to the Elasticsearch OTLP endpoint. | ||
|
||
It's not recommended to send metrics from applications directly to the Elasticsearch OTLP endpoint, | ||
especially if there are many individual applications that each periodically send a small amount of metrics. | ||
Instead, send data to an OpenTelemetry collector first. | ||
This helps with handling many connections, | ||
and with creating bigger batches to improve ingestion performance. | ||
For more details on the recommended way to set up OpenTelemetry-based data ingestion, | ||
have a look at the [EDOT reference architecture](opentelemetry:/reference/architecture/index.md). | ||
|
||
At this point, {{es}} only supports the OTLP metrics endpoint (`/_otlp/v1/metrics`). | ||
Other signals, are not supported as a native {{es}} OTLP endpoint at the moment. | ||
To ingest other signals, | ||
such as logs, traces, and profiles, | ||
use a distribution of the OpenTelemetry collector that includes the [Elasticsearch exporter](opentelemetry:/reference/edot-collector/components/elasticsearchexporter.md), | ||
such as the [Elastic distribution of OpenTelemetry (EDOT) Collector](opentelemetry:/reference/edot-collector/index.md). | ||
|
||
## Send data to different data streams | ||
|
||
By default, metrics are ingested into the `metrics-generic.otel-default` data stream. | ||
You can influence the target data stream by setting specific attributes on your data: | ||
|
||
- `data_stream.dataset` or `data_stream.namespace` in attributes, with the following order of precedence: data point attribute -> scope attribute -> resource attribute | ||
- Otherwise, if the scope name contains `/receiver/<somereceiver>`, `data_stream.dataset` is set to the receiver name. | ||
- Otherwise, `data_stream.dataset` falls back to `generic` and `data_stream.namespace` falls back to `default`. | ||
|
||
The target data stream name is constructed as `metrics-${data_stream.dataset}.otel-${data_stream.namespace}`. | ||
|
||
## Mapping hints | ||
felixbarny marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
## Limitations | ||
|
||
* Histograms are only supported in delta temporality. | ||
Set the temporality preference to delta in your SDKs, | ||
or use the [`cumulativetodelta` processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/cumulativetodeltaprocessor) to avoid cumulative histograms to be dropped. | ||
* Exemplars are not supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's leave this as is, since the otlp entrypoint works only for, well, otlp data.