This is the product vision for Monitor. If you'd like to discuss this vision directly with the product manager for Monitor, feel free to reach out to Joshua Lambert via e-mail or by scheduling a video call.
Performance is a critical aspect of the user experience, and ensuring your application is responsive and available is everyone's responsibility. We want to help address this need for development teams, by integrating key performance analytics and feedback into the tool developers already use every day.
As part of our commitment to performance we are also deeply instrumenting GitLab itself, enabling our team to improve GitLab peformance and for customers to more easily manage their deployments.
There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.
Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.
GitLab collects and displays performance metrics for deployed apps, leveraging Prometheus. Developers can determine the impact of a merge and keep an eye on their production systems, without leaving GitLab. This category is at the "minimal" level of maturity.
GitLab makes it easy to view the logs of running pods in connected Kubernetes clusters. By displaying the logs directly in GitLab, developers can avoid having to manage console tools or jump to a different interface. This category is at the "minimal" level of maturity.
Out-of-the-box Kubernetes cluster monitoring let you know the health of your deployment environments with traceability back to every issue and code change as part of a single application for end-to-end DevOps. This category is at the "minimal" level of maturity.
Tracing provides insight into the performance and health of a deployed application, tracking each function or microservice which handles a given request. This makes it easy to understand the end-to-end flow of a request, regardless of whether you are using a monolithic or distributed system. This category is at the "minimal" level of maturity.
Error tracking allows developers to easily discover and view the errors that their application may be generating. By surfacing error information where the code is being developed, efficiency and awareness can be increased. This category is at the "minimal" level of maturity.
Simulate user activity within your application, to detect problems in end-to-end workflows and undestand real-world performance. This category is planned, but not yet available.
Track incidents within GitLab, providing a consolidated location to understand the who, what, when, and where of the incident. Define service level objectives and error budgets, to achieve the desired balance of velocity and stability. This category is planned, but not yet available.
Easily communicate the status of your services to users and customers. This category is planned, but not yet available.
Self-managed GitLab instances come out of the box with great observability tools, reducing the time and effort required to maintain a GitLab instance. This category is planned, but not yet available.
GitLab is a unique product, a single application which spans the entire devops lifecycle. This breadth offers both the capability for a unified user experience, as well as emergent capabilities.
We want to help teams resolve outages faster, accelerating both the troubleshooting and resolution of incidents. GitLab's single platform can analyze the incoming observability data with known CI/CD events and source code infomation, to automatically suggest potential root causes. GitLab's Web IDE can also provide an optimized coding experience, presenting the source code enriched with related observability data like stack traces.
There is often a tension between the velocity of shipping new features and stability of the overall service. The desired balance is frequently different between companies, as well as between services within a company.
In general, we follow the same prioritization guidelines as the product team at large. Issues will tend to flow from having no milestone, to being added to the backlog, to being added to this page and/or a specific milestone for delivery.
You can see our entire public backlog for Monitor at this link; filtering by labels or milestones will allow you to explore. If you find something you're interested in, you're encouraged to jump into the conversation and participate. At GitLab, everyone can contribute!
Issues with the "direction" label have been flagged as being particularly interesting, and are listed in the sectiond below.
requestedresources to cluster monitoring
There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!