New

The executive guide to generative AI

Read more
Loading

Spans

Elastic Stack Serverless

APM Server vs managed intake service

In Elastic Cloud Hosted, the APM Server receives data from Elastic APM agents and transforms it into Elasticsearch documents. In Elastic Cloud Serverless there is in fact no APM Server running, instead the managed intake service receives and transforms data.

Spans contain information about the execution of a specific code path. They measure from the start to the end of an activity, and they can have a parent/child relationship with other spans.

Agents automatically instrument a variety of libraries to capture these spans from within your application, but you can also use the Agent API for custom instrumentation of specific code paths.

Among other things, spans can contain:

  • A transaction.id attribute that refers to its parent transaction.
  • A parent.id attribute that refers to its parent span or transaction.
  • Its start time and duration.
  • A name, type, subtype, and action—see the span name/type alignment sheet for span name patterns and examples by APM agent. In addition, some APM agents test against a public span type/subtype spec.
  • An optional stack trace. Stack traces consist of stack frames, which represent a function call on the call stack. They include attributes like function name, file name and path, line number, etc.
Tip

Most agents limit keyword fields, like span.id, to 1024 characters, and non-keyword fields, like span.start.us, to 10,000 characters.

For performance reasons, APM agents can choose to sample or omit spans purposefully. This can be useful in preventing edge cases, like long-running transactions with over 100 spans, that would otherwise overload both the Agent and the APM Server or the managed intake service. When this occurs, the Applications UI will display the number of spans dropped.

To configure the number of spans recorded per transaction, see the relevant Agent documentation:

Agents stream spans to the APM Server or the managed intake service separately from their transactions. Because of this, unforeseen errors may cause spans to go missing. Agents know how many spans a transaction should have; if the number of expected spans does not equal the number of spans received by the APM Server or the managed intake service, the Applications UI will calculate the difference and display a message.

Spans are stored with transactions in the following data streams:

  • Application traces: traces-apm-<namespace>
  • RUM and iOS agent application traces: traces-apm.rum-<namespace>

See Data streams to learn more.

This example shows what span documents can look like when indexed in Elasticsearch.

In some cases, APM agents may collect large amounts of very similar or identical spans in a transaction. For example, this can happen if spans are captured inside a loop or in unoptimized SQL queries that use multiple queries instead of joins to fetch related data.

In such cases, the upper limit of spans per transaction (by default, 500 spans) can be reached quickly, causing the agent to stop capturing potentially more relevant spans for a given transaction.

Capturing similar or identical spans often isn’t helpful, especially if they are of very short duration. They can also clutter the UI, and cause processing and storage overhead.

To address this problem, APM agents can compress similar spans into a single span. The compressed span retains most of the original span information, including the overall duration and number of spans it represents.

Regardless of the compression strategy, a span is eligible for compression if:

  • It has not propagated its trace context.
  • It is an exit span (such as database query spans).
  • Its outcome is not "failure".

The APM agent selects between two strategies to decide if adjacent spans can be compressed. In both strategies, only one previous span needs to be kept in memory. This ensures that the agent doesn’t require large amounts of memory to enable span compression.

The agent uses the same-kind strategy if two adjacent spans have the same:

  • span type
  • span subtype
  • destination.service.resource (e.g. database name)

The agent uses the exact-match strategy if two adjacent spans have the same:

  • span name
  • span type
  • span subtype
  • destination.service.resource (e.g. database name)

You can specify the maximum span duration in the agent’s configuration settings. Spans with a duration longer than the specified value will not be compressed.

For the "Same-Kind" strategy, the default maximum span duration is 0 milliseconds, which means that the "Same-Kind" strategy is disabled by default. For the "Exact-Match" strategy, the default limit is 50 milliseconds.

Support for span compression is available in the following agents and can be configured using the options listed below:

OpenTelemetry spans are mapped to Elastic APM transactions and spans as follows:

  • Root spans, such as entry points, are mapped to APM transactions.
  • Child spans, such as internal operations and DB queries, are mapped to APM spans.

The following table summarizes the mapping between OpenTelemetry span kinds and Elastic APM entities.

OpenTelemetry span kind Mapped to APM Example
SERVER Transaction Incoming HTTP request (GET /users/{id})
CONSUMER Transaction Message queue consumer event
CLIENT Span Outgoing database query (SELECT * FROM users)
PRODUCER Span Sending a message to a queue
INTERNAL Span Internal function execution

The following example shows OpenTelemetry spans:

[
  {
    "traceId": "abcd1234",
    "spanId": "root5678",
    "parentId": null,
    "name": "GET /users/{id}",
    "kind": "SERVER"
  },
  {
    "traceId": "abcd1234",
    "spanId": "db1234",
    "parentId": "root5678",
    "name": "SELECT FROM users",
    "kind": "CLIENT"
  }
]

The previous OTel spans are stored by Elastic APM as follows:

Transaction: GET /users/{id}
 ├── Span: SELECT FROM users