Category Direction - Metrics

1. You are here:
2. Category Direction - Metrics

• Metrics
  • Introduction and how you can help
• Background
• Target audience and experience
• What's Next & Why
• Maturity Plan
• Competitive Landscape
• Analyst Landscape
• Top Customer Success/Sales Issue(s)
• Top Customer Issue(s)
• Top Internal Customer Issue(s)
• Top Vision Item(s)

Metrics

Stage	Monitor
Maturity	Viable

Introduction and how you can help

Thanks for visiting this category strategy page on Metrics in GitLab. This category belongs to and is maintained by the APM group of the Monitor stage.

This strategy is a work in progress, and everyone can contribute:

• Please comment and contribute in the linked issues and epics on this page. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
• Please share feedback directly via email, Twitter, or on a video call. If you're a GitLab user and have direct knowledge of your Metrics usage, we'd especially love to hear your use case(s).

Background

Metrics help users understand how their applications are performing, and if they are healthy. Examples of common metrics include response metrics like latency and error rate, system metrics like cpu and memory consumption, as well as any other type of telemetry desired.

Actions and insights can then be derived from these metrics like setting Service Levels, Error Budgets, as well as triggering alerts.

Target audience and experience

Metrics are an important tool for all users across the DevOps spectrum. From pure developers who should understand the performance impact of changes they are making, as well as pure operators who are responsible for keeping production services online.

The target workflow includes a few important use cases:

1. Configuring GitLab to monitor an application should be as easy as possible. To the degree possible given the environment, we should automate this activity for our users.
2. Dashboards should automatically populate with relevant metrics that were detected, however still offer flexibility to be customized as needed for a specific use case or application. The dashboards themselves should offer the visualizations required to best represent the data.
3. When troubleshooting, we should offer the ability to easily explore the data to help understand potential relationships and create/share one off dashboards.
4. Alerts should be easy to create, and provide a variety of notification options include Issues and third party services like Slack. It would also be great if we could provide some automatic detection of outliers/anomalies, and out of the box alerts based on best practices.
5. Service Level Objectives should be able to be defined, with corresponding impact on Error Budgets when they are not met.

What's Next & Why

Next up is the ability to support multiple queries per chart, which is an important building block to improve our charting dashboard.

This allows multiple time series to be represented in the same chart, that require different queries to generate. For example showing both the p95 and p99 buckets in the same chart.

Maturity Plan

• Base Epic

Competitive Landscape

Datadog and New Relic are the top two competitors in this space.

Analyst Landscape

Gartner does a review of APM products in their APM Magic Quadrant.

We are working to set up meetings with analysts to gather their feedback.

Top Customer Success/Sales Issue(s)

Not yet, but accepting merge requests to this document.

Top Customer Issue(s)

Support for NGINX Ingress 21+

Top Internal Customer Issue(s)

Not yet, but accepting merge requests to this document.

Top Vision Item(s)

Not yet, but accepting merge requests to this document.