feat(metrics): add a relation info panel in grafana

[hzxa21]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Resolve #22156. I try exposing the db and schema label in the specific metrics like source/sink throughput first but it turns out too difficult to do so. Given that the labels in tsdb won't be store repeatedly, the current approach is a good workaround IMO.

Checklist

• I have written necessary rustdoc comments.
• I have added necessary unit tests and integration tests.
• I have added test labels as necessary.
• I have added fuzzing tests or opened an issue to track them.
• My PR contains breaking changes.
• My PR changes performance-critical code, so I will run (micro) benchmarks and present the results.
• I have checked the Release Timeline and Currently Supported Versions to determine which release branches I need to cherry-pick this PR into.

Documentation

• My PR needs documentation updates.

Release note

[Copilot]

Pull Request Overview

This PR adds a new gauge metric, relation_info, to expose relation (table, source, sink) information in Grafana. The changes include introducing the new metric in the MetaMetrics struct with its refresh logic, extending the catalog controller with new methods to retrieve object information, and updating the Grafana dashboard to display the relation info panel.

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

File	Description
src/meta/src/rpc/metrics.rs	Added relation_info gauge metric and its refresh function.
src/meta/src/controller/catalog/get_op.rs	Added methods to list table, source, and sink objects.
src/meta/model/src/object.rs	Introduced a new Schema2 relation mapping annotation.
grafana/dashboard/dev/actor_info.py	Extended dashboard with a panel to show relation info metrics.

[Copilot]

Correct the spelling error in the comment: replace 'dummpy' with 'dummy'.

Suggested change

	/// A dummpy gauge metrics with its label to be relation info
	/// A dummy gauge metrics with its label to be relation info

[Copilot]

[nitpick] The implementations of list_table_objects, list_source_objects, and list_sink_objects share similar query logic. Consider refactoring the common parts into a helper function to improve maintainability.

Suggested change

	// Output: Vec<(table id, db name, schema name, table name, resource group)>
	pub async fn list_table_objects(
	&self,
	) -> MetaResult<Vec<(TableId, String, String, String, String)>> {
	let inner = self.inner.read().await;
	Ok(Object::find()
	.select_only()
	.join(JoinType::InnerJoin, object::Relation::Table.def())
	.join(JoinType::InnerJoin, object::Relation::Database2.def())
	.join(JoinType::InnerJoin, object::Relation::Schema2.def())
	.column(object::Column::Oid)
	.column(database::Column::Name)
	.column(schema::Column::Name)
	.column(table::Column::Name)
	.column(database::Column::ResourceGroup)
	.into_tuple()
	.all(&inner.db)
	.await?)
	// Helper function to list objects with customizable columns and relations
	async fn list_objects<T>(
	&self,
	columns: Vec<impl ColumnTrait>,
	relations: Vec<impl RelationTrait>,
	) -> MetaResult<Vec<T>> {
	let inner = self.inner.read().await;
	let mut query = Object::find().select_only();
	for relation in relations {
	query = query.join(JoinType::InnerJoin, relation.def());
	}
	for column in columns {
	query = query.column(column);
	}
	Ok(query.into_tuple().all(&inner.db).await?)
	}
	// Output: Vec<(table id, db name, schema name, table name, resource group)>
	pub async fn list_table_objects(
	&self,
	) -> MetaResult<Vec<(TableId, String, String, String, String)>> {
	self.list_objects(
	vec![
	object::Column::Oid,
	database::Column::Name,
	schema::Column::Name,
	table::Column::Name,
	database::Column::ResourceGroup,
	],
	vec![
	object::Relation::Table,
	object::Relation::Database2,
	object::Relation::Schema2,
	],
	)
	.await

[yezizp2012]

LGTM

[arkbriar]

LGTM!