- Regenerate proto bindings with yojson support
- Add JSON encoding path in Resource_signal.Encode
- Pass protocol from config to generic_http_consumer
- Set Content-Type/Accept headers based on protocol
- Remove hardcoded protobuf headers from all HTTP client implementations
- Add yojson dependency
- Rename http_config to exporter_config with deprecated alias
- add OTEL_SDK_DISABLED support (sdk_disabled field)
- add OTEL_EXPORTER_OTLP_PROTOCOL support (Http_protobuf | Http_json)
- add OTEL_LOG_LEVEL support (log_level field replacing debug bool)
- add OTEL_EXPORTER_OTLP_TIMEOUT and per-signal timeout variants
- add per-signal headers
(OTEL_EXPORTER_OTLP_{TRACES,METRICS,LOGS}_HEADERS)
- add OTEL_SERVICE_NAME support
also remove some globals and put most config in `exporter_config.ml`,
which is no longer a private record.
The ezcurl library changed its client type from Curl.t to Ezcurl_core.t
(an unboxed record type) in version 0.3. Updated both sync and lwt
implementations to use the correct type and module functions.
This allows clien implementors to micromanage the state of the protobuf
`encoder` if they want, or to just let the library handle allocation and
garbage collection of encoder states when that level of resource
managment is not required.
As of OCaml 5.3, the OCaml runtime doesn't support signals on
Windows. Trying to block them with Thread.sigmask will raise:
Thread 5 killed on uncaught exception Invalid_argument("Thread.sigmask not implemented")
Raised by primitive operation at Opentelemetry_client_ocurl.start_bg_thread.run in file "src/client-ocurl/opentelemetry_client_ocurl.ml", line 106, characters 12-49
it's less dangerous to emit spans for self-tracing, even
if nothing else is going on, than risk having them accumulate
in case the program emits no spans but emits a lot of
metrics and logs (which create self-tracing spans)
we don't go through OTEL for self tracing as it can create
regular span emission where normally there would be none
(emitting a self-tracing span might create a batch, which then
has to be sent after the batch timeout, and sending
that one creates a new span, etc.)
it's cleaner to emit GC events on ticks rather than on GC,
because it avoids both spamming if the GC is very active, and
emitting nothing when there are few allocations.
