Fluent Bit — Tail, Enrich and Forward Pipeline (conf)
A Fluent Bit configuration in its INI-like section format: a tail input using the CRI multiline parser that reassembles the partial-line fixture, Kubernetes enrichment, a modify filter dropping two of the high-cardinality fields, and a throttle. Keys are space-aligned, not delimited.
# Fluent Bit pipeline: read CRI container logs, parse the JSON body,
# enrich with Kubernetes metadata, then forward.
[SERVICE]
Flush 5
Daemon Off
Log_Level info
Parsers_File parsers.conf
HTTP_Server On
HTTP_Listen 0.0.0.0
HTTP_Port 2020
storage.path /var/log/flb-storage/
storage.sync normal
storage.backlog.mem_limit 64M
[INPUT]
Name tail
Tag kube.*
Path /var/log/containers/*shop*.log
multiline.parser cri
Mem_Buf_Limit 32MB
Skip_Long_Lines On
Refresh_Interval 10
DB /var/log/flb-tail.db
[FILTER]
Name kubernetes
Match kube.*
Kube_Tag_Prefix kube.var.log.containers.
Merge_Log On
Merge_Log_Key app
Keep_Log Off
K8S-Logging.Parser On
[FILTER]
Name modify
Match kube.*
Remove app.session_id
Remove app.device_id
Rename app.msg message
[FILTER]
Name throttle
Match kube.*
Rate 2000
Window 5
Interval 1s
[OUTPUT]
Name http
Match kube.*Specifications
- Sections
- 8
- Inputs
- 1
- Filters
- 3
- Outputs
- 1
- Format
- INI-style with indented key/value pairs
- Uses Cri Multiline Parser
- true
- Drops High Cardinality Keys
- 2
- Skip Long Lines
- true
Testing contract
Expected to pass- Scenario
- Parse the configuration and list the pipeline stages in order.
- Expected result
- Eight sections parse from the whitespace-aligned key/value format, and the modify filter is shown removing exactly the session_id and device_id fields that the high-cardinality log fixture carries.
What is a .conf file?
A .conf text file here is an OpenSSH-style client configuration SAMPLE with Host stanzas for fictional hosts.
How to use this file
Use the SAMPLE SSH config to test SSH config parsers and StrictHostKeyChecking tooling without real host keys.
How to use this file for testing
“Fluent Bit — Tail, Enrich and Forward Pipeline (conf)” is a deterministic Novus Examples fixture for Observability, Config parsing, Config testing. Structured and plain-text telemetry with known timestamps, levels, request identifiers, and error states for testing log ingestion, correlation, dashboards, and alert pipelines.
Documented properties for this file: INI-style with indented key/value pairs. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Telemetry fixtures use fixed trace IDs, span IDs, and timestamps so ingestion is reproducible run to run. Point your collector, parser, or query layer at the file and assert the documented span tree, metric families, or severity mix; service and host names are invented.
Related files
- yamlAlertmanager Config — Routing Tree, Inhibition and Mute Windows (yaml)An Alertmanager configuration with the routing behaviour that is hard to reason about without a fixture: a continue: true branch so a critical alert reaches two receivers, an inhibition rule suppressing warnings under a matching critical, and a weekend mute window.
- yamlOpenTelemetry Collector — Tail-Sampling Policies (yaml)Six tail-sampling policies including an inverted regex match that drops health checks and a composite policy with its own rate limit and ordered sub-policies. Policies are OR-ed and one match keeps the entire trace, which is the semantic most people get backwards.
- yamlOpenTelemetry Collector — Three-Signal Pipeline Configuration (yaml)A Collector configuration wiring traces, metrics and logs through separate pipelines, with named component instances, a filelog receiver that parses the CRI log fixture, OTTL statements performing the semantic-convention migration from the paired trace fixtures, and a redaction processor.
- yamlPrometheus Alerting Rules — Four Rules Across Two Groups (yaml)Four alerting rules over two groups, using the YAML features that break naive config readers: block scalars for multi-line PromQL, folded scalars for descriptions, Go template annotations with pipes, and keep_firing_for. Every expression references metrics that exist in this category's fixtures.
- yamlPrometheus Scrape Config — Relabelling and Federation (yaml)Three scrape jobs with the parts that actually matter: relabel_configs rewriting a target label with a capture group, metric_relabel_configs dropping the two unbounded labels from the cardinality fixture, honor_timestamps for the textfile collector and a federation job with a match[] selector.
- jsonDashboard JSON — Chained Template Variables (json)A dashboard driven by four template variables, one of which queries using the value of another — the chained dependency that must be resolved in order. Multi-select variables interpolate as regex alternations, which is why every query here uses =~ rather than =.
Generated by generation/observability.py. Free for any use, no attribution required — license.