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

APM Group

On this page

• APM Group
  • Common links
  • Backend Team members
  • Frontend Team members
  • Stable counterparts
  • Responsibilities
  • How to work with Monitoring
    • Adding new metrics to GitLab
  • Repos we own or use
  • Issue boards
  • Async Daily Standups
  • Recurring Meetings
  • Monitor Stage PTO

Common links

• Slack channel: #g_monitor_apm
• Slack alias: TBD
• Google group: TBD

Backend Team members

Person	Role
Matt Nohr	Engineering Manager, Monitor APM
Reuben Pereira	Backend Engineer, Monitor
Ryan Cobb	Backend Engineer, Monitor
Adrien Kohlbecker	Senior Backend Engineer, Monitor APM
David Wilkins	Backend Engineer, Monitor

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 B.	Senior Frontend Engineer, Monitor APM

Stable counterparts

Person	Role
Achilleas Pipinellis	Technical Writer, Create, Package, Monitor, Secure, Defend
Amelia Bauerly	Product Designer, Monitor & Package
Sarah Voegeli	Senior Product Designer, Monitor & Package
Ahmad Sherif	Site Reliability Engineer, Manage, Monitor & Configure
Amarbayar Amarsanaa	Senior Site Reliability Engineer, Create, Plan, Monitor
D.H.	Senior Product Manager, Monitor:APM
Sarah Waldner	Product Manager, Monitor:Health
bg	Product Marketing Manager, Monitoring, Create

Responsibilities

The APM group is responsible for:

• Providing the tools required to enable monitoring of GitLab.com
• Packaging these tools to enable all customers to manage their instances easily and completely
• Building integrated monitoring solutions for customers apps into GitLab, including: metrics, logging, and tracing

This team maps to the APM Group category and focuses on:

• Metrics
• Tracing
• Logging

How to work with Monitoring

Adding new metrics to GitLab

The Monitor 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 ~Monitoring label, and ping @gl-monitoring for initial review
3. During implementation consider:
4. The Prometheus naming and instrumentation guidelines
5. Impact on cardinality and performance of Prometheus
6. Whether any alerts should be created
7. Assign to an available Monitor Group reviewer

Repos we own or use

• Prometheus Ruby Mmap Client - The ruby Prometheus instrumentation lib we built, which we used to instrument GitLab
• GitLab CE and GitLab EE - Where much of the user facing code lives
• Omnibus and Charts, where a lot of the packaging related work goes on. (We ship GitLab fully instrumented along with a Prometheus instance)

Issue boards

• APM - Main board with all issues labeled "group::apm"
• APM - Planning - APM issues organized by milestone
• APM - Product - APM issues organized by issue type label like "feature", "bug", "backstage", "security", or "Community contribution"
• APM - Workflow - APM issues organized by workflow label of "ready for development", "in dev", or "in review".

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 channel.

Recurring Meetings

While we try to keep our process pretty light on meetings, we do have a few recurring meetings to keep in sync and to keep our backlog in good shape. We hold the Monitor Group Weekly Meeting to discuss agenda items that have been added over the course of the week and to walk through our current issue board together.

There is also an optional Monitor Social Hour meeting every week. This call has no agenda and alternates times every other week to be more inclusive of team members in different time zones.

Monitor Stage PTO

Just like the rest of the company, we use PTO Ninja to track when team members are traveling, attending conferences, and taking time off. The easiest way to see who has upcoming PTO is to run the /ninja whosout command in the #g_monitor_standup slack channel. This will show you the upcoming PTO for everyone in that channel.