You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ottrelite provides interoperability with OpenTelemetry (OTEL) through a set of adapter facilities.
6
+
7
+
#### Javascript
8
+
9
+
Firstly, Ottrelite provides its own `TracerProvider` ([`OttreliteTracerProvider.ts`](./src/otel/OttreliteTracerProvider.ts)) that provides adequate configuration for JS (configures the default resource to carry ottrelite's metadata, registers W3C & trace context baggage propagators, by default - `StackContextManager`). Invoking `register` on it, apart from the aforementioned, also calls invokes configuration of the global C++ API provider, described in the section below.
10
+
11
+
The analogous applies to [`OttreliteMeterProvider`](src/otel/OttreliteMeterProvider.ts). An implementation detail difference is that the meter provider hooks into returned instrument creation methods & their return values dynamically by replacing properties on instances, to call its own logic before the original is executed.
12
+
13
+
The OTEL API is also hooked into by the [`DevSpanProcessorInterceptor.ts`](src/otel/processor/DevSpanProcessorInterceptor.ts), which can be registered to propagate all OTEL spans live to the [Development API](../../README.md#development-api).
14
+
15
+
#### C++
16
+
17
+
##### Usage
18
+
19
+
The global C++ Tracer and Meter Providers are registered - respectively - from `installGlobalOTELCPPTracerProvider` and `installGlobalOTELCPPMeterProvider` Nitro Module methods. Calling each of those makes sense **only once**. At the first call, the Ottrelite tracer/meter exporters that have been instantiated and registered in JavaScript so far, will also be registered in the C++ API. This is the single-implementation, single-configuration approach that Ottrelite follows: create & configure all tracer/meter exporters in JS, use them from JS, C++, Kotlin/Java & Swift code.
20
+
21
+
> [!WARNING]
22
+
> Invoking the aforementioned install methods more than once will discard all previously registered C++ tracer/meter exporters. It is important to first register all the tracer/meter exporters in JS, and then call the `register()` methods of `OttreliteTracerProvider` and `OttreliteMeterProvider` in JS.
23
+
24
+
##### Configuration
25
+
26
+
The `Ottrelite.install` method accepts 3 C++ OTEL SDK - specific configuration options:
27
+
28
+
1.`cppBatchLogRecordProcessorOptions` - options for the `opentelemetry::sdk::logs::BatchLogRecordProcessorFactory`
29
+
2.`cppMetricReaderOptions` - options for the `opentelemetry::sdk::metrics::PeriodicExportingMetricReaderFactory`
30
+
3.`cppTraceBatchSpanProcessorOptions` - options for the `opentelemetry::sdk::trace::opentelemetry::sdk::trace::BatchSpanProcessorFactory`
31
+
32
+
Those can only be passed once and will be used to configure the C++ OTEL SDK, which is the data sink for OTEL traces from all interoperability layers in all languages. However, those options will only affect the C++ data export - other languages will process, report & provide the spans according to their own setup.
33
+
34
+
##### Implementing a custom exporter
35
+
36
+
To implement a custom exporter, first create a C++ Nitro Module spec:
Those methods are standard for OTEL exporters in according to its specification, yet the methods accept internal Ottrelite object types.
55
+
56
+
The `OTLPExporterConfig` is Nitro-codegened from [`OTLPExporterConfig.ts`](src/types/OTLPExporterConfig.ts) and represents the most important JS configuration for exporters in general. If some more configuration levels are needed to be covered, please file a PR or issue.
57
+
58
+
The `ExportResult` is trivial and is a 1:1 CPP-JS mapping of the result type.
59
+
60
+
The `SerializedReadableSpan` is a representation of a span in JS. Due to some limitations of Nitro, the object currently is not possible to be passed to CPP 1:1, however the overhead of conversion is minimal: some properties are only cast as types, while some need to be remapped:
61
+
62
+
- due to Nitro codegen problems with recursive type references, some methods need to be masked & some types require aliases
63
+
- all `SpanContext` objects are serialized to a string using built-in JS OTEL functionality, which is then parsed on the C++ side using built-in C++ OTEL functionality
64
+
65
+
For conversion of `SerializedReadableSpan`s to C++ OTEL vector of `Recordable`s, the `::ottrelite::interop::otel::SpanConverter::convertSpans(spans, resourcesMemory)` from `SpanConverter.hpp` can be used:
66
+
67
+
```cpp
68
+
#include"SpanConverter.hpp"
69
+
70
+
// ...
71
+
72
+
// converted Resource-s must be kept in memory for the time of export
0 commit comments