Epic Goal

• Evaluate the feasibility of having the oc CLI collect a set of metrics that would help support and engineering troubleshoot customer cases.

Why is this important?

• Metrics provide great insights that help debug customer cases, however, when we want to look at certain metrics we always have ask to the support for those. Inherently support team will then relay this request to the customer which will most of the time just share a screenshot of the result. Furthermore, usually as a follow-up, it's frequent for us (engineering) to have to request more queries which becomes a burden to not only the support organization but more importantly to the customer.
• We (engineering) should have as much information as possible to debug customer cases without having to bother the customer and other teams for pieces of information.

Scenarios

1. ...

Acceptance Criteria

The following question should be answered in order for this issue to be complete

• How would this work with the mustgather command? Would the metrics be collected automatically would we pass a flag and a list of metrics?
• How would the CLI get the metrics?
• Come up with a list of interesting metrics that would be nice to have in the majority of customer cases
• How are we going to consume the output?

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>