Service-Level Log Filtering Independent of Ingestion Keys #79

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

Originally created by @atippin1 on 2/17/2026

Is your feature request related to a problem? Please describe.
Currently, OneUptime enforces a 1:1 relationship between ingestion keys and services. When an ingestion key is created, a corresponding service is automatically created, and all logs ingested via that key are associated with that service. This creates significant friction in multi-application environments, particularly when using log aggregators like Fluentd in Kubernetes:

  • A separate ingestion key must be created for each application/service
  • Managing multiple ingestion keys in Fluentd configuration is cumbersome and error-prone
  • There's no way to dynamically route logs to services based on log attributes (e.g., Kubernetes labels, application tags)
  • This limits flexibility in how services are logically defined and organized

Describe the solution you'd like
Decouple service definition from ingestion keys by allowing users to define service membership through log filtering rules:

  • Service declaration: Users create services independently of ingestion keys
  • Filter-based log routing: Each service can define filtering rules to match logs based on ANY custom attribute (e.g., kubernetes.labels.app: "oneuptime", environment tags, namespace, etc.)
  • Reuse existing filtering UI: Leverage the existing log filtering functionality already present in the Logs section, but apply it at the service definition level to determine which logs belong to which service
  • Single ingestion key: Users can send all logs through a single ingestion key, and OneUptime routes them to the appropriate services based on the defined filters

Benefits:

  • Granular control over service boundaries (e.g., "this service = all logs from this Kubernetes deployment")
  • Simplified Fluentd/log aggregator configuration (one ingestion key instead of many)
  • More natural alignment with cloud-native architectures where services are defined by labels/tags

Describe alternatives you've considered
The current workaround is creating multiple ingestion keys—one per application/deployment—and configuring the log aggregator (e.g., Fluentd) to use different keys based on the source. This works but is maintenance-heavy and doesn't scale well.
Additional context
This feature would be particularly valuable in Kubernetes environments where applications are already tagged with labels (e.g., app, environment, version). Being able to map those labels to OneUptime services without managing a proliferation of ingestion keys would significantly improve the user experience.
The filtering logic already exists in the OneUptime UI (Logs section), so this would extend that capability to service-level log routing.

*Originally created by @atippin1 on 2/17/2026* **Is your feature request related to a problem? Please describe.** Currently, OneUptime enforces a 1:1 relationship between ingestion keys and services. When an ingestion key is created, a corresponding service is automatically created, and all logs ingested via that key are associated with that service. This creates significant friction in multi-application environments, particularly when using log aggregators like Fluentd in Kubernetes: - A separate ingestion key must be created for each application/service - Managing multiple ingestion keys in Fluentd configuration is cumbersome and error-prone - There's no way to dynamically route logs to services based on log attributes (e.g., Kubernetes labels, application tags) - This limits flexibility in how services are logically defined and organized **Describe the solution you'd like** Decouple service definition from ingestion keys by allowing users to define service membership through log filtering rules: - Service declaration: Users create services independently of ingestion keys - Filter-based log routing: Each service can define filtering rules to match logs based on ANY custom attribute (e.g., kubernetes.labels.app: "oneuptime", environment tags, namespace, etc.) - Reuse existing filtering UI: Leverage the existing log filtering functionality already present in the Logs section, but apply it at the service definition level to determine which logs belong to which service - Single ingestion key: Users can send all logs through a single ingestion key, and OneUptime routes them to the appropriate services based on the defined filters **Benefits:** - Granular control over service boundaries (e.g., "this service = all logs from this Kubernetes deployment") - Simplified Fluentd/log aggregator configuration (one ingestion key instead of many) - More natural alignment with cloud-native architectures where services are defined by labels/tags **Describe alternatives you've considered** The current workaround is creating multiple ingestion keys—one per application/deployment—and configuring the log aggregator (e.g., Fluentd) to use different keys based on the source. This works but is maintenance-heavy and doesn't scale well. Additional context This feature would be particularly valuable in Kubernetes environments where applications are already tagged with labels (e.g., app, environment, version). Being able to map those labels to OneUptime services without managing a proliferation of ingestion keys would significantly improve the user experience. The filtering logic already exists in the OneUptime UI (Logs section), so this would extend that capability to service-level log routing.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/oneuptime#79