## Description As part of the [logging field standardisation](https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1432), ~"group::development tooling" is implementing a strategy to rename and standardize logging fields across GitLab services. The goal is to move forward quickly for GitLab.com to help internal engineers while minimizing overhead and difficulties for self-managed and dedicated customers. ## Background Following the [decisions made on 2026-04-10](https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/work_items/4349#note_3239668711), the team agreed on a phased approach: - **Admin panel setting**: Introduce an admin panel setting that allows customers (internal and external) to control which version of logging field names is emitted — old only (default), dual-emit (old + new), or new only. This enables a paced migration for customers while letting GitLab.com move forward independently. - **Initial focus on high-impact fields**: Rather than tackling all fields at once, focus first on logging fields with the highest usage and impact. Lower-impact fields will be handled through a breaking change exception request. - **Service-level consumption**: The setting must be consumed at boot by service runtimes to avoid adding per-log checks that would degrade logging speed. ## Strategy and phases 1. **Identify and document high-impact logging fields** — Determine which logging fields to focus on initially, based on usage and impact. 2. **Create the admin panel setting** — Build the setting that controls the logging field naming version. 3. **Define the SSOT for included fields** — Establish a single source of truth in labkit-spec for which fields are controlled by the setting. 4. **Enable services to consume the setting** — Implement a mechanism for services to read the setting at boot and adjust logging accordingly, with benchmarks to ensure no performance regression. 5. **Document expected changes** — Collect and map current vs. new field names per service, and coordinate with affected teams (e.g., Security). 6. **Execute internal migration** — Migrate GitLab.com to the new field names using the admin panel setting. 7. **Create migration guide and roll out to customers** — Produce a clear migration guide with steps, support contact, and deadlines, then communicate to customers in collaboration with customer support. ## Key constraints - The cost of dual-emitting grows quickly at thousands of requests per second — minimize the dual-emit window. - Logging speed must not be impacted; setting consumption happens at boot, not per-log. - Niche/low-impact fields go through a breaking change exception request, not the admin panel setting. ## Related - Parent epic: [Standardize logging fields across all index patterns for GitLab.com](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1432) - Decision log: [team-tasks#4349 (note)](https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/work_items/4349#note_3239668711) - Meeting recording: https://www.youtube.com/watch?v=HXCKAu0JGWg ### Status <!-- STATUS NOTE START --> ## Status 2026-07-09 Most of the groundwork for the migration is set. :clock1: **total hours spent this week by all contributors**: 22 :tada: **achievements**: - The frontend changes for the admin panel setting are waiting for maintainer approval: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/243667 - The [LabKit extension](https://gitlab.com/gitlab-org/labkit/-/merge_requests/496) is merged. With this in place, we can start setting up services one by one to consume the related application setting to kickstart the migration to standard fields internally. :arrow_forward: **next**: - Kickstart the migration internally. This will involve several internal parties that consume the logs and orchestrate GitLab. - With the results of the internal migration, we can create a customer journey with the help of customer support. _Copied from https://gitlab.com/groups/gitlab-org/quality/-/epics/398#note_3539098122_ <!-- STATUS NOTE END -->