Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Enabled to LogRecordProcessor #4363

Open
pellared opened this issue Jan 15, 2025 · 1 comment
Open

Add Enabled to LogRecordProcessor #4363

pellared opened this issue Jan 15, 2025 · 1 comment
Assignees
Labels
sig-issue A specific SIG should look into this before discussing at the spec spec:logs Related to the specification/logs directory

Comments

@pellared
Copy link
Member

pellared commented Jan 15, 2025

What are you trying to achieve?

A "hook" for Logger.Enabled for customization and flexibility via extending LogRecordProcessor with Enabled opt-in operation.

Additional context.

Created per:

Working implementation in OTel Go:

@cijothomas
Copy link
Member

OTel Rust also has this capability. Here's an example where it is leveraged to improve performance by dropping unwanted log early.

https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-appender-tracing/benches/logs.rs#L73-L80

pellared added a commit to open-telemetry/opentelemetry-go that referenced this issue Feb 18, 2025
Per
#6271 (comment)

> We agreed that we can move `FilterProcessor` directly to `sdk/log` as
Logs SDK does not look to be stabilized soon.

- Add the possibility to filter based on the resource and scope which is
available for the SDK. The scope information is the most important as it
gives the possibility to e.g. filter out logs emitted for a given
logger. Thus e.g.
open-telemetry/opentelemetry-specification#4364
is not necessary. See
open-telemetry/opentelemetry-specification#4290 (comment)
for more context.
- It is going be an example for
open-telemetry/opentelemetry-specification#4363

There is a little overhead (IMO totally acceptable) because of data
transformation. Most importantly, there is no new heap allocation.

```
goos: linux
goarch: amd64
pkg: go.opentelemetry.io/otel/sdk/log
cpu: 13th Gen Intel(R) Core(TM) i7-13800H
                 │   old.txt   │                 new.txt                  │
                 │   sec/op    │     sec/op      vs base                  │
LoggerEnabled-20   4.589n ± 1%   319.750n ± 16%  +6867.75% (p=0.000 n=10)

                 │   old.txt    │             new.txt             │
                 │     B/op     │     B/op       vs base          │
LoggerEnabled-20   0.000Ki ± 0%   1.093Ki ± 13%  ? (p=0.000 n=10)

                 │  old.txt   │            new.txt             │
                 │ allocs/op  │ allocs/op   vs base            │
LoggerEnabled-20   0.000 ± 0%   0.000 ± 0%  ~ (p=1.000 n=10) ¹
¹ all samples are equal
```

`Logger.Enabled` is still more efficient than `Logger.Emit` (benchmarks
from #6315).

```
goos: linux
goarch: amd64
pkg: go.opentelemetry.io/otel/sdk/log
cpu: 13th Gen Intel(R) Core(TM) i7-13800H
BenchmarkLoggerEmit/5_attributes-20               559934              2391 ns/op           39088 B/op          1 allocs/op
BenchmarkLoggerEmit/10_attributes-20             1000000              5910 ns/op           49483 B/op          5 allocs/op
BenchmarkLoggerEnabled-20                        1605697               968.7 ns/op          1272 B/op          0 allocs/op
PASS
ok      go.opentelemetry.io/otel/sdk/log        10.789s
```

Prior art:
- #6271
- #6286

I also created for tracking purposes:
- #6328
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig-issue A specific SIG should look into this before discussing at the spec spec:logs Related to the specification/logs directory
Projects
Status: In Progress
Status: In progress
Development

No branches or pull requests

2 participants