[Google.Cloud.Logging.NLog] Nlog logging structure

Hi! Problem description I have the following structure at stack driver using the following config: and it’s pretty understandable but I have to meet some standards where properties are in a flat structure. Something like that is expected:

  "jsonPayload": {    
    "someProperty": "propertyValue",
    "message": "2020-11-24 11:50:32.192 | INFO | InfoTrace | traceId:  | Hawk Server-1.0.0: started ",
   ...
  },

where someProperty is near the message in structure. Isn’t it better to require a full JSON layout from API clients to define jsonPayload exactly as they want?

Describe the solution you’d like I have two solutions actually:

1. Accept JsonLayout as user desire:

<layout xsi:type="JsonLayout" includeAllProperties="true">
                    <attribute name="message" layout="${defaultMessageFormat}" />
                    <attribute name="log_time" layout="${var:timeStampFormat}" />
                    <attribute name="team" layout="${var:team:default=dotnet}" />
                    <attribute name="service" layout="${var:serviceName:default=anonymous}" />
  </layout>

but it can be a breaking change, for that

1. By default all properties will be placed at properties object but with some prefixes like .someProperty properties are going to be at the root object

Additional context It’s something I really need now, but maybe there is a possibility to do that somehow? I can implement that, but I think greenlight is needed before. Thanks in advance for your help and time.

[jskeet]

Hmm… do you mean that even without any code changes, if you specify a JsonLayout that will be activated by NLog, possibly in the “rendering” part of the code? (I’m afraid I don’t use NLog myself normally, so this is all a bit new to me.)

If that is what you mean, option 3 is probably the cleanest in my view - it’s the most predictable, even if it feels a little clunky. In terms of a name, I think I’ll need to see what the code (and a test!) looks like first, as that will make me more aware of which NLog features it’s using. But yes, we can definitely discuss options about that.

In terms of documentation, I totally agree that we’ll want to document it, but you can probably leave that with me. Currently we have a bit of documentation in the README.md, but that should probably be moved into a docs/index.md file which I’m happy to do… and document this at the same time. At that point it would end up at https://googleapis.dev/dotnet/Google.Cloud.Logging.NLog/latest/index.html - or perhaps a separate “just configuration options” page linked from there and hosted in the same place.

[jskeet]

This has now been released in Google.Cloud.Logging.NLog version 3.2.0