LabKit

What is LabKit?

LabKit is a set of libraries that are intended to provide core-development functionalities such as logging, metrics, tracing, and more.

Vision

LabKit provides a consistent, intuitive interface for engineers to interact with application infrastructure, accelerating development and reducing time-to-production.

• Consistency

  • Standardized patterns for common infrastructure interactions
  • Enforced conventions across the GitLab ecosystem

• Ease of Use

  • Idiomatic APIs following language-specific best practices
  • Comprehensive documentation enabling rapid onboarding
  • Reduced Cognitive Load - engineers focus on business logic, not infrastructure boilerplate

• Accelerated Delivery

  • Production-ready defaults out of the box
  • Reduced setup time for new services and components
  • Focus on business logic, not infrastructure plumbing

• Observability by Default

  • Built-in instrumentation for metrics, traces, and structured logging
  • Consistent signal correlation across services
  • Improved incident response times and lower mean-time-to-recovery

LabKit Libraries

Development Tooling currently supports the following libraries:

• Go Library
• Ruby Library

New language adoption - engineering teams that adopt new languages will be asked to establish a new LabKit library for said language. This is to ensure that we retain that level of consistency across all language runtimes.

LabKit Roadmap

This section lays out a rough roadmap describing some of the sub-projects we are intending to deliver over the coming quarters.

If you have any questions or suggestions about projects you’d like to see in this list, please reach out to the Development Tooling team.

Field Standardization

Status: Under Development

Epic Links:

• Define Field Logging Standards for Developers

Handbook link: Field Standardization in Observability

The goal here is to define a schema for cross-domain fields and roll out this schema across our internal services.

• We’ve already helped to improve the upgrade experience for self-managed by reducing the number of incidents caused by high-dimensionality field names.
• Our next aim is to define a consistent field schema that is used across all services at GitLab in order to reduce toil when dealing with incidents. This ties directly into strengthening our monitoring and observability capabilities for managing GitLab for both self-managed and SaaS.
• The secondary outcome from this work is that we’re reducing the size of log messages being ingested by our logging infrastructure - this reduces our cost of goods sold (COGS) and indirectly helps to protect our, as well as our customer’s, observability infrastructure.

Logging Standardization

Status: Requirements Gathering

Epic Links:

• Migrate Core GitLab Systems to Labkit-based slog

Discussion issue: Discussion: Deprecating Logrus in favour of log/slog in Go Systems

The goal is to standardise how logging is configured within our GitLab services.

• This will enable the Observability team to move faster in their efforts to adopt OTeL logging and again ties into strengthening our monitoring and observability capabilities for managing GitLab for both self-managed and SaaS.
• Initial investigations have also highlighted that we can improve the startup and runtime performance of our systems by migrating away from legacy logging libraries.
• This will also accelerate customer value as we’ll be leaning on modern industry standards for logging and subsequent feature development work should be faster.

Metric Standardization

Status: To Be Scheduled

Tracing Standardization

Status: To Be Scheduled

Note: this is pending the outcome of this open epic: Select a distributed tracing solution for production use

Composite Metrics Functionality

Status: To Be Scheuled

Snowplow Standardization

Status: To Be Scheduled

The goal of this work is to provide all developers with the ability to lean on our Snowplow setup in a standard, consistent way.

We currently have a few fragmented approaches to set up Snowplow for capturing events, GDK being one of them. The ideal outcome of this project is that any internal team can lean on a generic setup should they need.

Note: Some work is ongoing to add an initial snowplow client to the LabKit Go repository, however, a wider effort will be needed to ensure that we’re catering for any and all internal use cases.

Standardised health, liveliness and readines checks

Status: To Be Scheduled

Standardised HTTP and gRPC Clients

Status To Be Scheduled

View page source - Edit this page - please contribute.