Operators might want to know how many tables, databases or schemas there are in a database. It's inconvenient to only be able to access this information via SQL, since operators may not always have readily available SQL access.
A count metric like sql.schema.tables.count, or alternatively sql.schema.objects.count with a tag for table/database/function/etc, would be a way to allow operators visibility into this performance-crucial number.
Some light research indicates this isn't a common metric in databases, so I think we definitely need some Product thinking before we just add this, but I'm certain it would help with operator experience especially given our soft limits around object count. Alerting based on active vs limit would be valuable as well.
Operators might want to know how many tables, databases or schemas there are in a database. It's inconvenient to only be able to access this information via SQL, since operators may not always have readily available SQL access.
A count metric like
sql.schema.tables.count
, or alternativelysql.schema.objects.count
with a tag for table/database/function/etc, would be a way to allow operators visibility into this performance-crucial number.Some light research indicates this isn't a common metric in databases, so I think we definitely need some Product thinking before we just add this, but I'm certain it would help with operator experience especially given our soft limits around object count. Alerting based on active vs limit would be valuable as well.
cc @rafiss @dikshant @rimadeodhar
Jira issue: CRDB-44207
Epic CRDB-43310