Goals

• Allow users to query logs directly (grep-like experience comes up pretty often). The engine should only return logs that a users has access to. OpenShift Console currently only supports projects/namespaces as a way to separate between tenants. Here "admins" should have access to all logs as before, but "developers" only look at logs from a single namespace.
  • Ability to further filter logs easily by, for example, selecting a specific timeframe.
  • Ability to export current result into a TEXT or CSV file.
  • Ability to visualize query result into a graph.
  • Ability to "share" dashboards/graphs either with "all" or "project/namespace". By default it's always only for yourself.
• Provide critical log information on various different views inside the console without the necessity to explicitly query them. The goal is to provide context information immediately to avoid another step for admins or devs and show them the right information at the right place (think about the alert page or inside the topology).

Non-Goals

Motivation

Enabling observability is a key aspect of our investment in different areas. One is to bring all experiences for helping SREs to troubleshoot problems into a single, native experience inside the OpenShift Console.

Currently, we have multiple, different experiences by providing separate tooling for each and every signal. For metrics we have Prometheus UI and Grafana and for logs Kibana. For the former, we have already successfully started to bring the most critical views into the Console and we want to do the same for logs. That will allow us to be much more flexible on how we present data back so that SREs can easily correlate information in the future without looking at different UIs.

Some important points to consider:

• A unified experience inside the OpenShift Console makes future investments to improve the discoverability of meaningful data much easier by looking at the complete picture holistically (think seeing all important logs attached to an alert).
• Not using third party UIs will make our entire auth mechanism easier since there is only on access point.
• When we introduce a new, improved storage with LOG-704, we have to have some nice UI since we can't use Kibana anymore.
• Minimizes deployment size and complexity of the Logging stack.

Alternatives

Acceptance Criteria

Risk and Assumptions

Documentation Considerations

Open Questions

Additional Notes

Why is this important?