-
Spike
-
Resolution: Done
-
Blocker
-
None
-
None
-
False
-
-
False
-
NEW
-
NEW
-
Release Note Not Required
-
-
-
Log Collection - Sprint 245, Log Collection - Sprint 246, Log Collection - Sprint 247, Log Collection - Sprint 248
Summary
Investigate and design custom tenant specification for ClusterLogForwarder so that administrators of various outputs control how their data is organized. Many of the existing CLF outputs support a 'tenant' concept: index, log group, etc. Administrators should be allowed to modify the default tenant choice for any output where it is applicable with the exception of 'default' lokistack and elasticsearch.
Administrators should additionally be able to base the tenant upon other fields (similar to elsewhere in the api):
- static value
- kubernetes.name
- kubernetes.namespace
- kubernetes.labels.<key>
Acceptance Criteria
- Document the outcome of this effort to include:
- API Proposal
- Implementation Details
- Possible Example
- Test plan
- Create Impl cards if needed
- General consensus and approval of design by logging team
- Enhancement proposal (if applicable) in https://github.com/openshift/enhancements
Notes
- Consider the need to define a "logType" for the receiver inputs and how that maps to a tenant.
- Do we allow the user to define a new "logtype"?
- How do admins classify incoming logs or do they define one that is well-known?
- Ref structuredKey from Elasticsearch outputs