Observability highlights

This list summarizes the most important enhancements in Observability 8.1.

Fleet and Elastic Agent Integrations previously required a superuser role. This required organizations to give users very broad access, which created more potential for security and operational risks.

Starting in 8.1, you can grant users a more limited set of Kibana privileges for Fleet and Integrations. No Elasticsearch privileges are required since Kibana updates Elasticsearch assets automatically. This will allow you to safely grant access to more users within your organization. The required Kibana privileges are All for the Fleet and Integrations feature.

Since many Integrations assets are shared across spaces, users need the Kibana privileges in all spaces. Also, we recommend giving users read-only access to Elastic Agent logs and metrics so they can monitor their agents and troubleshoot problems. We plan to introduce finer-grained controls in later releases.

Previously, if a user was not using Fleet, we installed several integrations by default. This over-complicated the setup experience by adding dashboards and visualizations that weren’t necessarily useful for all users. Even if the user had no agents installed, Fleet added default agent policies.

We now add integrations and agent policies only when users start using those features. This will offer users a cleaner experience when getting started. You can get started by adding an integration in Kibana, using the Fleet API, using Fleet preconfiguration, or running an Integrations Server in Elastic Cloud.

We continue to make improvements to our recently released experimental Observability alerting features. A rule count summary now appears alongside the “manage rules” button on the Alerts view providing a quick reference to counts of active, disabled, and muted rules. In addition, alert reason messages have been streamlined to be more consistent across rule types, concise, and crisp, while still conveying key information about the alert.

Alerts views are currently an experimental feature within Observability, and we encourage you to provide feedback via the Discuss link provided within the app.

We are pleased to announce that tail-based sampling has been made generally available (GA) in APM. Tail-based sampling enables users to optimize their sampling behavior by configuring sampling policies that determine how traces will be sampled.

Since sampling decisions are determined against policy criteria once a trace has completed, the risk of discarding important data is reduced.

You can configure tail-based sampling from the APM Integration Settings: