OTel javaagent class variables in log records

[defields923]

Hey, this seems like it could be improved. When logging class variables, such as:

log.info("{}", myClass);

The class will concat with the "toString"/String.valueOf method

That makes sense, but I've noticed a discrepancy when it comes to the attributes.

When adding a class to attributes via fluent API, the logback-appender will call String.valueOf on it, resulting in the same result as if it were concatenated into the body, but if I use the otlp.logs.exporter: "experimental-otlp/stdout" flag, the resulting console log has the attribute serialized as json (provided the class has Getter methods):

log.atInfo().addKeyValue("myClass", myClass)...
Attributes: {
myClass: {"foo": "bar"}

I'm trying to parse these key-value pairs with fluentbit, and it would be much easier to do so with the json serialized attribute rather than the result of toString.

I looked into the logback-appender code and see why the SDK's log records have the toString format:

  static void captureAttribute(AttributesBuilder attributes, Object key, Object value) {
    // empty values are not serialized
    if (key != null && value != null) {
      String keyStr = key.toString();
      // preserve type for boolean and numeric values, everything else is converted to String
      if (value instanceof Boolean) {
        ... Other checks ...
      } else {
        attributes.put(getAttributeKey(keyStr), String.valueOf(value));
      }
    }
  }

Could we possible change this so that class variables are serialized as json? I can deal with the Body being in the toString format; having the attributes in json would be a decent compromise for me.

You might suggest that I feed the stdout/tail/whatever other input into fluentbit instead of exporting from the javaagent to fluentbit's opentelemetry input, but that brings with it a host of other complexities and edge cases. Yes, I can use the experimental-otlp/stdout, define a fluentbit input to read it, but then I have to do the manual work of parsing this log, to say the least. I'd rather stick to the opentelemetry input if I can help it.

Thanks for reading.