The following page contains information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
UPDATE: As of 2020-09-01: The Metrics category at GitLab has presently been reprioritized and we are not actively progressing this category. The vision you see displayed on this page represents the direction we will pursue if this becomes a priority again in the future.
Thanks for visiting this category strategy page on Metrics in GitLab. This category belongs to and is maintained by the Health group of the Monitor stage.
This page is maintained by Kevin Chu, group product manager. You can connect with him via Zoom or Email. If you're a GitLab user and have direct knowledge of your Metrics usage, we'd especially love to hear your use case(s).
Metrics help service operators understand the health and status of the provided services; as such, metrics are essential for ensuring the reliability and stability of those services.
In practice, metrics are typically represented by a name, a type, and a measurement. They can tell you simple things like the current CPU usage rate, and they can also represent more complex concepts such as an Apdex score. Users typically would gather metrics of their monitored system into their product analytics system (such as Prometheus) to observe how their systems are behaving. There are many metrics that are exposed by your operating system or framework (e.g. Kubernetes metrics) and these metrics are typically easy to collect. For other components, such as the applications you developed, you may have to add code or other interfaces (such as an agent running on the same host as your application) to expose the metrics that you care about. Exposing metrics is sometimes called instrumentation, the collection of metrics from an end point is called scraping.
Once you have started collected metrics of your system, you now have the basis to defineservice level indicators and service level objectives. Having SLIs and SLOs is critical for efficient alerting and incident remediation. Defining SLIs and SLOs requires time to understand, correlate, and fine-tune relationships between the different kinds of metrics you are capturing.
Provide users with information about the health and performance of their infrastructure, applications, and system for insights into reliability, stability, and performance.
Metrics are essential for all users across the DevOps spectrum. From developers who should understand the performance impact of changes they are making, as well as operators responsible for keeping production services online.
Our vision is that in 1-2 years, GitLab metrics is the main day-to-day tool for monitoring cloud-native applications for SMBs.
We are targeting Software Developer and DevOps Engineer working in a SMB from the following reasons:
Since the team's current focus is dogfooding metrics, our immediate target audience is the GitLab Infrastructure Team. We plan to build the minimal work needed for them to start dogfooding our metrics dashboard before shifting focus to consider the overall needs of the target audience mentioned above.
The experience today offers you to deploy Prometheus instance into a project cluster by a push of a button, the Prometheus instance will run as a GitLab managed application. Once deployed, it will automatically collect key metrics from the running application which are displayed on an out of the box dashboard. Our dashboards provide you with the needed flexability to display any metric you desire you can set up alerts, configure variables on a generic dashboard, drill into the relavant logs to troubleshoot your service and more… If you already have a running Prometheus deploy into your cluster simply connect it to your GitLab and start using our GitLab metrics dashboard.
The target workflow, listed below, is our high-level roadmap. It is based on competitive analysis, user research, and customer interviews. The details of each workflow are listed in the epics and issues.
The first step in application performance management is collecting the proper measurements or product analytics data. Instrumenting critical areas and reporting metrics of your system are prerequisites to understanding the health and performance of your services and application. Our metric solution is powered by Prometheus, targeting users of Kubernetes. We need to make sure our users can successfully
Once you've collected a set of metrics, the next step is to see those metrics in a dashboard.
Users need to be alerted on any threshold violation, ideally before their end-users
Our vision is that in 1-2 years, GitLab metrics will be the primary day-to-day tool for monitoring cloud-native applications. To achieve that we would need to support:
In the distributed nature of cloud-native applications, it is crucial and critical to collect logs across multiple services and infrastructure, present them in an aggregated view, so users could quickly search through a list of logs that originate from multiple pods and containers. Metrics and logs are related and we intend to make the correlation for users so that they can more quickly get to the answers they are looking for. You can review our logging direction page for more information.
We are actively Dogfooding GitLab Metrics with the Infrastructure team to migrate dashboards used for monitoring Gitlab.com from Grafana to GitLab Metrics. This will help us receive rapid feedback as we mature metrics. In terms of this overall roles and responsibilities:
We will iterate based on the following process:
As mentioned above, adding a metric to a dashboard and adding new dashboards are basic functionalities a monitoring solution should have. Today, this can be quite confusing for a first time GitLab Metrics user. We are actively working on improving these workflows and allow a better onboarding experience for our users. Detailed information can is available in the following:
