journald: use body["MESSAGE"] for entry body

[kevinschoonover]

related: open-telemetry/oteps#188, open-telemetry/opentelemetry-collector-contrib#5846

Using the following configuration,

receivers:
  journald:
    logLevel: debug

exporters:
  loki:
    endpoint: <YOUR ENDPOINT>

service:
  pipelines:
    traces:
    logs:
      receivers: [journald]
      processors: [batch]
      exporters: [loki]

you will see the following error because Loki only supports having the body as a string

2021-11-06T16:24:00.252-0700	error	exporterhelper/queued_retry.go:183	Exporting failed. The error is not retryable. Dropping data.	{"kind": "exporter", "name": "loki", "error": "Permanent error: failed to transform logs into Loki log streams", "dropped_items": 10}
go.opentelemetry.io/collector/exporter/exporterhelper.(*retrySender).send
	go.opentelemetry.io/[email protected]/exporter/exporterhelper/queued_retry.go:183
go.opentelemetry.io/collector/exporter/exporterhelper.(*logsExporterWithObservability).send
	go.opentelemetry.io/[email protected]/exporter/exporterhelper/logs.go:133
go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).start.func1
	go.opentelemetry.io/[email protected]/exporter/exporterhelper/queued_retry_inmemory.go:105
go.opentelemetry.io/collector/exporter/exporterhelper/internal.consumerFunc.consume
	go.opentelemetry.io/[email protected]/exporter/exporterhelper/internal/bounded_memory_queue.go:99
go.opentelemetry.io/collector/exporter/exporterhelper/internal.(*boundedMemoryQueue).StartConsumers.func2
	go.opentelemetry.io/[email protected]/exporter/exporterhelper/internal/bounded_memory_queue.go:78

because the journald receiver sends it in the following format

InstrumentationLibraryLogs #0
InstrumentationLibrary
LogRecord #0
Timestamp: 2021-11-06 23:35:07.660848 +0000 UTC
Severity:
ShortName:
Body: {
     -> MESSAGE: STRING(bus: 5, device: 9 was not an MTP device)
     -> PRIORITY: STRING(6)
     -> SYSLOG_FACILITY: STRING(1)
     -> SYSLOG_IDENTIFIER: STRING(mtp-probe)
     -> SYSLOG_RAW: STRING(<14>Nov  6 16:35:07 mtp-probe: bus: 5, device: 9 was not an MTP device
)
     -> SYSLOG_TIMESTAMP: STRING(Nov  6 16:35:07 )
     -> _BOOT_ID: STRING(21c95bd00483448d827e6a6ef98de97c)
     -> _CAP_EFFECTIVE: STRING(1f7fdffffff)
     -> _CMDLINE: STRING(/usr/lib/udev/mtp-probe /sys/devices/pci0000:00/0000:00:08.1/0000:0a:00.3/usb5/5-1/5-1.4 5 9)
     -> _COMM: STRING(mtp-probe)
     -> _EXE: STRING(/usr/lib/udev/mtp-probe)
     -> _GID: STRING(0)
     -> _HOSTNAME: STRING(<REDACTED>)
     -> _MACHINE_ID: STRING(<REDACTED>)
     -> _PID: STRING(12954)
     -> _SOURCE_REALTIME_TIMESTAMP: STRING(1636241707660701)
     -> _SYSTEMD_CGROUP: STRING(/system.slice/systemd-udevd.service)
     -> _SYSTEMD_INVOCATION_ID: STRING(0a0cdf1e7f944d00b6475c04ed95c8fd)
     -> _SYSTEMD_SLICE: STRING(system.slice)
     -> _SYSTEMD_UNIT: STRING(systemd-udevd.service)
     -> _TRANSPORT: STRING(syslog)
     -> _UID: STRING(0)
     -> __CURSOR: STRING(s=9a461c87381b4d44a4867d9f1b5aa4c1;i=1818a;b=21c95bd00483448d827e6a6ef98de97c;m=100c8eacd;t=5d02735c07630;x=c701fd6f994b7f13)
     -> __MONOTONIC_TIMESTAMP: STRING(4308134605)
}

If I am reading the discussion on open-telemetry/oteps#188 correctly, it seems like the move is to standarize on Body being a string and putting the rest of the fields in the attributes which will solve the Loki exporter errors from above.

Wanted to open this sample PR to see if this is the correct approach / something y'all are interested in doing.

[djaglowski]

You're correct that this library will require some updates in order to support recent changes to the data model. This is a first party application, so it should not produce, by default, log entries with structured bodies. However, the data model will continue to allow structured bodies, and this library will support that as an option. Because of this, all log exporters should be able to handle structured bodies.

There's been a recent push to resolve open questions on the log data model. This effort has progressed quite a bit in recent months and it appears we are very close to a feature freeze. Once the data model is frozen, I'd like to scope out an overall set of changes to this library. I don't support making the suggested change until it is carefully considered as part of a larger set of related updates. Most likely this work will begin early in Q1.

[djaglowski]

I'm closing this for now. Please see the above comment for explanation.