[Feat]: Enable an extra layer of nesting in TOC menu

[shyamvalsan]

Problem

The current TOC menu only allows one layer of nesting - this is restrictive for many use-cases - and forces metrics to be organized in sub optimal ways.

Description

Enable more layers of nesting in TOC menu for optimal metric organization.

I am hitting a blocker right now, working on the PostgreSQL monitoring use-case due to the lack of this ability.

Currently the metrics are organized like this:

• Cluster level metrics first
• Followed by database level metrics (which are preceded by "db") aggregated across all databases

Drawbacks of this approach:

• If a particular DB has a problem, aggregate charts may mask this and the onus is then on the user to first go to a metric, select group by or filter by a database to discover said problem. To traverse to another metric the steps then need to be repeated. This is time consuming and clumsy.
• Aggregating across databases does not make sense for some metrics, and aggregation needs to be context specific in other cases.

The old (python postgres collector) approach was to have sub sections for each DB, so if you had 3 DBs you would have DB X, DB Y and DB Z but lose all sort of metric organization underneath it. Which means to find (for example) buffer cache hit ratio of DB X you need to click on DB X and then scroll through dozens of charts.

--

The approach we would like to pursue (open to better ideas) is to organize things in the following manner:

• Add support for nested menu entries in TOC + group all DB related metrics under the DB name
• Charts under a particular DB section would still be "composite" charts but filtered on that particular DB (This means the user is free to select other DBs for comparison etc.)
• Advantage: Retain metric organization and menu navigation, no aggregation confusion
• Example below shows the case where there are two PostgreSQL jobs (1 and 2)

PostgreSQL 1

• Summary
• Cluster level metrics
  • DB X
    • DB level metrics
    • Connections
    • Transactions (...)
  • DB Y
    • DB level metrics
  • DB Z
    • DB level metrics

PostgreSQL 2

• Summary
• Cluster level metrics
• DB A
  • DB level metrics
• DB B
  • DB level metrics

Importance

must have

Value proposition

1. Optimal metric organization => Faster monitoring and troubleshooting

Proposed implementation

No response

[shyamvalsan]

cc: @sashwathn @amalkov @ralphm

As discussed in the call, in the short term we will proceed with organizing and naming the currently available sections more optimally and enabling group-by database by default for charts where this is available. This will be a workaround.

Longer term we need the feature requested in this ticket, or something similar.

[shyamvalsan]

@novykh how much work is it to add an extra layer of nesting in TOC menu?

[novykh]

It depends on the rule. I will do some refactoring the coming days, so I can add more flexibility to this

[hugovalente-pm]

I'm not sure this is the path we want to take at the moment, this details of DB has been brought into the composite charts with NIDL framework and all

it seems we would be diverting from our current approach. wdyt @shyamvalsan ?