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

APM Group

APM Group

On this page

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 W. Backend Engineer, Monitor APM
Kirstie C. 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
Ahmad Sherif Site Reliability Engineer, Manage, Monitor & Configure
Amarbayar Amarsanaa Senior Site Reliability Engineer, Create, Plan, Monitor
Dov Hershkovitch Senior Product Manager, Monitor:APM
Sarah Waldner Product Manager, Monitor:Health

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. Here is what we do to keep that board up-to-date:

  1. Identify any issues that will not be completed in the current release and move them to the top of the next/upcoming release column.
    • Due Date: Last day of the month. Note: although the end of the month is only about half-way through the continuous delivery release cycle, we will hopefully have a good sense by then what we are working on and what can get done in the current release.
    • Responsible: Engineering Managers with input from the engineering teams
  2. Organize the upcoming release column by priority.
  3. Apply the Deliverable label to the top items in the upcoming milestone that will be completed. These should be the top priority items that are almost sure to be completed by the end of the upcoming milestone.
    • Due Date: Fourth day of the month
    • Responsible: Engineering Managers with input from the engineering teams
  4. Apply the “direction” label to the top issues for the upcoming milestone that we want to highlight in the Kickoff call.
    • Due Date: Before the kickoff call on the 8th of the month
    • Responsible: Product Manager
  5. Move items from the upcoming release that will not be worked on into a future release to be prioritized later. Some issues that were not considered "Deliverable" could remain in, and be labeled with the Stretch label.
    • Due Date: Shortly after the kickoff call
    • Responsible: Product Manager and Engineering Manager

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.

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.

Repos we own or use

Issue boards