`phosphor-logging` APIs (RFC)

[Andrew Jeffery]

On Wed, 28 Jul 2021, at 15:55, Patrick Williams wrote:
> On Wed, Jul 28, 2021 at 03:22:43PM +0930, Andrew Jeffery wrote:
> > On Wed, 28 Jul 2021, at 05:54, Patrick Williams wrote:
> 
> > >     - Useful data is missing from `journalctl` resulting in people working
> > >       around it by generating strings with `fmt` et.al.
> > 
> > Sounds promising! Reading the proposal it seems like you're appending 
> > certain bits of structured data to the message. I think it would be 
> > nice if the data could be interpolated into arbitrary positions and not 
> > just appended (note, I'm not asking for interpolation of arbitrary 
> > variables here unlike what can be achieved with raw use of fmt, only 
> > those captured via the structured logging).
> 
> Can you give me a concrete example of what you mean by this?  I'm not
> understanding.

I've left a comment on the patch:

https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-logging/+/45310/1/docs/structured-logging.md#60

But duplicating that here, how I'd like to use the API and what I'd 
like to see in the resulting journal message is:

```
value = "xyz.openbmc_project.EntityManager";
lg2::error("Error talking to {ENTITY} error code is {ERRNO}", "ENTITY", value, "ERRNO", 2);
```

The lg2 implementation renders the values into the format string and 
forwards the result as MESSAGE to the journal, along with the 
structured values (ENTITY and ERRNO in the example).

```
$ journalctl -b
...
Nov 25 13:13:09 bmc fansensor[3006]: Error talking to xyz.openbmc_project.EntityManager error code is 2
...
```

Better yet would be if we could just forward the format string and 
journalctl renders this at invocation time, but we'd need to work with 
upstream on that.

Andrew