fluentd
logging
namespace
configuration
Kubernetes

How to get specific namespace for log fluentd

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

Introduction

In Kubernetes, Fluentd usually learns a pod's namespace from Kubernetes metadata attached to the log record. So if you want logs from one specific namespace, the normal solution is to enrich records with Kubernetes metadata and then filter on namespace_name.

Where the Namespace Comes From

Container log lines from /var/log/containers often include pod identity in the filename, and Fluentd can enrich those records using the Kubernetes metadata filter.

Once enrichment is working, a record typically has fields like:

  • 'kubernetes.namespace_name'
  • 'kubernetes.pod_name'
  • 'kubernetes.container_name'

That is the field you usually filter on.

Typical Fluentd Flow in Kubernetes

The usual pipeline is:

  1. tail container logs
  2. parse the log line
  3. enrich with Kubernetes metadata
  4. filter for the namespace you want
  5. route to the output

A simplified configuration looks like this:

conf
1<source>
2  @type tail
3  path /var/log/containers/*.log
4  pos_file /var/log/fluentd-containers.log.pos
5  tag kubernetes.*
6  <parse>
7    @type json
8  </parse>
9</source>
10
11<filter kubernetes.**>
12  @type kubernetes_metadata
13</filter>
14
15<filter kubernetes.**>
16  @type grep
17  <regexp>
18    key $.kubernetes.namespace_name
19    pattern ^production$
20  </regexp>
21</filter>

This keeps only records from the production namespace.

Route Different Namespaces Differently

Instead of dropping other namespaces, you can retag or route them to separate outputs.

For example, after metadata enrichment you might send production logs to one destination and everything else to another.

That pattern is common when different teams own different namespaces.

Make Sure Metadata Enrichment Actually Works

If the namespace_name field is missing, the filter will never match. In that case, debug the metadata stage first.

Common requirements include:

  • Fluentd running with access to Kubernetes API metadata
  • correct RBAC permissions for pod and namespace lookups
  • logs being tailed from the expected container log path

If the metadata plugin cannot resolve pod information, namespace filtering becomes impossible because the field never appears.

Inspect a Sample Record

Before writing a strict grep filter, inspect one processed record to confirm the exact field path.

Depending on plugins and parsing, the namespace may appear under a slightly different structure. Do not guess the key name if you can verify it directly.

Fluent Bit Versus Fluentd

Some clusters use Fluent Bit as the node agent and Fluentd downstream as the aggregator. The idea is the same: enrich with Kubernetes metadata, then filter on namespace. Just make sure you know which component actually holds the metadata field when writing the filter rules.

Useful Filtering Variants

Keep one namespace exactly:

conf
pattern ^production$

Keep multiple namespaces:

conf
pattern ^(production|staging)$

Drop one noisy namespace instead of selecting one:

conf
1<exclude>
2  key $.kubernetes.namespace_name
3  pattern ^kube-system$
4</exclude>

Verifying the Filter Works

A practical way to validate the configuration is to send filtered records to a simple stdout output first.

conf
<match kubernetes.**>
  @type stdout
</match>

Once you confirm that only the intended namespace is passing through, switch the match block to Elasticsearch, OpenSearch, S3, or your normal log destination. This small test step prevents a lot of blind debugging when the issue is actually in the filter path rather than the final output plugin.

Common Pitfalls

A common mistake is trying to filter on namespace before Kubernetes metadata has been attached to the record.

Another mistake is using the wrong field path. namespace and namespace_name are not always interchangeable.

Developers also often forget that RBAC issues can silently prevent metadata enrichment, making the filter look broken even though the real problem is access to the Kubernetes API.

Summary

  • In Kubernetes, Fluentd usually gets namespace information from Kubernetes metadata enrichment.
  • Filter on kubernetes.namespace_name after metadata is attached.
  • Use a grep filter to keep or exclude specific namespaces.
  • Verify the actual record structure before writing the filter.
  • If namespace filtering fails, debug metadata enrichment and RBAC first.

Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.