You've already forked opentelemetry-go
mirror of
https://github.com/open-telemetry/opentelemetry-go.git
synced 2026-06-03 18:35:08 +02:00
1ee7c79b73
Per https://github.com/open-telemetry/opentelemetry-go/pull/6271#issuecomment-2657554647 > 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. https://github.com/open-telemetry/opentelemetry-specification/issues/4364 is not necessary. See https://github.com/open-telemetry/opentelemetry-specification/pull/4290#discussion_r1927546170 for more context. - It is going be an example for https://github.com/open-telemetry/opentelemetry-specification/issues/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 https://github.com/open-telemetry/opentelemetry-go/pull/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: - https://github.com/open-telemetry/opentelemetry-go/pull/6271 - https://github.com/open-telemetry/opentelemetry-go/pull/6286 I also created for tracking purposes: - https://github.com/open-telemetry/opentelemetry-go/issues/6328
37 lines
1.6 KiB
Go
37 lines
1.6 KiB
Go
// Copyright The OpenTelemetry Authors
|
|
// SPDX-License-Identifier: Apache-2.0
|
|
|
|
/*
|
|
Package log provides the OpenTelemetry Logs SDK.
|
|
|
|
See https://opentelemetry.io/docs/concepts/signals/logs/ for information
|
|
about the concept of OpenTelemetry Logs and
|
|
https://opentelemetry.io/docs/concepts/components/ for more information
|
|
about OpenTelemetry SDKs.
|
|
|
|
The entry point for the log package is [NewLoggerProvider].
|
|
[LoggerProvider] is the object that all Bridge API calls use to create
|
|
Loggers, and ultimately emit log records.
|
|
Also, it is an object that should be used to
|
|
control the life-cycle (start, flush, and shutdown) of the Logs SDK.
|
|
|
|
A LoggerProvider needs to be configured to process the log records, this is
|
|
done by configuring it with a [Processor] implementation using [WithProcessor].
|
|
The log package provides the [BatchProcessor] and [SimpleProcessor]
|
|
that are configured with an [Exporter] implementation which
|
|
exports the log records to given destination. See
|
|
[go.opentelemetry.io/otel/exporters] for exporters that can be used with these
|
|
Processors.
|
|
|
|
The data generated by a LoggerProvider needs to include information about its
|
|
origin. A LoggerProvider needs to be configured with a Resource, by using
|
|
[WithResource], to include this information. This Resource
|
|
should be used to describe the unique runtime environment instrumented code
|
|
is being run on. That way when multiple instances of the code are collected
|
|
at a single endpoint their origin is decipherable.
|
|
|
|
See [go.opentelemetry.io/otel/log] for more information about
|
|
the OpenTelemetry Logs Bridge API.
|
|
*/
|
|
package log // import "go.opentelemetry.io/otel/sdk/log"
|