General support for wildcards in spanlogs

[steve-hb]

Request

We should add wildcard support for components allowing for filtering. The one I'm currently struggling with is spanlogs, but I suspect other receivers, processors etc. share the same problem.

Use case

Currently we are only able to include known attributes (see Map#Get for reference), but when using heavy structured logging, this may be problematic - we don't know what developers may decide to include in their logs/metrics. I'm well aware of the drawbacks of having many attributes (performance, data privacy, security etc.) in this kind of data and that, if possible, we should try to discard many unused properties, but since other vendors allow us to freely ingest any kind of attribute and let us at least look at these, we should allow it here too.

In our specific use-case we invested heavily in putting nearly everything we need to know about our application from an observability perspective into span and logs attributes in order to be able to query/filter the data without log.message regex magic. This resulted in likely 100+ different attribute keys we were able to search in - fortunately not necessary to index most of them btw.

Maybe there are some examples or policies regarding this in the Grafana environment, therefore I'm open for comments/thoughts on this one.

PS: I'm open to contribute here again, but would like to have some thoughts/examples first before proposing a solution not aligning with other components.