# Feishu Template Hints: Serverless Shared Pools

## Document

- Title: `TiDBCloud Serverless Daily Inspection - <pool> - YYYY-MM-DD`
  (multi-day: `TiDBCloud Serverless Daily Inspection - <pool> - YYYY-MM-DD to YYYY-MM-DD`).
  The pool (cluster) name is mandatory in the title; multi-pool reports list
  every pool name in `--pool` order, separated by `+`.
- Always create a NEW document per report run; never overwrite, update, or
  append to an existing report document.
- Do not duplicate the title as a body H1.
- Use English and omit screenshots.
- A single-date report contains one section per inspected shared pool.
- A multi-day report contains one section per inspected shared pool. Within that
  section, each chapter is an item × date table: rows are stable inspection
  items/rules and columns are the independently inspected local dates. Do not
  average, merge, or otherwise reinterpret results across dates.

## Pool Header

Every pool section must identify:

- inspection window
- full Grafana `control_plane_info` routing identity; metrics use its derived two-segment label
- `k8s_cluster_info`
- scope: **pool-wide shared Serverless TiKV**, not a logical cluster or tenant
- fixed metric scope: `namespace="tidb-serverless"`, `component="tikv"`
- fixed log scope: `cluster="<k8s_cluster_info>"`, `namespace="tidb-serverless"`, `container="tikv-log"`; `control_plane_info` is parent-API routing, not a LogQL label
- dashboard: `Starter-Essential-TiKV-Details-for-Clinic` (UID `_eCx0ZDvz`)

## Section Order

1. Summary
2. Key Findings
3. Error Signals
4. gRPC QPS and Latency
5. CPU and Memory
6. Critical Thread Pool CPU
7. Disk Usage and Region Count
8. Disk Load
9. Compaction
10. ERROR/WARN Logs
11. Follow-up Investigation

For a multi-day report, retain this order. Render Summary, Key Findings, every
rule chapter, and Follow-up Investigation as item × date tables. In the
gRPC chapter, expand G1 into four stable rows: `gRPC message rate (read, max)`,
`gRPC message rate (read, avg)`, `gRPC message rate (write, max)`, and
`gRPC message rate (write, avg)`. Each cell reports messages per second from
1-minute rates by the required request types; do not render a full-window
request count. In the
Compaction chapter, the K3 cell lists the date's window total plus every
container/result count for that date (`0.00` when no compaction results were
observed). In
`ERROR/WARN Logs`, also render one separate `Content × Count` Top 10 table per
date/window, ordered by count descending and then content ascending. Treat the log
query limit as a lower bound, not a total-count comparison between dates.

In the `Critical Thread Pool CPU` chapter, expand T1 into the complete ordered
dashboard group catalog from [inspection rules](inspection-rules.md#thread-groups).
For a single-day report, render an `Item × Observation` table with one row named
`T1 — <group>` per group. For a multi-day report, render those same rows across
the date/window columns. Each known cell is exactly `max: <value> cores, avg:
<value> cores`, calculated from the per-instance
`sum by (instance) (rate(tikv_thread_cpu_seconds_total{...}[5m]))` query-range
samples. `max` is the maximum of the observed instances' per-window maxima;
`avg` is the arithmetic mean of their per-window averages. Do not render
instance names or individual instance values. A successful empty group is `No
observed instances; max: 0.00 cores, avg: 0.00 cores`; an individual query error,
malformed group, or group series without an `instance` label is `Unknown:
<reason>`. A successful empty group is known zero internally and omitted. Omit
another known group row only when `max` is below `0.10` CPU cores; `0.10` remains
visible. In multi-day tables, omit a row only when every displayed window is
known and below that line. If an empty window shares a row with another window at
or above `0.10`, retain the row for date-column alignment and render the empty
cell as `No observed instances; max: 0.00 cores, avg: 0.00 cores`. Always retain
a group with missing, malformed, or failed telemetry. T1 has no threshold warning.

## Status Language

Use concise reviewer-facing English:

- Healthy: no warning/error findings and no unavailable required check
- Warning: pool-wide pressure requires continued watch
- Error: error-level signal requires immediate pool investigation
- Needs Review: one or more required checks are unexpectedly `Unknown`
  (API/query errors or malformed responses); structurally unavailable
  placeholder rules such as D8 stay `Unknown` in their own rows but never
  trigger Needs Review, Summary unknown-rule lists, or follow-up actions

Never describe an unavailable metric as zero, absent, or healthy. Do not use
Dedicated node-topology, storage-device, tenant, keyspace, or logical-cluster
language in a pool section.

For Prometheus-backed rules, a successful empty result is known zero/healthy;
only API/query errors and malformed non-empty responses are `Unknown`. D8
remains unavailable/`Unknown` because its signal is unsupported.