pipeline: router: Only logs are currently supported

[lecaros]

Summary by CodeRabbit

• Documentation
  • Conditional routing docs now show a "Supported" column indicating which signal types (logs, metrics, traces, any) are supported.
  • Removed several example routing sections and example configurations that demonstrated per-signal and multi-signal routing, simplifying the guidance and examples shown.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

A documentation update to pipeline/router.md adds a "Supported" column to the Signal types table in the Conditional routing section and removes several example routing subsections and their YAML/Conf examples that demonstrated per-signal and multi-signal routing.

Changes

Cohort / File(s)	Change Summary
Documentation update pipeline/router.md	Added a "Supported" column to the Signal types table (changing it from 2 columns to 3) and removed multiple example routing sections and their YAML/Conf examples (per-signal metrics/traces routing and multi-signal routing examples).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Single documentation file modified but with multiple removed example blocks to verify.
• Review focus: ensure the table content and formatting are correct; confirm removed examples are intentionally omitted and links/refs remain valid.

Poem

I nibble docs in twilight's hum,
A column added — tidy, done,
Examples pruned, the page feels light,
Hops of change beneath the moonlight. 🐇✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: clarifying that only logs are supported in conditional routing by adding a 'Supported' column and removing unsupported routing examples.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch lecaros-clarify-routing

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2cdb6bb and 885c5e2.

📒 Files selected for processing (1)

• pipeline/router.md (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• pipeline/router.md

---

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 and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2153f99 and 2cdb6bb.

📒 Files selected for processing (1)

• pipeline/router.md (1 hunks)

[alexakreizinger]

I'm still a little bit confused by this--would it help to change the sentence before the table to say something like "Not all signal types support conditional routing"? (right now the way it's phrased makes it sound like something else entirely)

[alexakreizinger]

should any be part of this table? (does any refer to a specific tag/label/name of something? if not, I think it makes more sense to remove it)

[eschabell]

@lecaros are you sure about this, when I have our tooling parse the code base to validate I get this:

Based on review of the Fluent Bit source code, the Signal types table is correct.

Looking at flb_router_config.c, the parse_signal_key function (lines 204-255) explicitly supports all four signal types:

flb_router_config.c Lines 237-248:

        if (len == 4 && strncasecmp(start, "logs", len) == 0) {
            mask |= FLB_ROUTER_SIGNAL_LOGS;
        }        
        else if (len == 7 && strncasecmp(start, "metrics", len) == 0) {
            mask |= FLB_ROUTER_SIGNAL_METRICS;
        }
        else if (len == 6 && strncasecmp(start, "traces", len) == 0) {
            mask |= FLB_ROUTER_SIGNAL_TRACES;
        }
        else if (len == 3 && strncasecmp(start, "any", len) == 0) {
            mask |= FLB_ROUTER_SIGNAL_ANY;
        }

And the header file flb_router.h defines these signals:

flb_router.hLines 95-101

enum flb_router_signal {
    FLB_ROUTER_SIGNAL_LOGS    = (1U << 0),
    FLB_ROUTER_SIGNAL_METRICS = (1U << 1),
    FLB_ROUTER_SIGNAL_TRACES  = (1U << 2),
    FLB_ROUTER_SIGNAL_ANY     = (FLB_ROUTER_SIGNAL_LOGS |
                                 FLB_ROUTER_SIGNAL_METRICS |
                                 FLB_ROUTER_SIGNAL_TRACES)

So conditional routing supports:
✅ logs - Routes log records
✅ metrics - Routes metric records
✅ traces - Routes trace records
✅ any - Routes all signal types (which is a bitmask OR of logs, metrics, and traces)

The documentation table in router.md at lines 285-292 is correct. We even have working configuration examples:

https://docs.fluentbit.io/manual/data-pipeline/router#route-multiple-signal-types

[eschabell]

@lecaros I dug a bit deeper and see now that they are STUBBED features, so metrics and traces always returns FALSE.

The ANY listing supports only LOGS. Good catch.... this needs a bigger update. I'm going to adjust the entire doc as examples need fixing too. I'm going to merge this and then fix the rest of the doc.