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

Standardize SDK logging levels #2039

Open
MrAlias opened this issue Oct 19, 2021 · 9 comments
Open

Standardize SDK logging levels #2039

MrAlias opened this issue Oct 19, 2021 · 9 comments
Labels
area:configuration Related to configuring the SDK area:sdk Related to the SDK sig-issue A specific SIG should look into this before discussing at the spec spec:miscellaneous For issues that don't match any other spec label

Comments

@MrAlias
Copy link
Contributor

MrAlias commented Oct 19, 2021

Currently, the SDK logging is specified to be configured via the OTEL_LOG_LEVEL environment variable. There currently is only one log level listed in the specification: info. However, other log levels are not specified. It is important that each language use the same logging level so user configuration of environment variables will be cross-language compatible.

The compliance matrix shows only three language implement this environment variable: javascript, ruby, and erlang. Auditing these languages I have found the following logging levels being used.

Javascript

https://github.com/open-telemetry/opentelemetry-js/blob/feea5167c15c41f0aeedc60959e36c18315c7ede/packages/opentelemetry-core/src/utils/environment.ts#L187-L195

  • ALL
  • VERBOSE
  • DEBUG
  • INFO
  • WARN
  • ERROR
  • NONE

Ruby

https://github.com/open-telemetry/opentelemetry-ruby/blob/62d6ee584ce23ab23d8cde447c872b49486cedbd/sdk/lib/opentelemetry/sdk/forwarding_logger.rb#L20-L31

  • debug
  • info
  • warn
  • error
  • fatal
  • unknown

Erlang

As far as I can tall (I'm definitely not an Erlang programmer), they are using the built-in logging levels

  • emergency
  • alert
  • critical
  • error
  • warning
  • notice
  • info
  • debug

Proposed Solution

The intersection of the already implemented logging levels are: debug, info, error.

Standardizing on these values would mean that these languages will remain compliant. However, currently, only Javascript has released a stable release of OpenTelemetry. That would mean that if we wanted to add more than this minimal set of logging levels they should ideally remain compatible with the Javascript levels. Specifically, it seems having a "none" level would be ideal for users that do not want any logging output.

@MrAlias MrAlias added the spec:miscellaneous For issues that don't match any other spec label label Oct 19, 2021
@MrAlias
Copy link
Contributor Author

MrAlias commented Oct 19, 2021

@open-telemetry/javascript-approvers @open-telemetry/ruby-approvers @open-telemetry/erlang-approvers

@MrAlias
Copy link
Contributor Author

MrAlias commented Oct 19, 2021

It might also be worth trying to unify these logging levels with the logs telemetry signal severity levels: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#severity-fields

@hauleth
Copy link
Member

hauleth commented Oct 20, 2021

Erlang uses RFC 5424 log levels. Elixir before 1.11 used only debug, info, warning, and error, but recent versions support all 8 levels.

Technically there are 2 additional configuration options for Erlan all and none. While all is equivalent to debug there is difference between emergency and none, as the first will still pass emergency events while none will filter out everything (basically it disables logging).

@pellared
Copy link
Member

Related issue (pointed out by @owais 🙏 ) #920

@tsloughter
Copy link
Member

Note that the Erlang SDK isn't wired up to actually use that environment variable. If I remember correctly it is because I was going to wire it up, so added it as a configuration value that is read and parsed, but then wasn't sure how to actually use it :). Never got around to poking people to get that hashed out but now it sounds like this is going to be worked on.

@MSNev
Copy link
Contributor

MSNev commented Oct 25, 2021

While I agree that we should define a common "set" of logging levels that "should" be supported, different runtimes, languages and libraries will have their own set of levels that are used by their communities.

So as per the (signalfx/gdi-specification#139), I like the definition of

Distribution MAY support additional levels:

@dyladan
Copy link
Member

dyladan commented Apr 16, 2024

While I agree that we should define a common "set" of logging levels that "should" be supported, different runtimes, languages and libraries will have their own set of levels that are used by their communities.

So as per the (signalfx/gdi-specification#139), I like the definition of

Distribution MAY support additional levels:

I think I disagree. This is a config SIG issue in my opinion, but what we want is a single configuration that can be deployed to all your SDKs and your collector that behaves in a consistent manner.

@bryannaegele
Copy link
Contributor

I think we're good now in Erlang as the levels are getting translated.

@jack-berg
Copy link
Member

If we add support for log level to file config, we can standardize on an enumeration, and let each language define how values map to their ecosystem. A natural starting point would be to use the severity level definition from the log data model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:configuration Related to configuring the SDK area:sdk Related to the SDK sig-issue A specific SIG should look into this before discussing at the spec spec:miscellaneous For issues that don't match any other spec label
Projects
Status: Not blocking stability
Development

No branches or pull requests

10 participants