Vtadmin monitoring integration

[c-r-dev]

Description

This PR implements the frontend support for integrating external monitoring tools (like Grafana and PMM) directly into VTAdmin, addressing some of the goals outlined in RFC: Integrate PMM into vtadmin (#11191).

Added a flexible, configuration-driven mechanism to link VTAdmin entities (Clusters, Tablets, Gates) to external dashboards. This allows VTAdmin to serve as a "single view" for Vitess operations, enabling users to navigate seamlessly from topology views to deep-dive metrics.

Introduced new environment variables to define dashboard URL patterns. These templates support dynamic placeholders that are replaced with context-specific data at runtime.

• VITE_VITESS_MONITORING_CLUSTER_TEMPLATE: For cluster-level metrics.
• VITE_VITESS_MONITORING_VTTABLET_TEMPLATE: For tablet metrics.
• VITE_VITESS_MONITORING_VTGATE_TEMPLATE: For vtgate metrics.
• VITE_MYSQL_MONITORING_TEMPLATE: For underlying MySQL instance metrics (e.g., PMM).

Supported Placeholders: {cluster}, {keyspace}, {shard}, {alias}, {hostname}, {type}, {cell}, {pool}.

UI Integration

• VTClusters View: Added a column linking to the cluster dashboard (Grafana) with metrics from vtctld.
• Gates View: Added a column linkting to the VTGates dashboard (Grafana) with metrics from vtgate.
• Tablets View: Added a columns linkting to the Tablet metrics dashboard (Grafana) and MySQL metrics dashboard (PMM).
• Context-Aware: Links are only rendered if the corresponding environment variable is configured.

Demo & Verification

To demonstrate this functionality and provide a reference implementation, I have updated the examples/vtadmin directory.

• Co-deployed Stack: The example now includes a docker-compose setup with Prometheus, Grafana, and PMM running alongside Vitess.
• Pre-configuration: The example docker-compose.yml is pre-wired with the new VITE_ variables to link VTAdmin to the local monitoring stack.

cd examples/vtadmin
make up

monitoring_links_demo.mp4

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

• Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

• Apply the release notes (needs details) label if users need to know about this change.
• New features should be documented.
• There should be some code comments as to why things are implemented the way they are.
• There should be a comment at the top of each new or modified test to explain what the test does.

New flags

• Is this flag really necessary?
• Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
• vtctl command output order should be stable and awk-able.