Skip to content

docs: update apmschema url to use apm-data #723

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
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

docs: update apmschema url to use apm-data #723

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1d17691
docs: update apmschema url to use apm-data
kruskall Sep 2, 2025
4870014
Update README.md
kruskall Sep 2, 2025
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
6 changes: 3 additions & 3 deletions receiver/elasticapmintakereceiver/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ Receives data via HTTP using [APM IntakeV2 format](https://www.elastic.co/docs/s

The main purpose of this receiver is to enable classic Elastic APM Agents to send data to an OTel collector. This way users can gradually switch to OTel without needing to potentially replace lots of APM Agents which may be also used with some manually instrumented code.

The receiver currently supports the [Intake v2 protocol](https://github.com/elastic/apm-server/tree/main/docs/spec/v2). RUM intake, and older intake protocols, are not supported.
The receiver currently supports the [Intake v2 protocol](https://github.com/elastic/apm-data/tree/main/input/elasticapm/docs/spec/v2). RUM intake, and older intake protocols, are not supported.

## Getting started

Expand Down Expand Up @@ -107,7 +107,7 @@ The output of this component is the OTel native translation of the Elastic APM d
Because there is no clear 1:1 mapping between the OTel and the Elastic APM data model, there are three types of fields that go in the output OTel data. Everything that can be mapped to OTel, must be mapped into the OTel field defined by the OTel specs:

- All fields that are defined as top level fields in OTel are populated according to the OTel spec. Examples are `ParentSpanID`, `TraceID`, `StartTimestamp`, `EndTimestamp`.
- All Elastic APM Fields that can be mapped into a SemConv field, are mapped into SemConv fields. This hold true for both resource attributes and event specific attributes. For example, the [`service.name` field from the metadata](https://github.com/elastic/apm-server/blob/main/docs/spec/v2/metadata.json#L132) is stored on each event in the `service.name` SemConv attribute, while the [`node.name` field from the metadata](https://github.com/elastic/apm-server/blob/main/docs/spec/v2/metadata.json#L335) is stored on each event in the `service.instance.id`, and the `db.type` field from the Elastic APM span is stored in the `db.system` SemConv attribute.
- All Elastic APM Fields that can be mapped into a SemConv field, are mapped into SemConv fields. This hold true for both resource attributes and event specific attributes. For example, the [`service.name` field from the metadata](https://github.com/elastic/apm-data/blob/main/input/elasticapm/docs/spec/v2/metadata.json#L132) is stored on each event in the `service.name` SemConv attribute, while the [`node.name` field from the metadata](https://github.com/elastic/apm-data/blob/main/input/elasticapm/docs/spec/v2/metadata.json#L335) is stored on each event in the `service.instance.id`, and the `db.type` field from the Elastic APM span is stored in the `db.system` SemConv attribute.

- All fields required by Elastic APM, including Kibana, but are not part of any OTel spec, are stored in a custom attribute, using the Elastic APM field name as the key. Examples: the `transaction.name` of an Elastic APM transaction, which does not have an OTel equivalent, is stored in the `transaction.name` attribute. The `http.request.body` from the incoming Elastic APM data is stored in the `http.request.body` attribute.

Expand All @@ -116,4 +116,4 @@ The next component needed is the `elasticapm` processor, which takes care of enr

And then finally the `elasticsearch` exporter stores the data in Elasticsearch.

Currently, the whole pipeline will automatically store data in classic APM data streams. This is different from a fully OTel native pipeline with the OTLP receiver (as opposed to the `elasticapmintake` receiver), which by default stores data in [the OTel native data streams](https://github.com/elastic/opentelemetry-dev/blob/main/docs/design-decisions/ingest/routing.md). We still have the option to extend the components described above and add a config to potentially store data from classic Elastic APM Agents in OTel native data streams in a later iteration.
Currently, the whole pipeline will automatically store data in classic APM data streams. This is different from a fully OTel native pipeline with the OTLP receiver (as opposed to the `elasticapmintake` receiver), which by default stores data in [the OTel native data streams](https://github.com/elastic/opentelemetry-dev/blob/main/docs/design-decisions/ingest/routing.md). We still have the option to extend the components described above and add a config to potentially store data from classic Elastic APM Agents in OTel native data streams in a later iteration.
Loading