Product news and technical notes

Version 5.24 of our applications, configurations, and Collectord is now available. In this blog post, we will cover some highlights of the release.

Version 5.23 of our applications, configurations, and Collectord are now available. In this blog post, we will cover some highlights of the release.

Version 5.22 of our applications, configurations, and Collectord is now available. In this blog post, we will cover some highlights of the release.

Version 5.21 of our applications, configurations, and Collectord is now available. In this blog post, we will cover some highlights of the release.

Version 5.20 of our applications, configurations, and Collectord is now available. In this blog post, we will cover some highlights of the release.

Large teams might have different requirements for the log management system. Some teams might prefer to use Elasticsearch or OpenSearch for log management. In this version of Collectord, we have added support for sending logs to Elasticsearch and OpenSearch.

You can install Collectord with Elasticsearch or OpenSearch support and run it in the same cluster as Collectord for Splunk. In that case, you can configure Collectord to send logs to both Splunk and Elasticsearch or OpenSearch.

Collectord version 5.20 and later supports sending logs to Elasticsearch and OpenSearch.

The main focus of this release was to implement feature requests that we received from our users and various configuration updates for the latest versions of Kubernetes, OpenShift and Docker.

The main focus of this release was support for clusters using cgroupv2 and support for a different memory usage calculation.

This release includes a lot of usability improvements for troubleshooting and configuring Collectord, and monitoring your clusters.

We have been working on an interesting case with one of our customers. Every role in Splunk has a defined disk limit, and by default the user role has only 100MB.

We are always cautious about how much data we bring to Splunk Dashboards and limit everything to make sure our applications can handle large clusters in our applications.

One search that was causing an issue was a search used to populate filters in various places of our “Monitoring OpenShift” application. Depending on the number of nodes, namespaces and labels, we expect this search to return many thousands of values, but should not take a lot of disk space.