Open dpk83 opened 1 year ago
Tagging subscribers to this area: @dotnet/area-extensions-logging See info in area-owners.md if you want to be subscribed.
Author: | dpk83 |
---|---|
Assignees: | - |
Labels: | `api-suggestion`, `untriaged`, `area-Extensions-Logging` |
Milestone: | - |
@tarekgh @geeknoid
CC @reyang @CodeBlanch @davidfowl
LogProperties can have parameters that extends its functionality with more options.
Do we have more details about the behavior in general? This is a kind of serialization and needs to define the full scope of this serialization. For example, does it retrieve all properties which have getters either public or nonpublic inside the object? What do you expect to do when having types like collections (and which collections we should support)? What to expect if there is a cyclic reference? .... etc.
Much prefer structured logging support of @
-prefix destructuring and then handling in your logging provider. For example Serilog supports this, as do other structured logging providers. If source-gen supported it (there's some open issues for it) it would be a matter of just adapting your logging provider, I think.
Do we have more details about the behavior in general? This is a kind of serialization and needs to define the full scope of this serialization. For example, does it retrieve all properties which have getters either public or nonpublic inside the object? What do you expect to do when having types like collections (and which collections we should support)? What to expect if there is a cyclic reference? .... etc.
@tarekgh
error_Operation_Id
)Much prefer structured logging support of @-prefix destructuring and then handling in your logging provider. For example Serilog supports this, as do other structured logging providers. If source-gen supported it (there's some open issues for it) it would be a matter of just adapting your logging provider, I think.
pinkfloydx33 Doing this in source generation provides the performance benefits as all of this expansion is done at the compile time as opposed the runtime. I am not saying that support for logging complex object shouldn't be added for the normal logging provider but with source generation we should utilize it for extracting the best performance out.
@dpk83 per discussion I moved this issue to the future release.
Background and motivation
.NET uses source generation to provide high performance logging via LoggerMessage attribute. Source generation opens up a lot of flexibility to do more things in an efficient manner. We have a telemetry solution that is used by services across our orgs, as part of our solution we have expanded the LoggerMessage to support the following features
logger.Log("Failed to fetch data due to error: {0}, {1}, {2}", errorDetails.operationId, errorDetails.Type, errorDetails.Message);
. Instead with the support of complex object logging in LoggerMessage attribute developer can log the object directly i.e.logger.DataFetchFailed(errorDetails)
. This will perform the expansion of the errorDetails object as part of the compile time source generation in an efficient way (i.e. no runtime cost)API Proposal
Introduce
LogPropertiesAttribute
which is used to annotate an object that needs to be expanded for logging.API Usage
This will result in all parameters of the error details logged as
error_Operation_Id
,error_Operation_Name
,error_Type
,error_ErrorMessage
.This is a simplistic example. LogProperties can have parameters that extends its functionality with more options.
The above can be augmented via some attributes to indicate sensitive data so the generated code takes care of redacting it appropriately.
Similarly the attribute XYZ can be added to the members of the complex object and the generated code should be able to know and redact it.
Alternative Designs
No response
Risks
No response