Uploaded image for project: 'OpenShift Logging'
  1. OpenShift Logging
  2. LOG-946

Integrate a native log exploration view into the OpenShift Console

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Duplicate
    • Icon: Minor Minor
    • None
    • None
    • None
    • None
    • New native Exploration UI
    • False
    • False
    • To Do
    • OBSDA-7 - Adopting Loki as an alternative to Elasticsearch to support more lightweight, easier to manage/operate storage scenarios
    • OBSDA-7Adopting Loki as an alternative to Elasticsearch to support more lightweight, easier to manage/operate storage scenarios
    • Undefined

      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?

            Unassigned Unassigned
            cvogel1 Christian Heidenreich (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: