AxoSyslog and syslog-ng 4.4.0 release

AxoSyslog and syslog-ng 4.4.0 bring you exciting new features that enhance your on-premise and cloud-native logging and observability capabilities. Highlights: new destinations for Grafana Loki and Amazon S3, and advanced syslog-ng to syslog-ng log transfer. In this release, we introduce several significant features and bugfixes.

Packages are available for various platforms.
Our AxoSyslog project provides cloud-ready container images and Helm charts.

Logging Operator is a Kubernetes application to collect log data from pods and containers and route that to various logging backends. Logging Operator 4.4 also ships with AxoSyslog 4.4, with support for the new syslog-ng features already added. You can find examples on how to use these new features below, both for syslog-ng and the Logging Operator.

Let’s cover the highlights. For the in-depth details of every change, read the release notes on the GitHub Releases page. You can also find them in the AxoSyslog documentation.

Sending messages to Grafana Loki

AxoSyslog now supports sending log messages to Grafana Loki using the loki() destination. The messages are delivered via gRPC. The loki() AxoSyslog and syslog-ng destination offers extensive configuration options, including labels, worker settings, batch timeouts, and more.

Configuration in AxoSyslog and syslog-ng is done by simply adding a new destination:

destination d_loki {
  loki(
    url("loki.loki:8000")
    labels(
      "app" => "$PROGRAM",
      "host" => "$HOST",
    )
    workers(16)
    batch-timeout(10000)
    batch-lines(1000)
  );
};

The configuration in Logging Operator looks like this:

apiVersion: logging.banzaicloud.io/v1beta1
kind: SyslogNGOutput
metadata:
  name: loki
spec:
  loki:
    url: "loki.loki:8000"
    labels:
      "app": "$PROGRAM"
      "host": "$HOST"
    workers: 16
    batch-timeout: 10000
    batch-lines: 1000

Sending messages to Amazon S3

AxoSyslog now supports storing log messages in Amazon S3 objects using the s3() destination. This flexible driver comes with a range of configuration options, including compression, object rotation based on object size or timestamp, and more. You can customize these settings to fit your specific use case. An example configuration in AxoSyslog and syslog-ng looks like this:

destination d_s3 {
  s3(
    url("http://localhost:9000")
    bucket("syslog-ng")
    access-key("my-access-key")
    secret-key("my-secret-key")
    object-key("${HOST}/my-logs")
    template("${MESSAGE}\n")
  );
};

You can configure the S3 destination in Logging Operator like this:

apiVersion: logging.banzaicloud.io/v1beta1
kind: SyslogNGOutput
metadata:
  name: s3
spec:
  s3:
    url: "https://some-s3-compatible-endpoint:8088"
    bucket: "syslog-ng"
    access_key:
      valueFrom:
        secretKeyRef:
          name: s3
          key: access-key
    secret_key:
      valueFrom:
        secretKeyRef:
          name: s3
          key: secret-key
    object_key: "${HOST}/my-logs"
    template: "${MESSAGE}\n"

Transferring messages between syslog-ng instances via OTLP/gRPC

One of the standout features in syslog-ng 4.4.0 is the introduction of the syslog-ng-otlp() source and destination. This addition allows you to transfer the internal representation of log messages between syslog-ng instances using the OpenTelemetry protocol. Unlike the traditional syslog-ng() (ewmm()) drivers that rely on simple TCP connections, syslog-ng-otlp() leverages the OpenTelemetry protocol for efficient and reliable log message transmission.

Key benefits of syslog-ng-otlp() include scalability (via the workers() option), built-in application layer acknowledgement, support for Google service authentication (ADC or ALTS), and improved load balancing capabilities. While the performance is currently on par with ewmm(), we anticipate significant performance improvements in the near future.

To configure it in AxoSyslog and syslog-ng, add the syslog-ng-otlp() driver to both of your syslog-ng instances, like this:

Sending instance:

destination d_syslog_ng_otlp {
  syslog-ng-otlp(url("my-other-syslog-ng-instance:12346"));
};

Receiving instance:

source s_syslog_ng_otlp {
  syslog-ng-otlp(port(12346));
};

Other minor features

Among other minor improvements and bugfixes, we have also:

Added support for compression in the http() destination driver. You can enable it with content-compression() and accept-encoding(), possible values are identity, gzip and deflate.
Added namespace support for the systemd-journal() source driver.

Summary

This release takes syslog-ng another step closer to becoming a real cloud-native observability tool. We hope you’ll give it a try using the cloud-ready images of AxoSyslog, our syslog-ng distribution.

For the complete list of smaller changes and bugfixes, see the release notes. Stay tuned for more exciting features in the upcoming releases!

Thank you for everyone contributing with bug reports, feature requests, or pull requests. Feedback and any kind of contribution are always appreciated. Visit syslog-ng’s GitHub page or join Axoflow’s Discord server to reach out to us, or subscribe to the Axoflow newsletter to receive updates about syslog-ng and our observability and logging-related products.

For an overview on how our platform enhances syslog-ng based log collection with metrics, see the Metrics for syslog-ng based log management infrastructures blog post.