Skip to content

feat: adds the new fields package to labkit

Elliot Forbesrequested to merge
ef-add-attribute-package into master

This is intended to help enforce a certain level of consistency across our Go services when it comes to representing information within our logs.

This starts with the GitLabUserID as this field has been identified to be particularly troublesome within our current o11y setup.

What the field actually equates to is still up for debate, as is how we go about defining this pattern, so please feel free to suggest alternative approaches if you've seen this done differently/better.

Why gl_user_id?!

You might be asking why the gl_ prefix has been added to this field. There are a few reasons for this:

  1. to aide with the migration efforts - we can have service emit both the original fields as well as this new field at the same time and gradually move off any additional observability setups to this new field.
  2. the prefix helps to reduce a little cognitive load - the reader is immediately able to identify that this user_id is scoped to GitLab and it's not pertaining to an external user_id field.

Intended Outcome

When developers are working through enriching logs/metrics/traces (in the future), they should lean on fields.GitLabUserID as the respective field name. This will help to ensure consistency across the various Go runtimes.

Once we've agreed upon the actual field name, the intent is to create comparable Ruby and Python packages that can be utilised in a similar fashion.

We'll then be communicating this pattern more broadly across the organization and encouraging folks to use these standard field names.

This should eventually:

  • reduce the number of fields we have representing the same information today in our observability system
    • This will in turn, help to reduce the number of incidents that the dedicated team are pulled into. (concrete numbers pending)
  • improve our ability to debug and investigate our systems and reduce the cognitive load when interpreting logs emitted by different systems

Identified Duplicate Fields

Based on some discussions in this incident - we have the following fields present in our index:

  • meta.user
  • job_user_id
  • meta.user_id
  • user_id
  • username

It's not immediately clear if we can reduce all of these down to this new field, but if these do all contain the same information then this would be a fantastic win and would allow for easier querying of this field across our system. Username is the outlier, I'd like to see if we can rely purely on the gl_user_id.

Edited by Elliot Forbes

Merge request reports