[WIP] OTEP: Logger.Enabled #4290
Conversation
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Co-authored-by: Cijo Thomas <cithomas@microsoft.com>
oteps/logs/4290-logger-enabled.md
Outdated
|
|
||
| For (3) (4), the user can declarativly configure the Logs SDK using `LoggerConfigurator` to set the `disabled`, `minimum_severity_level`, `disabled_not_recorded_spans` of a `LoggerConfig`. | ||
|
|
||
| For (5) (6) (7), the user can hook to `Logger.Enabled` Logs API calls by adding to the Logs SDK a `LogRecordProcessor` implementing `OnEnabled`. |
There was a problem hiding this comment.
I'd add LogRecordExporter implementing OnEnabled too, though technically a processor can do the job
There was a problem hiding this comment.
I do not think this makes sense for "batching" exporters. I see LogRecordExporter as an abstraction that is suited for batching.
EDIT: Moreover, by implementing user_event and ETW exporters as log record processors we are skipping one abstraction that should reduce the overhead.
Co-authored-by: Cijo Thomas <cithomas@microsoft.com>
| 2. Avoid allocating memory to store a log record, avoid performing computationally expensive operations and avoid exporting when emitting a log or event record is unnecessary. | ||
| 3. Configure a minimum a log serverity level on the SDK level. | ||
| 4. Filter out log and event records when they are not inside a recording span. | ||
| 5. Have **fine-grained** filtering control for logging pipelines without using an OpenTelemetry Collector (e.g. mobile devices, serverless, IoT). |
There was a problem hiding this comment.
One thing I am not so sure about.. Do we expect OTel SDK to provide such control, mimicking what is often provided by the Logging libraries themselves? They often provide sophisticated mechanisms, and it may not be worth replicating everything in OTel...
We can explicitly state that our desire is to provide some control, but not necessarily matching/competing with existing logging libraries?
There was a problem hiding this comment.
I do not expect the Logs API to be as user-friendly as the logging libraries popular for given language.
However, I think that the SDK (the logging backend) should be able handle different logging processing scenarios. E.g. sending verbose logs via user_events and warning logs via OTLP (probably I could come up with better examples). I heard that someone wanted to send non-event log records and event records to different destinations. Moreover, there is the following question in the Events Basics OTEP:
How to support routing logs from the Logs API to a language-specific logging library while simultaneously routing logs from the language-specific logging library to an OpenTelemetry Logging Exporter?
I see logging libraries as logs frontend and Logs SDK as logs backend. Logs API is the thing which can bridges between the frontend and backend.
Side note: I think that even without this use case we would get the same design.
Co-authored-by: Cijo Thomas <cithomas@microsoft.com>
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Towards: