Release notesV1.5

Version 1.5 release notes

The Grafana Enterprise Logs (GEL) team is excited to announce the release of GEL 1.5.

GEL 1.5 is built off of Loki 2.6.1, so it inherits all the features, enhancements, and bug fixes of the upstream project. Refer to the Loki v2.6 release notes for more information.

For the full list of features, enhancements and bug fixes in GEL 1.5, please see the Changelog.

Features and enhancements

  • Cross-tenant query federation: GEL 1.5 inherits Loki 2.6’s new cross-tenant query capability, which allows users to query against multiple tenants. This new capability is integrated with GEL’s access control model, which means that any entity trying to execute a cross-tenant query must have logs:read access for all tenants it is requesting to query. For information on how to set up Grafana to execute cross-tenant queries, see Create a Grafana data source. For an example query request, see the Loki HTTP API reference.

  • Targeted log line deletion: GEL 1.5 inherits Loki 2.6’s new deletion capabilities, which make it possible to delete specific log lines matching a user-defined query. This new capability is integrated with GEL’s access control model, which means that any entity trying to perform a delete must have logs:delete access to the tenant whose data it is trying to delete. For an example delete request, see the Loki HTTP API reference.

Upgrade considerations

Check the upgrade considerations for Loki 2.6. There are no additional GEL-specific upgrade considerations.

Bug fixes

1.5.2 bug fixes

  • GEL now properly exposes CPU metrics on all components. Previously, GEL only exposed these metrics on its admin-api component.

1.5.1 bug fixes

  • Fixed a bug that caused all calls to GEL’s Node API to fail with a 404 error.

1.5.0 bug fixes

  • GEL now returns a generic error message to clients such as the Grafana Agent upon internal errors during authentication. The detailed error message is now written to the GEL logs rather than being returned to the client.
  • GEL now properly follows the chain of resolving mechanisms for validating AWS credentials. Previously, if a user did not specify their AWS credentials using the access_key and secret_access_key fields in their config.yaml file, GEL would fail to start, rather than checking other possible credential locations (such as environment variables and AIM roles. This fix is only relevant for users who use AWS S3 as their object storage backend for GEL.