-
Story
-
Resolution: Unresolved
-
Major
-
None
-
13
-
False
-
-
False
-
-
-
OBSDOCS (Mar 4 - Mar 25) #250
Information from ptsiraki@redhat.com in Slack:
The EPIC itself is more about what it takes to enable and operate Loki for OpenTelemetry logs once Cluster-Logging-Operator supports this on the collector side (currently only a preview exist). The feature set to be documented though is:
- Enable efficient support in LokiStack: Using the new V13 object storage format. Inform the docs reader that we will shoot out a warning alert that he/she needs to upgrade.
- Operate efficiently: a) We enable now by default automatic stream sharding (for further tuning the new desiredRate option to be documented. b) We support block queries per tenant.
I believe from a docs standpoint the OpenTelemetry support in OpenShift Logging needs to be documented considering three EPICs:
- Collection side: https://issues.redhat.com/browse/LOG-4225 and https://issues.redhat.com/browse/LOG-2827
- Storage side: https://issues.redhat.com/browse/LOG-4538
if you trace the parent link fields you will end up in this request product outcome: https://issues.redhat.com/browse/OBSDA-499
It would be great if we can expand Calvin's OTEL work (with the fixed OTEL setup) to make use of Loki's structured metadata API in vector. This would compose the full picture and we could have an efficient tech-preview.
Same thread, from rhn-engineering-aconway :
OTEL syntax can mainly be linked to the OTEL docs but need to explain how we enable it on the collector, special config on the store if there is any and perhaps an example showing the same log record in ViaQ vs. OTEL to make it easier to picture. There also will be interactions with other features that mention field names in configuration (filters in particular, but also outputs that can use field names as tenant-ids etc) - we need to decide on which name(s) are used ViaQ and/or OTEL. That's not finally decided yet, but to bear in mind.