We are happy to announce that Logging operator version 4.7.0 has arrived! The following are the highlights and main changes of Logging operator 4.7. For a complete list of changes and bugfixes, see the Logging operator 4.7 releases page and the Logging operator 4.7 release blog post.

Minor breaking change for Fluentd

When using the Fluentd aggregator, Logging operator has overridden the default chunk_limit_size for the Fluentd disk buffers. Since Fluentd updated the default value to a much saner default, Logging operator won’t override that to avoid creating too many small buffer chunks. (Having too many small chunks can lead to too many open files errors.)
This isn’t an intrusive breaking change, it only affects your deployments if you intentionally or accidentally depended on this value.

JSON output format for Fluentd

In addition to the default text format, Fluentd can now format the output as JSON:

spec:
  fluentd:
    logFormat: json

Disk buffer support for more outputs

Enabling disk buffers wasn’t available for some of the outputs, this has been fixed for: Gelf, Elasticsearch, OpenObserve, Amazon S3, and Splunk HEC.

Compression support for Elasticsearch

The Elasticsearch output of the Fluentd aggregator now supports compressing the output data using gzip. You can use the compression_level option to set default_compression, best_compression, or best_speed. By default, compression is disabled.

Protected ClusterOutputs for Fluentd

By default, ClusterOutputs can be referenced in any Flow. In certain scenarios, this means that users can send logs from Flows to the ClusterOutput, possibly spamming the output with user logs. From now on, you can set the protected flag for ClusterOutputs and prevent Flows from sending logs to the protected ClusterOutput.

ConfigCheck settings for aggregators

You can now specify configCheck settings globally in the Loggings CRD, and override them if needed on the aggregator level in the Fluentd or SyslogNG CRD.

Limit connections for Fluent Bit

You can now limit the number of TCP connections that each Fluent Bit worker can open toward the aggregator endpoints. The max_worker_connections is set to unlimited by default, and should be used together with the Workers option (which defaults to 2 according to the Fluent Bit documentation). The following example uses a single worker with a single connection:

kind: FluentbitAgent
spec:
  network:
    maxWorkerConnections: 1
  syslogng_output:
    Workers: 1

Summary

As you can see, Logging operator 4. brings you interesting new features. We are especially happy to see so many contributions from the community, many thanks to all of you! You can find the Logging operator release on our GitHub page.

To download the latest Docker image:

docker pull ghcr.io/kube-logging/logging-operator:4.7.0

To install the latest release using Helm:

helm install logging-operator oci://ghcr.io/kube-logging/helm-charts/logging-operator --version=4.7.0

Give it a try!

Follow Our Progress!

We are excited to be realizing our vision above with a full Axoflow product suite.

Request a Demo

  • A zero-commitment demo of the Axoflow Platform.
  • A chance to see how optimized telemetry can improve your observability operations and reduce costs.

    I have read and agree to the terms & conditions.

    Subscribe for Product News

    • Technology oriented content only.
    • Not more than 1-3 posts per month.
    • You can unsubscribe any time.

    By signing up you agree to receive promotional messages
    according to Axoflow's Terms of Services.