Frontend Observability Working Group

1. You are here:
2. Meet the GitLab team
3. Organizational Structure
4. Working Groups
5. Frontend Observability Working Group

On this page

• Attributes
  • Charter
  • Scope and Definitions
    • Definitions
  • Exit Criteria
• Roles and Responsibilities

Attributes

Charter

This working group will co-ordinate the organization of the effort to develop a frontend observability framework for Gitlab and establish guidelines for its usage. There is currently no method to instrument the frontend for the purposes of monitoring performance, especially across a range of devices and content. Error monitoring is possible but is mostly unused. This group will explore, define, and coordinate the development of system to make this instrumentation possible and document recommendations for use.

Scope and Definitions

This group will focus on creating a method for sending browser performance data to a frontend stats gateway that will allow the metrics to be accessed via our system, like the current backend metrics. Determining the details of this is part of the remit. Once this exists, the group will be responsible for documenting its use, as well as usage recommendations for error monitoring. This will allow frontend engineers to understand the performance of their code in various contexts and add another source of data to help find issues when new features are rolled out.

Stakeholders for this project include frontend engineers and SREs.

This group will not focus on instrumentation around user actions for product reasons; this is covered by Snowplow and has a different use case.

Definitions

• Frontend Observability describes the process of being able to answer questions about the performance of frontend code "in the wild". It is provided via the instrumentation of frontend Javascript. This is a nice talk covering what it can mean, although the goals of this group will be focused around performance and errors.

Exit Criteria

This working group will have fulfilled its purpose when:

• The @sentry/browser package is upgraded to version 6.10.0 or higher
• Sentry is configured to track and report frontend errors reliably
• Sentry is configured to monitor our performance with performance tracing
• We have decided what client performance data to send to Prometheus
• The aforementioned client performance data is sent to and tracked in Prometheus
• A triaging / diagnosing process is created for sentry errors
• Documentation is written that allows other frontend engineers to contribute

Roles and Responsibilities

The functional leads will be responsible for:

• Representing the needs of individual stakeholders in their department/sub-dept
• Gathering and consolidating feedback on specific proposals from their department/sub-dept
• Communicating the output from the working group (if any) and answering questions from their dept/sub-dept

Ideally the functional lead is someone who is an IC that might be affected by the policy put in place. but anyone capable of representing a department or sub-department in the fashion mentioned above is welcome.