Dev json logs

[krezreb]

Description:

Please include a description of this change and which issue it fixes. If no issue exists yet please include context and what problem it solves.

Review

• Functional review done
• Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• Documentation added if needed
• Existing documentation updated if needed

Related PR matomo-org/matomo#22994

[marcel-innocraft]

Given that there's no certainty of the encoded value in $line->content, it might be worth adding some checks or improved handling here. Since it's public method it should really return a class/interface for the message, but I appreciate it's not something you added so not something for today.
At a minimum I would null coalesce this level property reference, but i'd recommend populating all of the variables off the object and then letting the rest of this method run (if you want a consistent result). Is it intended that you return an object here when it normally returns an array?

[krezreb]

@marcel-innocraft actually the field will be present because it's set in the proposed json encoding function. I had to add this line because in the writer code the field is referred to as level but in the logviewer it's severity. I'm under the assumption that only lines generated using that class will be parsed here

[marcel-innocraft]

Assumptions are like the dangerous icebergs of code. When someone else starts logging their {"message": "Floating donkey"} messages then you'll run into trouble.
Having a class/interface would define the contract for working with these messages so then there are no assumptions being relied on, but short of increasing the scope with a refactor, I'd just make this a little safer. That's my 5c worth.

[AltamashShaikh]

@krezreb Can we read the config isJson logging enabled here ? and take an action accordingly, I assume if JSON logging is disabled but someone sends a logline as a JSON this will treat it as a JSON value.

[krezreb]

@AltamashShaikh that's a valid point. However I do not think that is a problem. If a user sends json content to the logger's message field it will still be prefixed when it appears in the logs, so it will fail the json_decode test.

Also in cases where there are historical non json encoded lines we need to keep the legacy reading. i'm not assuming users will think to purge their logs when they turn json_encodingn on