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

Log KeyValue Kind: KindError #5909

Open
Jesse0Michael opened this issue Oct 22, 2024 · 5 comments
Open

Log KeyValue Kind: KindError #5909

Jesse0Michael opened this issue Oct 22, 2024 · 5 comments
Labels
blocked:specification Waiting on clarification of the OpenTelemetry specification before progress can be made enhancement New feature or request response needed Waiting on user input before progress can be made

Comments

@Jesse0Michael
Copy link

Problem Statement

I am trying to write a custom Log Record Processor that will look at the record attributes for a KeyValue containing an error, and, if the record severity >= Error and it found an error Value that matches criteria included when configuring the processor, downgrade the severity to a Warn.

This is something I've done in other logging solutions with hooks or handlers. But I'm unable to write an otel Log Processor because there is no way to pull the error that was used as a log attribute, because the error value is converted to a string.
example: If the error is a context.Canceled, downgrade the severity of the log to a Warn

Proposed Solution

Would it be alright to add a new KindError to the log KeyValue Kinds

With supported func Error(key string, value error) KeyValue and func ErrorValue(v error) Value and func (v Value) AsError() error functions.

@Jesse0Michael Jesse0Michael added the enhancement New feature or request label Oct 22, 2024
@Jesse0Michael
Copy link
Author

If this is acceptable approach, I could work on the PR for it (as well as the subsequent PRs in https://github.com/open-telemetry/opentelemetry-go-contrib that would want to be updated to use the new Kind)

@dmathieu
Copy link
Member

I feel like this would break the specification requirements: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#type-any

@pellared what do you think about this proposal?

@pellared
Copy link
Member

pellared commented Oct 22, 2024

@Jesse0Michael, first of all, thanks for raising the issue.

I agree with @dmathieu that this would be not compliant with the specification. The SDK is designed to support the OpenTelemetry data-model and be compliant with the specification (see https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/sdk.md#additional-logrecord-interfaces). Therefore, it does not have kinds for all the core/common Go types. We could say that we also lack KindTime, KindDuration, KindComplex if we would like to support more Go core types.

If you think that the current design is not good (e.g. not user friendly), feel free to create an issue in https://github.com/open-telemetry/opentelemetry-specification so we can discuss it further.

This is something I've done in other logging solutions with hooks or handlers.

I think currently this is the way to go... E.g. decorate https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otelslog.

@dmathieu
Copy link
Member

@Jesse0Michael should we close this issue?

@dmathieu dmathieu added the response needed Waiting on user input before progress can be made label Nov 27, 2024
@pellared
Copy link
Member

@dmathieu, I think we can discuss it further. Maybe the API could accept a generic any and then the SDK would be responsible for translating it to something which fits the Logs Data Model. I think some languages do it that way e.g. .NET. WDYT?

@pellared pellared added the blocked:specification Waiting on clarification of the OpenTelemetry specification before progress can be made label Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked:specification Waiting on clarification of the OpenTelemetry specification before progress can be made enhancement New feature or request response needed Waiting on user input before progress can be made
Projects
None yet
Development

No branches or pull requests

3 participants