feat: Update Rabbitmq parser to use LoggingReceiverMacro

[dyl10s]

Description

Refactored the Rabbitmq parser to use the LoggingReceiverMacro. This shares some similarities with #1987 where we specifically need to register the processor for the transformation test.

Related issue

How has this been tested?

Generated golden files before the refactor. Refactored Rabbitmq and verified there were no changes.

Checklist:

• Unit tests
  • Unit tests do not apply.
  • Unit tests have been added/modified and passed for this PR.
• Integration tests
  • Integration tests do not apply.
  • Integration tests have been added/modified and passed for this PR.
• Documentation
  • This PR introduces no user visible changes.
  • This PR introduces user visible changes and the corresponding documentation change has been made.
• Minor version bump
  • This PR introduces no new features.
  • This PR introduces new features, and there is a separate PR to bump the minor version since the last release already.
  • This PR bumps the version.

[franciscovalentecastro]

Please move the r.ReceiverMixin.MultilineRules to a standalone confgenerator.LoggingProcessorParseMultilineRegex within the Expand method of "LoggingProcessorMacro".

The template for this update is elasticsearch.go in master after #2025 .

[dyl10s]

I moved this into the Expand method and it seemed to not correctly parse the multiline entries. You can see with the diff in the golden files on my most recent commit.

[franciscovalentecastro]

Please add more log line samples at the end of input.log so the last multiline log entry is parsed completely.

Nit : Add a new line at the end of the file.

[dyl10s]

Made this change but the parsing still does not seem to be working correctly. No changes are made after running make transformation_test_update

[franciscovalentecastro]

I see 🤔 ! Let me try to debug the reason of the multiline parse is not working.

[franciscovalentecastro]

I added two "sample" log lines at the end of the input.log and the multiline parsing worked (see sample output at the end of the comment). My suggestion is two add more sample lines at the bottom of input.log.

Why this works ?

The way fluent-bit multiparse rules work is using a start_state and a cont state. The cont state in rabbitmq (^(?!\d+-\d+-\d+ \d+:\d+:\d+\.\d+\+\d+:\d+)) will keep matching lines that doesn't look as the start_state (don't have the timestamp log format). This means, for a multiline log entry to be completely parsed it needs a followup log that matches start_state so fluent-bit know the previous log ended.

input.log

...
2025-08-18 05:07:43.557042+00:00 [erro] <0.130.0>
BOOT FAILED
===========
ERROR: could not bind to distribution port 25672, it is in use by another node: rabbit@keith-testing-rabbitmq
2025-08-19 04:07:07.777+00:00 [noti] <123.456.789> {shutdown,{connection_closed, "Broken pipe"}}
2025-08-19 04:07:07.777+00:00 [noti] <123.456.789> {shutdown,{connection_closed, "Broken pipe"}}

output_fluentbit.yaml

...
    severity: 0.0
    timestamp: 2025-08-18T04:07:07.777000000Z
  - jsonPayload:
      message: |-
        2025-08-18 05:07:43.557042+00:00 [erro] <0.130.0>
        BOOT FAILED
        ===========
        ERROR: could not bind to distribution port 25672, it is in use by another node: rabbit@keith-testing-rabbitmq
    labels:
      compute.googleapis.com/resource_name: hostname
      logging.googleapis.com/instrumentation_source: agent.googleapis.com/rabbitmq
    logName: projects/my-project/logs/transformation_test
    timestamp: now
  - jsonPayload:
      message: "{shutdown,{connection_closed, \"Broken pipe\"}}"
      process_id: 123.456.789
      severity: noti
    labels:
      compute.googleapis.com/resource_name: hostname
      logging.googleapis.com/instrumentation_source: agent.googleapis.com/rabbitmq
    logName: projects/my-project/logs/transformation_test
    severity: 0.0
    timestamp: now
  partialSuccess: true
  resource:
    labels: {}
    type: gce_instance

[quentinmit]

This feels like a fluent-bit bug. The flush_timeout setting is supposed to cause the final log entry to be emitted after the timeout expires even if there isn't another line. I'm guessing that the exit_on_eof setting is causing fluent-bit to exit before it has a chance to flush.

[dyl10s]

I added the additional log lines here but it does seem like a bug that could get fixed. This can work as a temporary solution though.

[franciscovalentecastro]

Sounds good ! I created b/439825446 to track this bug.

[franciscovalentecastro]

LGTM!

We will address separately the bug with missing last log in fluent-bit transformation tests.