Support processing guest stdout/stderr through `tracing`

[lann]

In #431 we add support for copying guest output to the console. If we update that implementation to pass through tracing we would gain a nice way to hook in other log processing options.

cc @itowlson

[itowlson]

Could we brainstorm the desired behaviour here? I'm not very familiar with the various tracing options. E.g.:

• Should the guest output always go through tracing or should that be an option?
• Does the tracing output have a level associated with it? If so, what should guest output be?
• What metadata can/should we provide e.g. application id, component id, timestamp?

We can do this as a SIP or just figure out a general spec in this issue, but I'd like us to think about what we want before we dive into this!

[lann]

Should the guest output always go through tracing or should that be an option?

It should at least be optional at the engine level to support WAGI and any other triggers that need to process stdio. I think that it would otherwise make sense to pass all logging output through tracing, and handle log file/console output with subscribers.

Does the tracing output have a level associated with it? If so, what should guest output be?

Yes. I'd be inclined to default to DEBUG. It might be nice to make it configurable (per-component?), but with appropriate log event fields and filtering I don't think it is strictly necessary.

What metadata can/should we provide e.g. application id, component id, timestamp?

I think timestamps are handled by the subscriber. Application and component I would see as "spans"

I don't think we need a SIP for this. We're already using tracing. This is more an implementation detail, at least until we get to more instrumentation features.

[lann]

This is subsumed by #520