Remove dependency on KNOWN_KEYS constant to bump gitlab-labkit to 0.22.0
What does this MR do and why?
This updates Labkit from 0.21.3 to 0.22.
Changelog:
- https://gitlab.com/gitlab-org/labkit-ruby/-/merge_requests/88: Don't enforce logged keys to be known by Labkit
- https://gitlab.com/gitlab-org/labkit-ruby/-/merge_requests/86: Update gitlab-dangerfiles to 2.6
- https://gitlab.com/gitlab-org/labkit-ruby/-/merge_requests/87: Pin jaeger-client to 1.1.x
Diff: https://my.diffend.io/gems/gitlab-labkit/0.21.3/0.22.0
Mainly for https://gitlab.com/gitlab-org/labkit-ruby/-/merge_requests/88 which would be needed for !75542 (merged) and gitlab-com/gl-infra/scalability#128 (comment 462598081)
For this we needed to remove dependency on removed LOG_KEYS constant
This moves the knowledge about which keys GitLab-rails can log
entirely into the ApplicationContext
class.
We were using these known keys to allow deleting Sidekiq jobs from the queue based on context information that gets added to the jobs. So we do need to know what kind of information to accept for this.
This also adds a spec making sure we don't push anything into the context that we haven't defined in the KNOwN_KEYS constant.
Testing locally
Browse the GDK and see that meta.
keys are still included in development_json.log
:
{"method":"GET","path":"/-/peek/results","format":"json","controller":"Peek::ResultsController","action":"show","status":200,"time":"2022-02-02T15:42:20.646Z","params":[{"key":"request_id","value":"01FTXHKADSBR1FTVYF70QYF99P"}],"correlation_id":"01FTXHKP9T1CKGHP4E7BCMJCEN","meta.user":"root","meta.client_id":"user/1","meta.caller_id":"Peek::ResultsController#show","meta.remote_ip":"127.0.0.1","remote_ip":"127.0.0.1","user_id":1,"username":"root","ua":"Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0","queue_duration_s":0.147712,"request_urgency":"default","target_duration_s":1,"redis_calls":4,"redis_duration_s":0.002258,"redis_read_bytes":707940,"redis_write_bytes":2501,"redis_cache_calls":2,"redis_cache_duration_s":0.001761,"redis_cache_read_bytes":707757,"redis_cache_write_bytes":1296,"redis_shared_state_calls":1,"redis_shared_state_duration_s":0.000188,"redis_shared_state_write_bytes":53,"redis_sessions_calls":1,"redis_sessions_duration_s":0.000309,"redis_sessions_read_bytes":183,"redis_sessions_write_bytes":1152,"db_count":1,"db_write_count":0,"db_cached_count":0,"db_replica_count":1,"db_primary_count":0,"db_replica_cached_count":0,"db_primary_cached_count":0,"db_replica_wal_count":0,"db_primary_wal_count":0,"db_replica_wal_cached_count":0,"db_primary_wal_cached_count":0,"db_replica_duration_s":0.002,"db_primary_duration_s":0.0,"cpu_s":0.122587,"pid":13031,"db_duration_s":0.0,"view_duration_s":0.00018,"duration_s":0.00846}
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.