kubeblocks-observability-router

Route observability decisions for KubeBlocks-managed databases using the capability matrix.

3|Updated Mar 12, 2026
One-click install
npx skills add https://github.com/apecloud/kubeblocks-skills --skill kubeblocks-observability-router
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kubeblocks-observability-router
Source: https://github.com/apecloud/kubeblocks-skills/tree/main/skills/kubeblocks-observability-router
Command: npx skills add https://github.com/apecloud/kubeblocks-skills --skill kubeblocks-observability-router

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The Observability Router decides how to handle monitoring needs for KubeBlocks-managed databases, routing requests to the most appropriate observability path and ensuring accurate readiness reporting.

Core Features & Use Cases

  • Uses the observability-capability-matrix as the truth source to determine exporter, scrape, dashboard, and alerting readiness levels.
  • Routes requests to kubeblocks-observability-existing-stack when Prometheus/Grafana already exists.
  • Routes requests to kubeblocks-observability-bootstrap-stack when no monitoring base is present but exporter evidence exists.
  • Routes to kubeblocks-troubleshoot when evidence is unclear or live state disagrees with the matrix.
  • Always report current state as none, metrics-ready, scrape-ready, dashboard-ready, or alerting-ready.

Quick Start

State your current monitoring state and ask the router to guide the next action.

Frequently Asked Questions about kubeblocks-observability-router

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I route KubeBlocks database observability requests when monitoring infrastructure already exists?

Route KubeBlocks observability requests to the existing-stack path when Prometheus or Grafana is already present. The router checks the observability capability matrix to validate exporter, scrape, dashboard, and alerting readiness before directing requests accordingly.

What is the best way to set up monitoring for KubeBlocks databases if no monitoring base is installed?

Setting up monitoring for KubeBlocks databases without an existing base uses the bootstrap-stack path. The router directs requests here when exporter evidence exists but no Prometheus or Grafana infrastructure is currently deployed.

How does KubeBlocks observability routing determine if database metrics are ready for scraping?

KubeBlocks observability routing determines metrics readiness by validating evidence against the observability capability matrix. It reports the current state precisely as none, metrics-ready, scrape-ready, dashboard-ready, or alerting-ready based on this validation.

Why does my KubeBlocks monitoring state disagree with the expected readiness level?

Monitoring state disagreements occur when live state conflicts with the observability capability matrix. The router defers these inconclusive evidence cases to the troubleshoot path to investigate and resolve the readiness discrepancy.

Do I need an existing Prometheus stack to use KubeBlocks observability routing?

An existing Prometheus stack is not required for KubeBlocks observability routing. The router handles three scenarios: existing-stack, bootstrap-stack when no monitoring base is present, and troubleshoot paths when evidence is unclear.