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: 2024-02-20
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.
|Detect, visualize and triage applications errors
|Track and visualize application requests across distributed services
|Collect and visualize application performance and health metrics
|Centralize application and infrastructure logs collection, storage and analysis
|Experiment ETA 16.10 (2024-03-21)
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.
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 aim to store all types of telemetry data that are useful for DevOps teams - from metrics, logs, traces, and errors, to usage 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.
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
Learn more: see internal release notes
In the next 3 months (2024-03 - 2024-05), we plan to release Logs and Metrics Beta, and the Experiment version of the Cloud Connector integration for self-managed customers:
Logs Experiment: ETA 16.10 (2024-03-21)
Logs Beta: ETA 17.0 (2024-05-16)
Logs will enable these new capabilities:
Metrics Beta: ETA 16.11 (2024-04-18)
Cloud Connector integration Experiment: ETA 17.0 (2024-05-16)
Integrating with Cloud Connector will enable self-managed customers to use observability features by storing data remotely (on gitlab.com), and querying and visualizing data seamlessly from their self-managed instance.
During this period, we will also explore:
Our goal for the current fiscal year (FY25: 2024-02 to 2025-01) 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:
Support GitLab self-monitoring use cases: what GitLab platform administrators need to troubleshoot performance issues in their software delivery platform at the application, infrastructure or pipeline level.
Learn more: see epic