GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2024-03-15T00:20:27Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/301096Proposal: Add new metrics for pipelines and jobs and export metrics to OpenMe...2024-03-15T00:20:27ZBrie CarranzaProposal: Add new metrics for pipelines and jobs and export metrics to OpenMetrics format (ideally) or Prometheus<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
I am opening this feature proposal on behalf of a subscriber who would like to have a number of [new metric...<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
I am opening this feature proposal on behalf of a subscriber who would like to have a number of [new metrics exported by GitLab](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html). It would be ideal to export these metrics [in OpenMetrics format](https://openmetrics.io/) but Prometheus would be acceptable.
Today, the requester is retrieving the requisite data via the GitLab API and converting it to Prometheus format and sending it to Prometheus. The goal of this feature proposal is to remove the requirement for an approach like this, which adds overhead.
The idea is that these metrics will be reported as time series data. These metrics fall into these two categories:
- Pipelines
- Jobs
Here's a list of the desired metrics, by category:
#### Pipelines
**Metric 1: total number of pipelines per project**
Total number of pipelines / project / timeseries: 1hr, 4hr, 8hr, 24hr -> specific interval is flexible.
- Include project ID, project name, branch/tag/ref/kind, reference name, pipeline status (one of: created, waiting_for_resource, preparing, pending, running, success, failed, canceled, skipped, manual, scheduled)
- Optionally: include all project info made available via the [project API](https://docs.gitlab.com/ee/api/projects.html#get-single-project) in timeseries format. This would be a collection of how that information looked at the point in time when the data was collected.
**Metric 2: average number of pipelines per project per time series**
Avg number of pipelines / project / timeseries: 1hr, 4hr, 8hr, 24hr -> specific interval is flexible.
- Include project ID, project name, branch/tag/ref/kind, reference name, pipeline status (one of: created, waiting_for_resource, preparing, pending, running, success, failed, canceled, skipped, manual, scheduled)
- Optionally: include all project info made available via the [project API](https://docs.gitlab.com/ee/api/projects.html#get-single-project) in timeseries format. This would be a collection of how that information looked at the point in time when the data was collected.
**Metric 3: average pipeline duration per project per timeseries**
Avg pipeline duration / project / timeseries: 1hr, 4hr, 8hr, 24hr -> specific interval is flexible.
- Include project ID, project name, branch/tag/ref/kind, reference name, pipeline status (one of: created, waiting_for_resource, preparing, pending, running, success, failed, canceled, skipped, manual, scheduled)
- Optionally: include all project info made available via the [project API](https://docs.gitlab.com/ee/api/projects.html#get-single-project) in timeseries format. This would be a collection of how that information looked at the point in time when the data was collected.
#### Jobs
**Metric 4: Total number of jobs per project**
Total number of jobs / project / timeseries: 1hr, 4hr, 8hr, 24hr -> specific interval is flexible.
- Include job status
- Include project ID, project name, branch/tag/ref/kind, reference name, pipeline status (one of: created, waiting_for_resource, preparing, pending, running, success, failed, canceled, skipped, manual, scheduled)
**Metric 5: Average job duration per project**
Avg job duration / project / timeseries: 1hr, 4hr, 8hr, 24hr -> specific interval is flexible.
- Include job status
- Include project ID, project name, branch/tag/ref/kind, reference name, status of pipeline that the job is running in (one of: created, waiting_for_resource, preparing, pending, running, success, failed, canceled, skipped, manual, scheduled)
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
-->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/326245Add project badges to operations dashboard2021-04-06T00:07:58ZJosh MillerAdd project badges to operations dashboard### Proposal
The Operations Dashboard should incorporate project badges. Badges are everything a dashboard could want: Helpful deep links with tiny graphical "status" colors for a variety of project-specific metrics.### Proposal
The Operations Dashboard should incorporate project badges. Badges are everything a dashboard could want: Helpful deep links with tiny graphical "status" colors for a variety of project-specific metrics.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/299203Docs - product feedback: Health checks failing on Load balancer - whats the fix2021-01-20T10:11:59ZGaurav GawandeDocs - product feedback: Health checks failing on Load balancer - whats the fixneed more inputs on the load balancer setup, after performing all the steps for Gitlab install on AWS, the health checks keep failing, the document need to be update to use new load balancer or need to provide more updates on how to trou...need more inputs on the load balancer setup, after performing all the steps for Gitlab install on AWS, the health checks keep failing, the document need to be update to use new load balancer or need to provide more updates on how to troubleshoot health check failures on load balancerhttps://gitlab.com/gitlab-org/gitlab/-/issues/34891Allow alerts to connect to other observability artifacts via a link formatter2020-08-14T11:05:27ZKenny Johnstonkencjohnston@gitlab.comAllow alerts to connect to other observability artifacts via a link formatter### Problem to solve
When passing relevant information from various observability sources (logs, metrics, errors, traces) in an alert, I have to go manually search for those other relevant sources in order to view and interact with them...### Problem to solve
When passing relevant information from various observability sources (logs, metrics, errors, traces) in an alert, I have to go manually search for those other relevant sources in order to view and interact with them.
### Intended users
* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
Include ability to easily interpret common IDs from other observability tools when passed in alerts and generate links directly to their appropriate systems when creating incidents.
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?-->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. -->
### Testing
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
### What is the type of buyer?
<!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
### Links / referencesBacklog