docs: document max inputs/outputs/filters plugin limits#2554
Open
pierluigilenoci wants to merge 2 commits intofluent:masterfrom
Open
docs: document max inputs/outputs/filters plugin limits#2554pierluigilenoci wants to merge 2 commits intofluent:masterfrom
pierluigilenoci wants to merge 2 commits intofluent:masterfrom
Conversation
Remove the outdated "up to 256 OUTPUT plugins" hard limit from both the classic and YAML configuration references. The routing bitmask was changed from a fixed-size array (4 × 64 = 256 bits) to a dynamically allocated bitmask that grows to match the number of configured output plugins, so the 256 cap no longer applies. Add a note to every plugin type section (INPUT, FILTER, OUTPUT) in both configuration formats clarifying that there is no hard-coded maximum and that the practical limit depends on available system resources. Closes fluent/fluent-bit#4201 Signed-off-by: Pierluigi Lenoci <pierluigilenoci@gmail.com>
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughDocumentation updates remove hard-coded upper bounds for INPUT, FILTER, and OUTPUT plugins, describing counts as not limited by code and constrained instead by runtime resources; OUTPUT routing bitmask is noted to be dynamically sized at startup based on configured output plugins. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (4)
administration/configuring-fluent-bit/classic-mode/configuration-file.md (2)
77-91: Clarify “no hard-coded limit” scope for FILTERs in classic mode.Same suggestion as INPUTs: explicitly tie the statement to absence of a compile-time plugin-count limit.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@administration/configuring-fluent-bit/classic-mode/configuration-file.md` around lines 77 - 91, Update the sentence that reads "There is no hard-coded limit on the number of `FILTER` sections." to explicitly state that in classic mode there is no compile-time or built-in limit on the number of `FILTER` sections or filter plugins (e.g., `FILTER` with `Name`, `Match`, `Match_Regex`), and clarify that the practical maximum is determined by runtime system resources such as memory and CPU; replace the vague line with a clear statement tying the lack of hard-coded limit to compile-time/plugin-count and noting the runtime resource-based constraints.
53-66: Clarify “no hard-coded limit” scope for INPUTs in classic mode.Consider changing to explicitly reference a compile-time cap (plugin-count) to avoid any perception of “truly unbounded.” Current practical-max clause already helps, but the added wording makes the guarantee unambiguous.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@administration/configuring-fluent-bit/classic-mode/configuration-file.md` around lines 53 - 66, Update the "Config input" section text to clarify the scope of "no hard-coded limit" for INPUT sections by stating there is no runtime hard-coded limit in classic mode but a compile-time cap may exist (e.g., a plugin-count constant), and recommend that practical limits depend on system resources; modify the paragraph that currently reads "There is no hard-coded limit on the number of `INPUT` sections." to explicitly mention "in classic mode there is no runtime hard-coded limit on `INPUT` sections, though a compile-time plugin-count cap may apply" and keep the following sentence about practical maximums based on memory and file descriptors intact (referencing the `INPUT` section and `input` plugin concept to locate the change).administration/configuring-fluent-bit/yaml/pipeline-section.md (2)
68-81: Clarify “no hard-coded limit” scope for INPUTs.This sentence is good, but “no hard-coded limit” can read as “unbounded in all cases.” Consider tightening to: “Fluent Bit does not impose a compile-time cap on the number of configured INPUT plugins; the practical maximum depends on system resources …” This prevents over-interpretation while keeping the same meaning.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@administration/configuring-fluent-bit/yaml/pipeline-section.md` around lines 68 - 81, Replace the ambiguous sentence about limits with a tightened phrasing referencing the inputs section: change the line in the "inputs" section that currently reads "There is no hard-coded limit on the number of input plugins." to something like "Fluent Bit does not impose a compile-time cap on the number of configured INPUT plugins; the practical maximum depends on available system resources such as memory and file descriptors." Ensure this edit is made within the inputs section where `inputs`, `name`, and `tag` are described.
136-150: Clarify “no hard-coded limit” scope for FILTERs.Same wording pattern as INPUTs: consider explicitly stating it’s a compile-time cap (plugin-count) rather than an absence of any other limit (memory and plugin-specific constraints still apply).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@administration/configuring-fluent-bit/yaml/pipeline-section.md` around lines 136 - 150, The sentence "There is no hard-coded limit on the number of filter plugins" is ambiguous—update the `filters` section text to mirror the INPUTs wording by clarifying that there is no compile-time hard limit on the number of filter plugins (i.e., no built-in plugin-count cap), but practical limits still apply due to system resources (memory) and plugin-specific constraints; reference the `filters` section and parameters like `name`, `match`, `match_regex`, and `log_level` so readers understand this applies to filter plugins.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@administration/configuring-fluent-bit/classic-mode/configuration-file.md`:
- Around line 77-91: Update the sentence that reads "There is no hard-coded
limit on the number of `FILTER` sections." to explicitly state that in classic
mode there is no compile-time or built-in limit on the number of `FILTER`
sections or filter plugins (e.g., `FILTER` with `Name`, `Match`, `Match_Regex`),
and clarify that the practical maximum is determined by runtime system resources
such as memory and CPU; replace the vague line with a clear statement tying the
lack of hard-coded limit to compile-time/plugin-count and noting the runtime
resource-based constraints.
- Around line 53-66: Update the "Config input" section text to clarify the scope
of "no hard-coded limit" for INPUT sections by stating there is no runtime
hard-coded limit in classic mode but a compile-time cap may exist (e.g., a
plugin-count constant), and recommend that practical limits depend on system
resources; modify the paragraph that currently reads "There is no hard-coded
limit on the number of `INPUT` sections." to explicitly mention "in classic mode
there is no runtime hard-coded limit on `INPUT` sections, though a compile-time
plugin-count cap may apply" and keep the following sentence about practical
maximums based on memory and file descriptors intact (referencing the `INPUT`
section and `input` plugin concept to locate the change).
In `@administration/configuring-fluent-bit/yaml/pipeline-section.md`:
- Around line 68-81: Replace the ambiguous sentence about limits with a
tightened phrasing referencing the inputs section: change the line in the
"inputs" section that currently reads "There is no hard-coded limit on the
number of input plugins." to something like "Fluent Bit does not impose a
compile-time cap on the number of configured INPUT plugins; the practical
maximum depends on available system resources such as memory and file
descriptors." Ensure this edit is made within the inputs section where `inputs`,
`name`, and `tag` are described.
- Around line 136-150: The sentence "There is no hard-coded limit on the number
of filter plugins" is ambiguous—update the `filters` section text to mirror the
INPUTs wording by clarifying that there is no compile-time hard limit on the
number of filter plugins (i.e., no built-in plugin-count cap), but practical
limits still apply due to system resources (memory) and plugin-specific
constraints; reference the `filters` section and parameters like `name`,
`match`, `match_regex`, and `log_level` so readers understand this applies to
filter plugins.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: b3f40571-9e9a-46e1-ae48-5fb532476ae6
📒 Files selected for processing (2)
administration/configuring-fluent-bit/classic-mode/configuration-file.mdadministration/configuring-fluent-bit/yaml/pipeline-section.md
eschabell
added
waiting-on-review
eschabell
requested changes
Apr 24, 2026
Collaborator
eschabell
left a comment
eschabell
left a comment
There was a problem hiding this comment.
Just two small fixes needed @pierluigilenoci, thanks for the docs PR!
Signed-off-by: Pierluigi Lenoci <pierluigilenoci@gmail.com>
Contributor
Author
|
Done — wrapped |
eschabell
approved these changes
Apr 25, 2026
Collaborator
eschabell
left a comment
eschabell
left a comment
There was a problem hiding this comment.
Good to go @pierluigilenoci, just waiting on code PR merge.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Remove the outdated "up to 256 OUTPUT plugins" hard limit and add
documentation for the maximum number of input, output, and filter plugins
in both the classic-mode and YAML configuration references.
What changed
The routing bitmask was changed from a fixed-size array (
4 × uint64_t = 256bits) to a dynamically allocated bitmask sized at startup based on the number
of configured output plugins (
flb_routes_mask_set_size()insrc/flb_engine.c).This means the former 256-output cap no longer applies.
Input and filter plugin instances are stored in linked lists with no
compile-time size limit, so they were never capped either.
Changes per file
administration/configuring-fluent-bit/classic-mode/configuration-file.mdadministration/configuring-fluent-bit/yaml/pipeline-section.mdCloses fluent/fluent-bit#4201
Signed-off-by: Pierluigi Lenoci pierluigilenoci@gmail.com
Summary by CodeRabbit