Skip to content

Commit 47e7881

Browse files
committed
feat(otlp): Add develop docs for OTLPIntegration
1 parent 51d13fc commit 47e7881

File tree

3 files changed

+102
-1
lines changed

3 files changed

+102
-1
lines changed
Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
---
2+
title: OTLP Integration
3+
---
4+
5+
This document outlines how to build a dedicated `OTLPIntegration` in SDKs that makes it easier for users using [OpenTelemetry](https://opentelemetry.io/) for instrumentation to send their spans and traces to Sentry's new [OTLP ingestion endpoint](https://docs.sentry.io/concepts/otlp/).
6+
7+
## Background
8+
9+
### Existing OpenTelemetry Support
10+
11+
Some of our SDKs (Node, Java) already shipped a complete Performance powered by OpenTelemetry (POTEL) system following the [OpenTelemetry Support spec](../opentelemetry).
12+
13+
Some other SDKs (Python, Ruby, Elixir) implement a simpler system with **only** the `SpanProcessor` and `Propagator` components.
14+
15+
While building the POTEL prototype for Python, we questioned if the complexity we were adding was justified and the architecture was scalable and decided to stop with POTEL for other backend SDKs.
16+
17+
### OTLP Ingestion Endpoint
18+
19+
Concurrently to the above SDK work, we also shipped first-class support for ingesting OTLP Traces and Logs. This opened up the possibility of a much cleaner system that allows users to setup OpenTelemetry with Sentry seamlessly while preserving behavior - **Trace Connectedness** that makes Sentry valuable.
20+
21+
## Integration Spec
22+
23+
The new integration MUST be called `OTLPIntegration` with the following signature:
24+
25+
```python
26+
OTLPIntegration(setup_otlp_exporter=True, setup_propagator=True)
27+
```
28+
29+
The arguments `setup_otlp_exporter` and `setup_propagator` MUST be booleans that default to `True` and can be turned off if needed by the user.
30+
31+
It MUST consist of and setup the following components:
32+
33+
* A `SpanExporter` that automatically configures the OTLP ingestion endpoint from the DSN
34+
* A `Propagator` that ensures Distributed Tracing works with other upstream and downstream services using Sentry SDKs
35+
* An `external_propagation_context` that extracts the active `trace_id` and `span_id` from the OpenTelemetry SDK
36+
37+
### SpanExporter
38+
39+
IF `setup_otlp_exporter` is `True`, the integration MUST do the following:
40+
41+
* Take the existing `TracerProvider` from OpenTelemetry if it exists, otherwise create a new one
42+
* Construct the OTLP Traces `endpoint` from the DSN
43+
* Add the `X-Sentry-Auth` header to a `headers` dictionary
44+
* Instantiate a `OTLPSpanExporter` from OpenTelemetry with the `endpoint` and `headers`
45+
* Instantiate a `BatchSpanProcessor` with the above `OTLPSpanExporter`
46+
* Add the `BatchSpanProcessor` to the `TracerProvider`
47+
48+
IF `setup_otlp_exporter` is `False`, the integration MUST skip this entire step so users can configure their exporters OR collectors manually if they wish to do so.
49+
50+
See the reference Python implementation:
51+
<GitHubCodePreview url="https://github.com/getsentry/sentry-python/blob/c68c3d6b5152b879bc107f76d9a9c78e95792235/sentry_sdk/integrations/otlp.py#L36-L55" />
52+
53+
### Propagator
54+
55+
The `Propagator` implementation is the same as in the earlier [OpenTelemetry Spec](../opentelemetry/#step-2-implement-the-sentrypropagator-on-your-sdk-add-sentrypropagator).
56+
57+
IF `setup_propagator` is `True`, the integration MUST setup the `Propagator`.
58+
59+
The way to setup the propagator is dependent on the language ecosystem. The Python implementation uses `set_global_textmap`.
60+
61+
IF `setup_propagator` is `False`, the integration MUST skip setting up the `Propagator` and leave it to user to configure manually if they wish to do so.
62+
63+
### External Propagation Context
64+
65+
This specification introduces a new `external_propagation_context` concept that is a global function that adds a new source of `trace_id` and `span_id` to be used in other Sentry event payloads.
66+
67+
This is to ensure that all other Sentry events such as Errors, Check-Ins, Logs and Metrics have the correct `TraceContext` (for Errors and Check-Ins) or `trace_id, span_id` attributes (for Logs and Metrics) and can be linked correctly to the relevant Trace and Span originating from OpenTelemetry.
68+
69+
#### Scope
70+
71+
The `Scope` implementation MUST add two new methods:
72+
73+
* `register_external_propagation_context(fn)` that takes a function and stores it as a global
74+
* `get_external_propagation_context` that when called calls the above stored global function and returns a `(trace_id, span_id)` tuple or `None`
75+
76+
Further, the scope's `get_trace_context` method should use this `get_external_propagation_context` in preference to the local `propagation_context` on the scope to fill in the `trace_id` and `span_id` in the respective event payloads.
77+
78+
It is RECOMMENDED to centralize this logic for fetching the active `trace_id` and `span_id` for Logs and Metrics if that is not already the case in your SDK.
79+
80+
See the reference Python implementation:
81+
<GitHubCodePreview url="https://github.com/getsentry/sentry-python/blob/c68c3d6b5152b879bc107f76d9a9c78e95792235/sentry_sdk/scope.py#L149-L165" />
82+
83+
<GitHubCodePreview url="https://github.com/getsentry/sentry-python/blob/c68c3d6b5152b879bc107f76d9a9c78e95792235/sentry_sdk/scope.py#L587-L610" />
84+
85+
#### Integration
86+
87+
The Integration then MUST call `register_external_propagation_context` with a function that fetches the `(trace_id, span_id)` tuple from OpenTelemetry.
88+
89+
See the reference Python implementation:
90+
<GitHubCodePreview url="https://github.com/getsentry/sentry-python/blob/c68c3d6b5152b879bc107f76d9a9c78e95792235/sentry_sdk/integrations/otlp.py#L23-L33" />
91+
<GitHubCodePreview url="https://github.com/getsentry/sentry-python/blob/c68c3d6b5152b879bc107f76d9a9c78e95792235/sentry_sdk/integrations/otlp.py#L70" />
92+
93+
## Comparison to POTEL
94+
95+
Note the difference in components above to the components in the POTEL implementation:
96+
97+
* A `SpanProcessor` for processing and packaging the Spans that OpenTelemetry emits
98+
* A `Propagator` that ensures Distributed Tracing works with other upstream and downstream services using Sentry SDKs
99+
* A `Sampler` that works with Sentry's `traces_sample_rate` and `traces_sampler`
100+
* Bidirectional syncing between Sentry's `Scope`s and OpenTelemetry's `Context` so that spans can be started in either API and interleaved freely while preserving the span tree

src/components/codeTabs.tsx

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -139,6 +139,7 @@ const Container = styled('div')`
139139
border-radius: 0 0 6px 6px;
140140
border: 1px solid var(--accent-11);
141141
border-top: none;
142+
margin-bottom: 1.5rem;
142143
}
143144
`;
144145

src/components/githubCodePreview.tsx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
'use client';
22

3-
import {useEffect, useState} from 'react';
3+
import {useEffect, useState, Fragment} from 'react';
44

55
import {CodeBlock} from './codeBlock';
66
import {CodeTabs} from './codeTabs';

0 commit comments

Comments
 (0)