Exploring the Extensibility and Modification Limitations of LogRecord.Attributes #5631
Unanswered
CodeTherapist
asked this question in
Q&A
Replies: 1 comment
-
The above approach works, but costs a lot of allocation/cpu, as you have to convert the Attributes to a Dictionary, add things to it, convert it again to an Array, and then replace the old Attributes, with the newly created Array. We are hoping that |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I've been exploring the extensibility mechanism of
BaseProcessor<LogRecord>
, specifically looking at how I could extend the list ofAttributes
. I've noticed thatLogRecord.Attributes
is of typeIReadOnlyList<KeyValuePair<string,object?>>
and can't be modified directly.I'm curious as to why this is the case. From my perspective, it seems that the extensibility mechanism with a custom class inheriting from
BaseProcessor<LogRecord>
could potentially be more flexible. Could you provide some insight into this design decision?Additionally, when I add a byte array of my own protobuf structure, it always results in an array of
int
values. Is there a way to useAnyValue.ByteString
directly, as I would expect a byte array to be serialized?I'm eager to understand these aspects better and would be happy to contribute to enhancing this functionality if needed.
Here's what I've tried so far:
Beta Was this translation helpful? Give feedback.
All reactions