Gitlab hero border pattern left svg Gitlab hero border pattern right svg

APM Group

  1. You are here:
  2. Handbook
  3. Engineering
  4. Development Department
  5. Ops Section
  6. Monitor Stage
  7. APM Group

Backend Team members

Person Role
Matt Nohr Engineering Manager, Monitor:APM
Reuben Pereira Backend Engineer, Monitor:APM
Ryan Cobb Backend Engineer, Monitor:APM
Adrien Kohlbecker Senior Backend Engineer, Monitor:APM
David Wilkins Senior Backend Engineer, Monitor:APM
MikoĊ‚aj Wawrzyniak Backend Engineer, Monitor:APM
Kirstie Cook Backend Engineer, Monitor:APM

Frontend Team members

Person Role
Adriel Santiago Interim Frontend Engineering Manager, Monitor:APM
Jose Ivan Vargas Frontend Engineer, Monitor:APM
Dhiraj Bodicherla Senior Frontend Engineer, Monitor:APM
Miguel Rincon Senior Frontend Engineer, Monitor:APM

Stable counterparts

Person Role
Achilleas Pipinellis Technical Writer, Create, Package, Monitor, Secure, Defend
Amelia Bauerly Product Designer, Monitor & Package
Dov Hershkovitch Senior Product Manager, Monitor:APM
Sarah Waldner Product Manager, Monitor:Health
Nadia Sotnikova Product Designer, Monitor

Responsibilities

The APM group is responsible for:

This team maps to the APM Group category.

How to work with APM

Adding new metrics to GitLab

The APM Group is responsible for providing the underlying libraries and tools to enable GitLab team-members to instrument their code. When adding new metrics, we need to consider a few facets: the impact on GitLab.com, customer deployments, and whether any default alerting rules should be provided.

Recommended process for adding new metrics:

  1. Open an issue in the desired project outlining the new metrics desired
  2. Label with the ~group::apm label, and ping @gl-monitoring for initial review
  3. During implementation consider:
    1. The Prometheus naming and instrumentation guidelines
    2. Impact on cardinality and performance of Prometheus
    3. Whether any alerts should be created
  4. Assign to an available APM Group reviewer

Milestone Planning

In planning a milestone, the engineering and product team work closely together. We do follow the Engineering Workflow and specifically the Product Development Timeline when planning a milestone. However, here is some additional information that may help in the planning process.

For APM we use the APM Planning Board to do milestone planning and to prioritize our backlog. We defer to the Product Development Timeline for deadlines. The following information outlines how we execute those tasks in the context of our issue board where M is the month in which milestone m will be shipped:

  1. By the 4th of M-1 (at least 14 days before milestone m begins):
    • Organize the upcoming release column by priority. This serves as a draft of issues to be included in m.
  2. Organize the upcoming release column by priority.

    • Due Date: First day of the month. Note: this aligns with the Product Development Timeline

      Responsible Accountable Consulted
      PM PM EMs

    • Identify any issues that will not be completed in m-1 and move them to m. Apply the "to schedule" label for any that are moved, and apply a weight (see Issue Weights). Note: This may continue to happen leading up to our deadline for finalized scope on the 13th of M-1

      Responsible Accountable Consulted
      EMs PM Engineers
  3. By the 13th of M-1 (at least 5 days before milestone m begins):

    • Scope should be finalized with the deliverable label applied to all issues scheduled for m.

      Responsible Accountable Consulted
      EMs PM Engineers

    • Apply the release post item label to the top issues for the upcoming milestone that we want to highlight in the Kickoff call.

      Responsible Accountable Informed
      PM PM EMs
  4. After the 22nd of M-1 (release date for m-1):

    • Ensure all remaining issues in m-1 have either been moved to m or to a later milestone for reprioritization at a later time.

      Responsible Accountable Informed
      EMs and PM PM Assignees

By using the planning board as a priority list, and by keeping it in order, then we should always be able to look at the current and upcoming milestone columns to have a prioritized list of upcoming work.

Issue Weights

We only use issue weights when we have to move an issue from one milestone to the next. This is to help us understand how much remaining work we have for any issue that had to move. For example, we may schedule an issue that just needs a final review differently than an issue that has not been started. We use a simple 1 to 10 scale to estimate the remaining work:

Weight Meaning
1 10% Remaining
5 50% Remaining
10 100% Remaining/Not Started

Recurring Meetings

While we try to keep our process pretty light on meetings, we do hold a Monitor APM Weekly Meeting to triage and prioritize new issues, discuss our upcoming issues, and uncover any unknowns.

Async Daily Standups

The purpose of our async standups is to allow every team member to have insight into what everyone else is doing and whether anyone is blocked and could use help. This should not be an exhaustive list of all of your tasks for the day, but rather a summary of the major deliverable you are hoping to achieve. All question prompts are optional. We use the geekbot slack plugin to automate our async standup in the #g_monitor_standup_apm channel. Every team member should be added to the async standup by their manager.

Repos we own or use

Issue boards

Edit this page — open Web IDE — please contribute. Creative Commons License