[jsonlogencodingextension] Add Modes for Body with Attributes

[blakeromano]

Description:

The goal of this PR is to add configuration to the JSON Encoding method to have metadata from resources and attributes in logs and output those into a json attribute. This also will output the body of the log in the body attribute. This follows a similar pattern that the AWS Cloudwatch Log Exporter uses but removes any of the AWS specific logic and makes this a more generalized solution

Link to tracking Issue: #32679

Testing: Unit Tests were added to validate that the output is desired and that the existing logic remains the same.

Documentation: Documentation regarding the usage of the configuration as well as the output to expect is added.

[atoulme]

I am ok with this as an alternative to otlp json encoding. Noting outputting the resource attributes for each record is of course wasteful, I suppose you meant for this to be a self sufficient log representation

[blakeromano]

I am ok with this as an alternative to otlp json encoding. Noting outputting the resource attributes for each record is of course wasteful, I suppose you meant for this to be a self sufficient log representation

If I understand your comment enough that is correct. The idea is each index in the array is a self contained log. The hope is that this provides a fairly stable format for ingestion to be able to parse into a usable format. The other alternative I guess that I wasn't sure if it was possible would be to have a seperate return for each log record therefore instead of an array of items you'd have

{
    "body": "log testing",
    "resource": {
      "test": "logs-test"
    }
  }

which I think may be desirable however I am not sure the value add is worth it. I think if anything a future enhancement to the encoder could be a "split" mode where a user could define whether they'd want to split it into two separate log entries or have it combined into one but I feel like that may not be an encoder issue rather a processor problem.

We could also have a seperate mode later on for folks who do not want to have resource attributes in each document and instead have it once and then have each body in an array something like

{
  "body": [
    "foo",
    "bar",
  ],
  "resource": {
      "test": "logs-test"
    }
}

[dmitryax]

Maybe log_attributes and resource_attributes?

[blakeromano]

I was thinking of trying to stay with camelCase as most json is but I wouldn't be opposed to logAttributes and resourceAttributes

[atoulme]

LGTM with 2 nits.

[atoulme]

BTW, your approach discards scope log attributes, I'm not sure if that matters.

[blakeromano]

BTW, your approach discards scope log attributes, I'm not sure if that matters.

I don't think it matters but I am happy to hear other opinions

[blakeromano]

@atoulme @dmitryax all the tests should pass now. Let me know if there's anything else needed on my side to see this get merged.

[tiffany76]

Just a few grammar and style suggestions from a docs perspective. Thanks!

[blakeromano]

I believe I addressed all the naming and doc suggestions thank you for that feedback! I am not sure why there was so many status failures on the last commit. A lot of them seemed relating to something else so not sure it is because of this PR. I was able to validate linting and tests for this component were all passing.

[blakeromano]

Hey folks just wondering what the next steps are to get this merged? 😄

[andrzej-stencel]

This should be resourceAttributes I'm guessing?

Suggested change

	"resource": {
	"resourceAttributes": {

[andrzej-stencel]

Would be nice to make the headings consistent

Suggested change

	#### body Mode
	#### body

[andrzej-stencel]

It would be great if you could fix the small docs remarks in a follow-up PR @blakeromano

The component is in development stability, so it's probably better to move fast in small increments rather than sweat over every little detail.