The following page may contain 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.
Content Last Reviewed: 2023-12-21
This page outlines the direction for the Monitor:Observability group. Feedback is welcome: you can create a new issue or reach out to this page maintainer if you have any questions or suggestions.
| Category | Description | Availability | Maturity |
|---|---|---|---|
| Error Tracking | Detect, visualize and triage applications errors | GA | Minimal |
| Distributed Tracing | Track and visualize application requests across distributed services | Beta | Minimal |
| Metrics | Collect and visualize application performance and health metrics | Experiment | Minimal |
| Logging | Centralize application and infrastructure logs collection, storage and analysis | Experiment ETA Q1 2024 | Planned |
Observability software enables the visualization and analysis of application performance, availability and user experience, based on the telemetry data it generates, such as traces, metrics or logs. It allows developers and operators to understand the impact of a code or configuration change, answering questions such as:
Common capabilities include the configuration of dashboards and alerts for issue detection and triage, the execution of analytical queries for deeper issue investigation and root cause analysis, as well as the capability to share findings with team members. By centralizing data from multiple sources into a single, unified platform, observability tools facilitate collaboration across software development and operations teams, enabling companies to resolve issues faster and minimize downtimes.
We aim to provide a best-in-class observability solution that enables our customers to monitor their applications and infrastructure performance directly within GitLab. This will allow organizations to further consolidate their DevOps workflows into a single platform, enhancing operational efficiency.
We will pursue this vision with the following principles:
We are focused on solving problems for modern development teams first. In doing so, we immediately add value to the majority of our current users. Over time, this will allows us to provide a unique, modern approach to observability, helping companies to further "shift-left" their monitoring workflows.
Platform teams are key to building an onramp to the product. Providing them capabilities to observe and improve the performance of their software delivery platform will allow us to land our first champion users within an organization, and help expanding to development teams.
Building features first for modern, cloud-native environment allows us to focus on where development is going, and deliver solutions that every company aspires to use eventually.
We want developers to have immediate access to an available observability solution. That means we will ensure it is on by default, starts with convention over configuration, and is easy to use.
Consolidating data into a single place facilitates collaboration and enables to surface unique insights by correlating diverse set of information, which would otherwise be overlooked if siloed. To achieve this, we are working to store all types of telemetry data that are useful for DevOps teams - from metrics, logs, traces, and errors, to analytics data into a cohesive data platform that can span the entire DevOps process.
The data visualization and investigation capabilities we are building are aimed to be seamlessly integrated into the platform and enhance other GitLab features and contribute to the direction for customizable dashboards in GitLab.
We are supporting OpenTelemetry as the primary way to instrument, generate, collect and export telemetry data. This approach aligns with GitLab's values, as it emphasizes our support for open-source industry standards. This way, we hope to contribute to improve OpenTelemetry, and that our customers will be able to do the same. We will progressively deprecate previously built solutions based on other agents or SDK.
GitLab error tracking allows developers to discover and view errors generated by their application directly within GitLab, removing the need to switch between multiple tools when debugging. In this release, we are supporting both the GitLab integrated error tracking and the Sentry-based backends.
Learn more: Release Post, Direction page
With GitLab Distributed Tracing, users can now troubleshoot application performance issues by inspecting how a request moves through different services and systems, the timing of each operation, and any errors as they occur. It is particularly useful in the context of micro-service applications, which group multiple independent services collaborating to fulfill user requests.
Telemetry data can be collected via any OpenTelemetry SDK:
Collected Traces can be queried and visualized via a new integrated UI, replacing previous Jaeger-based front-end:
The Beta release adds the following features:
Learn more: Tracing documentation page
With GitLab Metrics, users can collect application and infrastructure metrics, offering valuable insights for tracking performance and system health. This first release has the following features and limitations:
Learn more: Metrics documentation page
In the next 3 months (2023-12 - 2024-02), we will progress towards Tracing GA and Metrics Beta release, and release the first experiment version of Logs:
Tracing GA release (epic):
Metrics Beta release (epic):
Logs Experiment release (epic):
Logs will enable these new capabilities:
Additionally, by collecting telemetry data from GitLab CI/CD pipelines, GitLab platform operators will be able to investigate performance issues in their Software Delivery platform, and optimize pipeline execution speed. (related POC).
Exploratory work:
During this period, we will also explore:
Our goal for the next year (2023-11 - 2024-11) is to achieve minimal maturity and GA for all Observability categories, so customers can further consolidate their monitoring workflows within GitLab.
While we don't expect customers to fully replace existing solutions they may use with higher level of maturity, we expect to be able to provide development teams that are currently not using any monitoring tools a basic set of capabilities available directly in GitLab. This way, they will be able to start tracking and improving their application performance and availability.
Prioritized development work:
Exploratory work:
Learn more: see epic