## 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-09-03 Continuous progress on preparing services to be migrated to the new logging field naming standard. :clock1: **total hours spent this week by all contributors**: 22 :status: **TL;DR**: On track. :tada: **achievements**: - The GitLab Runner is now prepared to be configured to use the new logging field naming standard: https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/6995 - This concludes the second of four services we plan to migrate in the first iteration: https://gitlab.com/groups/gitlab-org/quality/-/work_items/440+ - Raised an MR to prepare Gitaly to consume the logging settings: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/9189 - After a short alignment with the GitLab Pages maintainers, I referred my question about the deployment and observability infrastructure impact to the infrastructure team - Raised an MR to correct the behaviour of the logging field validator in the pipeline of Gitaly: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/9188 :arrow_forward: **next**: - Based on the response and guidance from the infrastructure team, continue the migration of GitLab Pages - Tackle the preparation of the GitLab Rails application as the next big step: https://gitlab.com/gitlab-org/gitlab/-/work_items/608155+ _Copied from https://gitlab.com/groups/gitlab-org/quality/-/epics/398#note_3778652193_ <!-- STATUS NOTE END -->