Add per DB counters to logs and refactor
This MR adds multiple new DB metrics to our logging when the `multiple_database_counters` feature flag is enabled. ```diff + "db_primary_primary_cached_count": 0, + "db_primary_primary_count": 0, + "db_primary_primary_duration_s": 0, + "db_replica_primary_cached_count": 0, + "db_replica_primary_count": 0, + "db_replica_primary_duration_s": 0, + "db_primary_primary_wal_count": 0, + "db_primary_primary_wal_cached_count": 0, + "db_replica_primary_wal_cached_count": 0, + "db_replica_primary_wal_count": 0, + "db_replica_primary_duration_s": 0, + "db_primary_primary_duration_s": 0, ``` These new fields indicate how many queries went to the database named `primary`. `primary` happens to be the default name Rails gives to the database connections described in `config/database.yml`. This is unfortunate as it conflicts with the `primary/replica` language we use to distinguish between read/write and read-only servers (hence `primary_primary` in the key) but this will change when we start explicitly setting the 2 databases we configure to be called `main` and `ci`. The feature flag exists to alleviate some of this confusion as described in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66515 as only the ~group::sharding will need to use this for testing in the meantime. Prior to this change we already supported logging the `duration_s` data per database but we did not log the count of queries. When implementing this count of queries it became obvious it was much easier to implement these metrics in the same way that all the other metrics were implemented. In particular that they are logged as `0` even if there was no matching query. This led to quite a lot of refactoring because the list of `database_config_names` is dynamic. It's what is configured in `config/database.yml` and we had a tonne of tests that needed the full list of keys and values being logged.
Showing
Please register or sign in to comment