DESCRIPTION

The Loki sizes are tested and supported for a log retention of 30 days or less as it's indicated in the Loki Statement of Purpose task and in the Support Documentation section, Loki and the Logging stack are for short-term log store and the maximum supported/tested are 30 days.

Related to the previous sentence, two issues are present:

ISSUE 1

In the Documentation section "Enabling stream-based retention with Loki" is read the  sentence below.

This is not for managing the retention for stored logs. Global retention periods for stored logs to a supported maximum of 30 days is configured with your object storage.

This sentence is not correct, probably, a misunderstanding of the maximum of days that the Loki sizes were tested and they are supported by Red Hat, as it doesn't exist a default configured retention and the stored logs and those logs are never deleted at least that configured a lifecycle policy in the backend storage and/or in Loki as it's possible to read in the same documentation link  "Enabling stream-based retention with Loki". This is already said:

If there is no retention period defined on the s3 bucket or in the LokiStack custom resource (CR), then the logs are not pruned and they stay in the s3 bucket forever, which might fill up the s3 storage.

ISSUE 2

The 30 days limitation is maximum number of days that the Loki Sizes were tested and supported, exceeding this log retention could lead to the Red Hat Loki not working as expected having performance impact.

Then, the Documentation should say pretty clear that exceeding the 30 days could lead to performance issues as not tested.

*NOTE*: The RFE https://issues.redhat.com/browse/OBSDA-383 is requesting to test and support Loki for 3 months of log retention