Fluent Bit log ingestion does not support custom attributes beyond the log body #115

Closed
opened 2026-04-05 16:18:54 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @atippin1 on 2/6/2026

Is your feature request related to a problem? Please describe.
When ingesting logs into OneUptime via Fluent Bit / Fluentd, only the log body is currently stored and indexed. Any structured fields or metadata sent alongside the log (for example Kubernetes metadata like namespace, pod name, container name, labels, etc.) are discarded during ingestion.

This makes Kubernetes log ingestion significantly less useful, as logs cannot be filtered, grouped, or searched by common operational dimensions (namespace, workload, app, container). The only workaround today is to embed metadata into the log message string itself, which is brittle and limits structured querying.

Describe the solution you'd like
OneUptime should support ingesting and storing custom attributes when logs are sent via Fluent Bit / Fluentd.

At a minimum, one of the following should be supported:

Preserve the full JSON object sent by Fluent Bit / Fluentd as structured log attributes, not just the extracted log body
or

Allow users to explicitly define custom attributes (e.g. kubernetes.namespace_name, kubernetes.pod_name, kubernetes.container_name, labels, etc.) that are stored and indexed alongside the log body

This would allow logs to be queried, filtered, and grouped by Kubernetes metadata and other structured fields without embedding them into the log message.

Describe alternatives you've considered

Splitting logs into separate OneUptime services/ ingestion keys based on deployment or container name via Fluentd routing rules

These approaches work around the limitation but are obciously not ideal.

Additional context
While investigating this, it appears the Fluentd log ingestion path normalizes incoming payloads into strings only (e.g. extracting log, message, or stringifying objects), which discards structured fields by design.

Supporting structured log attributes would significantly improve Kubernetes and cloud-native observability use cases in OneUptime.

*Originally created by @atippin1 on 2/6/2026* **Is your feature request related to a problem? Please describe.** When ingesting logs into OneUptime via Fluent Bit / Fluentd, only the log body is currently stored and indexed. Any structured fields or metadata sent alongside the log (for example Kubernetes metadata like namespace, pod name, container name, labels, etc.) are discarded during ingestion. This makes Kubernetes log ingestion significantly less useful, as logs cannot be filtered, grouped, or searched by common operational dimensions (namespace, workload, app, container). The only workaround today is to embed metadata into the log message string itself, which is brittle and limits structured querying. **Describe the solution you'd like** OneUptime should support ingesting and storing custom attributes when logs are sent via Fluent Bit / Fluentd. At a minimum, one of the following should be supported: Preserve the full JSON object sent by Fluent Bit / Fluentd as structured log attributes, not just the extracted log body or Allow users to explicitly define custom attributes (e.g. kubernetes.namespace_name, kubernetes.pod_name, kubernetes.container_name, labels, etc.) that are stored and indexed alongside the log body This would allow logs to be queried, filtered, and grouped by Kubernetes metadata and other structured fields without embedding them into the log message. **Describe alternatives you've considered** Splitting logs into separate OneUptime services/ ingestion keys based on deployment or container name via Fluentd routing rules These approaches work around the limitation but are obciously not ideal. **Additional context** While investigating this, it appears the Fluentd log ingestion path normalizes incoming payloads into strings only (e.g. extracting log, message, or stringifying objects), which discards structured fields by design. Supporting structured log attributes would significantly improve Kubernetes and cloud-native observability use cases in OneUptime.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/oneuptime#115