- Provide a new output option to forward any logs to an existing Loki cluster with the following configuration options:
- Tenant as endpoint URI path. One tenant per OutputRef
- Server-side TLS support only
- Translation of fluentd fields to Loki labels..
- Changing or adopting the new Loki output into our "DEFAULT" pipeline.
- Us supporting Loki.
- No custom field translation
- No basic authentication
Loki is becoming a hot topic pretty quick. We already have a handful (and more) customers that are really interested in adopting it themselves and we also plan to adopt it as an alternative to our current storage engine - the Elastic stack. We need to make sure that we let users easily integrate Loki into our log pipeline as well as our ability to switch the "DEFAULT" pipeline to Loki in the future.
- Verify that any log messages from a particular input source (infra, app, and audit) are forwarded and present inside a remote Loki (can run locally, but the important part is that we standup a standalone Loki cluster).
- Verify that we translate Loki configuration into a valid Fluentd config.
- Verify that instead of using fields for docker., kubernetes., pipeline_metadata.*, we translate them into labels.
- Documentation describing what is (is not ) configurable.
- With the new log forwarding API, we are now have the ability to introduce other endpoints to which we forward logs without compromising the supportability of OpenShift Logging.
- Loki is another promising endpoint