Support Monolog 3.x

Thanks @guillaumeg - I’ll check the MR out once it’s up. IIRC there was something we needed to change for monolog 3, but can’t recall it!

Hi @GuillaumeG

Thanks for the MR, it's greatly appreciated.

Would you mind expanding a little on why you've removed the `LagoonLogsLogProcessor`?
Without it seems as though we're not getting a bunch of the fields that are calculated by `transformDataForProcessor`.

From my side, just to test, I've restored `LagoonLogsLogProcessor` and changed it's invoke signature to `public function __invoke(\Monolog\LogRecord $record) {` and this seems to bring the log details back in line with what the module is currently producing.

Some more info on this would be super. Thanks!

Hi bomoko,

Thanks a lot for checking the MR.

I removed LagoonLogsLogProcessor because I was able to get all the fields in the logs (OpenSearch) without this class and could not see any difference when comparing with a previous log entry.

Happy to restore the file with the changes you proposed if I am missing something, which is surely the case !
Or feel free to push a commit to my MR directly if you prefer.

Ah, thanks for the clarification!

I was actually testing locally capturing the udp output with nc - I wonder if there's some weirdness going on downstream.

This is what I was seeing, in terms of the difference in structure :-

Without LagoonLogsLogProcessor:

{
  "@timestamp": "2023-07-16T21:35:20.016453+00:00",
  "@version": 1,
  "host": "8b8e14550172",
  "message": "The file assets://js was not deleted because it does not exist.",
  "type": "project_unset-safe_branch_unset",
  "channel": "file",
  "level": "NOTICE",
  "monolog_level": 250
}

With LagoonLogsLogProcessor:

{
  "@timestamp": "2023-07-16T21:29:30.469535+00:00",
  "@version": 1,
  "host": "8b8e14550172",
  "message": "The file assets://js was not deleted because it does not exist.",
  "type": "project_unset-safe_branch_unset",
  "channel": "file",
  "level": "NOTICE",
  "monolog_level": 250,
  "ip": "127.0.0.1",
  "request_uri": "http://drupal10-base.docker.amazee.io/",
  "uid": 0,
  "link": "",
  "application": "drupal"
}

Which makes sense because the processor _should_ attach this arbitrary data to the log entry.

I wonder what's happening that it didn't make a difference for you between the two cases? This is the kind of mystery that keeps me up at night :D

I've just rerun in opensearch and can confirm that those fields are indeed missing from this branch, so will need readding in

Hi @bomoko / tobybellwood,

Thanks both, I was definitely missing these fields.

I have re-added the file with some changes to make it work with the LogRecord class.

Ready for review again.

Looking good @GuillaumeG - I've pinned your changes to D10+ only, and we'll release this as a new major version.

Merging into the new 3.x branch