Skip to content

Resolve "Remove gitops_sync_count and k8s_api_proxy_request_count metrics"

What does this MR do and why?

Removes deprecated code.

The GitLab Agent Server (KAS) is the only component which uses this
internal API. In the current version of KAS it does not send
param[:gitops_sync_count] and params[:k8s_api_proxy_request] anymore, 
since GitLab 15.3.

We have kept these around while we were transitioning the KAS version to
change the params to use params[:counters] and params[unique_counters].
It is safe to remove this code now.

One can confirm here that KAS is only using params[:counters] and params[:unique_counters]. Observe how we serialize the request params:

json:"counters,omitempty" and json:"unique_counters,omitempty"

Screenshots or screen recordings

My own tests result were copied and pasted to the next section on how to reproduce it.

How to set up and validate locally

[3] pry(main)> Gitlab::UsageDataCounters::KubernetesAgentCounter.count(:k8s_api_proxy_request)
=> 299
  • To check the Unique counters, you can also use Rails:
Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'agent_users_using_ci_tunnel', start_date: Date.current.beginning_of_week, end_date: Date.current.next_week)
=> 2
  • Or through our RedisHLL keys
> redis-cli -s $YOUR_GDK_PATH/redis/redis.socket
> keys *agent*
1) "{agent}_users_using_ci_tunnel-2022-39"
2) "{agent}_users_using_ci_tunnel-2022-44"

> pfcount {agent}_users_using_ci_tunnel-2022-44
(integer) 2

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #369489 (closed)

Edited by João Alexandre Cunha

Merge request reports

Loading