out_prometheus_exporter: run flushes on an output worker

[stondo]

Dependency

This draft is intentionally stacked on the HTTP-option correctness PR. It will be
rebased onto current master after that PR merges.

Depends on #12111

Summary

Run out_prometheus_exporter::cb_prom_flush() on one output worker by default rather
than on the main engine event loop.

The callback synchronously decodes the metrics chunk and encodes the Prometheus text
payload. Large process-metrics payloads can therefore occupy the main event loop long
enough to delay unrelated request handling.

Change

.workers = 1,

The runtime test additionally verifies:

output instance worker count == 1
output instance is threaded
output thread pool != NULL

Why one worker

• one worker isolates decode/encode CPU work from the main event loop
• one worker preserves serialized access to the exporter hash table
• the published payload remains protected by the existing mutex
• output workers are destroyed before the plugin context is freed
• out_vivo_exporter, the other HTTP-serving output, already uses one worker

Trade-off

Each Prometheus exporter instance gains one thread and its associated runtime
resources. The change does not reduce encoding CPU time; it changes where that work is
scheduled.

Configuration consideration

For outputs carrying FLB_OUTPUT_HTTP_SERVER, the bare workers compatibility alias
is parsed as an HTTP server setting before generic output-worker handling. The new
one-worker plugin default therefore is not currently overridden through that bare
property; http_server.workers continues to control HTTP listener workers.

This matches the existing out_vivo_exporter default. Maintainer feedback is welcome
on whether output-worker configurability for HTTP-serving outputs should be addressed
as a separate shared configuration change.

Performance evidence

Repeated current-master A/B tests used approximately 1500 processes and 5.4-5.5 MB
payloads:

Run	Scheduling	Worst TTFB	Requests over 100 ms
1	main event loop	175 ms	7
1	one output worker	15 ms	0
2	main event loop	165 ms	7
2	one output worker	17 ms	0

An earlier run showed the same direction: 158 ms and 11 requests over 100 ms versus
16 ms and none.

Testing

Commands:

cmake -S . -B build-container-bookworm \
  -DFLB_TESTS_RUNTIME=On \
  -DFLB_TESTS_INTERNAL=On \
  -DFLB_EXAMPLES=Off \
  -DCMAKE_CXX_FLAGS=-mavx2
cmake --build build-container-bookworm -j8
ctest --test-dir build-container-bookworm \
  -R '^flb-rt-out_prometheus_exporter$' \
  --output-on-failure
ctest --test-dir build-container-bookworm \
  -R '^flb-it-http_server$' \
  --output-on-failure
FLUENT_BIT_BINARY="$PWD/build-container-bookworm/bin/fluent-bit" \
tests/integration/.venv/bin/python -m pytest \
  tests/integration/scenarios/out_prometheus_exporter/tests/test_out_prometheus_exporter_001.py \
  -q
FLUENT_BIT_BINARY="$PWD/build-container-bookworm/bin/fluent-bit" \
VALGRIND=1 VALGRIND_STRICT=1 \
  tests/integration/.venv/bin/python -m pytest \
  tests/integration/scenarios/out_prometheus_exporter/tests/test_out_prometheus_exporter_001.py \
  -q

These ran in the documented Debian 12 rootless Podman environment. The explicit AVX2
flag is a GCC 12 compatibility workaround for bundled simdutf, not part of this
change.

Results:

• full YAML-enabled build: passed
• runtime regression test: passed 10 consecutive iterations
• HTTP server internal test: passed
• normal integration: 2 passed
• strict Valgrind integration: 2 passed
• both Valgrind runs: 0 bytes live at exit, 0 errors
• CI commit-prefix validation: passed
• DCO: signed

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing

• Example configuration and repeated A/B evidence included
• Runtime output included
• Valgrind output shows no leaks or memory corruption

Packaging

• [N/A] No packaging or container-output change

Documentation

• [N/A] No new configuration surface

Backporting

• No backport requested initially; gather maintainer feedback on the new default

Fluent Bit is licensed under Apache 2.0. By submitting this pull request I understand
that this code will be released under the terms of that license.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 1d96b30f-8f4d-44fc-962e-5e95435662de

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}