From 1d17691da86472512a996bea036920c570dd32cd Mon Sep 17 00:00:00 2001 From: kruskall <99559985+kruskall@users.noreply.github.com> Date: Tue, 2 Sep 2025 16:26:10 +0200 Subject: [PATCH 1/2] docs: update apmschema url to use apm-data apm schema was moved to apm-data a long time ago and the apm-server files are just a mirror update the readme to use apm-data files to we can stop mirroring them in apm-server --- receiver/elasticapmintakereceiver/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/receiver/elasticapmintakereceiver/README.md b/receiver/elasticapmintakereceiver/README.md index 99f94d0ad..9706d5928 100644 --- a/receiver/elasticapmintakereceiver/README.md +++ b/receiver/elasticapmintakereceiver/README.md @@ -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 @@ -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. \ No newline at end of file +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. From 487001474289a3d2f6c05c242e0ed7a259e2df98 Mon Sep 17 00:00:00 2001 From: kruskall <99559985+kruskall@users.noreply.github.com> Date: Tue, 2 Sep 2025 16:27:23 +0200 Subject: [PATCH 2/2] Update README.md --- receiver/elasticapmintakereceiver/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/receiver/elasticapmintakereceiver/README.md b/receiver/elasticapmintakereceiver/README.md index 9706d5928..8f7949f43 100644 --- a/receiver/elasticapmintakereceiver/README.md +++ b/receiver/elasticapmintakereceiver/README.md @@ -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.