Incident Management: Embed Prometheus metrics in issues
### Problem to solve
When a user is collaborating with team members to solve an incident and restore services, they need a way to easily attach metrics to incidents to share visuals. This is similar to how users can link to merge requests, commits, epics, etc. This solves three problems:
1. Enables collaboration and knowledge transfer
1. Enables users to have effective post incident reviews
1. Makes future remediation faster - users may refer to historical incidents in order to solve a current incident.
### Supporting Research
A full summary of UX research can be found [here](https://gitlab.com/gitlab-org/ux-research/issues/223). Relevant findings are summarized below. Interviewees included 5 SMB customers and 4 Enterprise customers.
* 4/5 SMB stated that most incidents were missing the "why" (https://gitlab.com/gitlab-org/uxr_insights/issues/507, https://gitlab.com/gitlab-org/uxr_insights/issues/509)
* 3/5 SMB customers stated they needed more info from the monitoring tool (https://gitlab.com/gitlab-org/uxr_insights/issues/511)
* 4/4 Enterprise customers stated they needed to log into multiple tools to identify the problem (https://gitlab.com/gitlab-org/ux-research/issues/223)
### Intended users
**On-call engineer**
[Sasha the Software Developer](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
[Devon the DevOps Engineer](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
[Sidney the Systems Administrator](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
### Further details
This work supports the [Incident Management Vision](https://about.gitlab.com/direction/monitor/debugging_and_health/incident_management/)
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
Allow users to generate a a shareable link directly from charts on the metrics dashboard under the Operations section of a project. The user should be able to set a time frame for the data using the existing time period drop-down at the top of the dashboard. The specified time frame will be included in the URL. When the user pastes the link in the description of an issue and clicks save, the specific chart will unfurl, embedded in the issue. The chart will be interactive. If the users wants to change the time-frame, they can do so manually by editing the URL of the embed link. Charts will unfurl for all time frames in which Prometheus data is retained - dependent on installation.
#### User Journey 1:
Issue is automatically created when an alert is triggered and the DevOps team has configured issues to automatically create using a template that includes a link to the metrics dashboard so that CPU, Memory, and throughput metric charts are automatically embedded.
#### User Journey 2:
Devon is on-call and actively working an incident. He and his team are not co-located as it is the middle of the night. They have a zoom call running as they work to resolve the outage. Devon digs into metrics and logs around the time their web app went down and identifies a spike in CPU. While his colleague is sorting through logs, he shares the chart to the in-progress incident to share his learnings and context with his team. Additionally, the spike in CPU will be the first event in the timeline that gets reviewed the following day at the post-incident review his team tries to have following each incident.
epic