opentelemetry-erlang
opentelemetry-erlang copied to clipboard
OpenTelemetry Erlang SDK
Sets the SDK log level. Unsure what this actually means for the Erlang SDK, maybe supposed to set each module's level to the` OTEL_LOG_LEVEL`? Wouldn't be hard to do if...
Each active instrument (the combination of an instrument name and a labelset) is stored in the active instruments ets table. There is no reason to keep these active instrument rows...
The providers need a shutdown/terminate callback added and the SDK implementation of each should set the the meter and tracer to noops. This is currently done in the SDK's `prep_stop`...
As I was thinking about adding a `monitor` option to spans so that they can be ended if the process dies I realized it was probably a good idea to...
The name of an instrument must be namespaced by the Meter it was created with: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/metrics/api.md#instrument-naming-requirements Currently the name of the meter is ignored by `new_instrument` in `otel_meter_default`. Obviously this...
Add a pull controller for metrics gathering via systems like prometheus.
There is no longer a "labelset" part of the API, so the SDK takes the raw label and value in a tuple list. At some point in the metrics pipeline...
This will likely be broken into multiple tickets, and the Views API is not yet stable, but some work could be done on preparing for a stable Views API. See...
A Context must be able to be passed to any synchronous instrument recording (calls to `add` or `record`) and if none is passed the current context (`otel_ctx:get_current/0`) must be used.
In the SIG meeting yesterday @yurishkuro asked about auto-instrumentation, like in Java and others. I realized this is similar to what @ferd and I had discussed at one point making...