Exploring the Extensibility and Modification Limitations of LogRecord.Attributes

[CodeTherapist]

I've been exploring the extensibility mechanism of BaseProcessor<LogRecord>, specifically looking at how I could extend the list of Attributes. I've noticed that LogRecord.Attributes is of type IReadOnlyList<KeyValuePair<string,object?>> and can't be modified directly.

1. 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?

2. 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 use AnyValue.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:

 public class LogRecordProcessor : BaseProcessor<LogRecord>
    {
        public LogRecordProcessor()
        {
        }

        public override void OnEnd(LogRecord data)
        {
            var d = data.Attributes.ToDictionary(e => e.Key, e => e.Value);

            var mydata = new MyData()
            {
                MyValue = "test"
            };
            d.Add("test.ToByteArray", mydata.ToByteArray());
            d.Add("test.AnyValue", new AnyValue()
            {
                BytesValue = ByteString.CopyFrom(mydata.ToByteArray())
            });
            d.Add("test.AnyPack", Any.Pack(mydata));
            d.Add("test.ByteString", ByteString.CopyFrom(mydata.ToByteArray()));
            
            data.Attributes = d.ToArray();
            base.OnEnd(data);
        }

        public override void OnStart(LogRecord data)
        {
            base.OnStart(data);
        }
    }

[cijothomas]

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 ILogger's native enrichment story is the best to be leveraged here, as that would be much more performant, and as a bonus, will affect non OTel providers like ConsoleLogProviders.