Open-Source Observability · kube-logging

logging-operator

Logging Operator is a Kubernetes-native project that automates deployment and management of logging pipelines using Fluent Bit collectors and Fluentd or syslog-ng forwarders. It enables declarative log routing, filtering, and multi-destination output through Kubernetes Custom Resources.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/kube-logging/logging-operator

1.7k

GitHub stars

364

Forks

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	kube-logging/logging-operator
Owner	kube-logging
Primary language	Go
License	Apache-2.0 — OSI-approved
Stars	1.7k
Forks	364
Open issues	43
Latest release	6.7.0 (2026-06-16)
Last updated	2026-07-07
Source	https://github.com/kube-logging/logging-operator

What logging-operator is

A Go-based Kubernetes operator that deploys Fluent Bit DaemonSets for log collection, forwards logs through Fluentd or syslog-ng with TLS encryption, and manages routing via Flow/Output CRDs supporting namespace isolation and cluster-wide policies. Integrates with major log backends (S3, GCS, Elasticsearch, Loki).

Quickstart

Get the logging-operator source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/kube-logging/logging-operator.git2cd logging-operator3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Multi-tenant Kubernetes clusters with namespace isolation

Native label selectors and namespace-scoped Flow/Output CRDs allow teams to define logging behavior independently while maintaining cluster-wide governance through ClusterFlow/ClusterOutput.

Declarative log pipeline as code

Embed logging configuration directly in application Helm charts using Logging operator CRDs, eliminating manual pipeline setup and ensuring logs follow application deployments.

Hybrid multi-destination logging

Route the same logs to multiple outputs (Elasticsearch, S3, Loki, syslog) with different filters and transformations per destination using multiple Flow definitions.

Implementation considerations

Fluent Bit runs on every node as a DaemonSet; verify node resource headroom (CPU/memory) for log collection agents across your cluster size.
Choose between Fluentd and syslog-ng forwarders early; CRDs are specific to each and cannot be mixed in the same cluster (separate Logging resources required).
Plan TLS certificate rotation and secret management for encrypted log transport; operator expects pre-configured secrets for authentication.
Namespace isolation requires explicit RBAC and careful ClusterOutput/ClusterFlow governance if `allowClusterResourcesFromAllNamespaces` is enabled.
Validate log output destinations are accessible from your cluster network; operator does not automatically retry or buffer on output failure.

When to avoid it — and what to weigh

Need serverless/managed logging without cluster overhead — Logging Operator requires cluster resources (Fluent Bit DaemonSet on every node, Fluentd/syslog-ng forwarder pods). Not suitable if you want fully external, zero-footprint logging.
Require non-Fluentd/syslog-ng log collectors — Operator is hardcoded to Fluent Bit for collection. If your environment mandates Logstash, Vector, or other collectors, this operator will not support them.
Minimal cluster complexity required — Adding operator, CRDs, DaemonSets, and forwarder replicas increases cluster resource consumption and operational surface. Simple static logging may not justify the overhead.
Air-gapped or restricted container registries — Requires pulling operator, Fluent Bit, and Fluentd/syslog-ng images. Not explicitly documented how to mirror or cache these in offline environments.

License & commercial use

Licensed under Apache License 2.0. Permissive OSI-approved open-source license. Copyright held by Cisco Systems, Inc. and Banzai Cloud, Inc. as of 2021–2023.

Apache 2.0 permits commercial use, modification, and distribution with minimal restrictions (retain copyright notice, disclose changes, no warranty/liability). No explicit commercial support model documented in provided data; review vendor support offerings separately if required.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Strong
License clarity	Clear
Deployment complexity	Moderate
DEV.co fit	Good
Assessment confidence	High

Security considerations

Operator documentation states logs are transferred on 'authenticated and encrypted channels' (TLS), but specific implementation details (TLS version, cipher strength, certificate validation) are not provided in the data. Recommend: verify TLS configuration in Fluent Bit and forwarder output plugins, ensure Secrets are encrypted at rest in etcd, audit RBAC for operator and collector service accounts, validate network policies restrict log traffic paths.

Alternatives to consider

Fluent Operator (Fluent Community)

Community-driven operator focusing on Fluent Bit and Fluentd; lighter footprint, stronger plugin ecosystem alignment, but fewer native Kubernetes abstractions.

Prometheus + Loki (Grafana)

Purpose-built for cloud-native logging/metrics; superior query language and UI, but requires separate metrics stack and different mental model than declarative log routing.

Datadog/New Relic Kubernetes agents

Managed SaaS logging with built-in APM; eliminates on-cluster log forwarder overhead, but vendor lock-in, cost scaling with volume, and less control over log processing.

Software development agency

Build on logging-operator with DEV.co software developers

Logging Operator simplifies log collection and routing at scale. Start with the quickstart guides or contact our team to evaluate fit for your cluster and logging requirements.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

fluent-operator fluentd logr

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Observability DevOps Cloud Deployment Enterprise Software Talk to DEV.co

logging-operator FAQ

Can I use Logging Operator with an existing Fluentd or syslog-ng deployment?

The operator manages its own Fluentd/syslog-ng forwarder instances; running pre-existing instances in the same cluster requires careful namespace/RBAC isolation. Recommend single operator instance per cluster.

Does Logging Operator support log sampling or rate-limiting to reduce output volume?

Not directly stated in provided data. Fluentd filters support sampling; review Fluentd/syslog-ng plugin documentation for rate-limiting capabilities. Operator does not abstract this feature.

What happens if a log output becomes unreachable?

Not explicitly documented. Fluentd/syslog-ng may buffer or drop logs depending on plugin configuration; operator does not provide automatic retry or circuit-breaker logic. Test output resilience before production.

Can I define Flow rules across namespaces?

Flow is namespaced; ClusterFlow is cluster-wide. Namespaced users can reference ClusterOutput but cannot modify it. Cross-namespace log routing requires ClusterFlow or namespace-shared Output references.

Work with a software development agency

Need help beyond evaluating logging-operator? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source observability integrations — and maintain them long-term.

Ready to automate your Kubernetes logging?

Logging Operator simplifies log collection and routing at scale. Start with the quickstart guides or contact our team to evaluate fit for your cluster and logging requirements.

Talk to DEV.co Schedule a Consultation