---
name: manus-op-grafana
description: Query the Manus OP vida or monica cluster from the auto-oncall runtime through its exact Grafana or Prometheus metrics source and TiDB Dashboard endpoint. Use only for auto-oncall tickets whose canonical Account Alias is Manus, which explicitly name exactly one supported target, and which need read-only metrics or QPS, component logs, TopSQL, slow queries, or SQL statement summaries.
---

# Manus OP Grafana

Use the separately installed `evidence-query-planning` Skill for shared metric
scope, source-cardinality, and selector-provenance requirements. This Provider
Skill owns supported operations, actual label mappings, and transport only in
that planning boundary; its existing product-capability guidance still applies.

Under Agent9, use the `managed_auto_oncall_manus` Tool as the only provider
entrypoint. The Tool runs in a separate sandbox, receives credentials from
Agent9, and returns only bounded, sanitized evidence. Never inspect credential
environment variables or access the provider directly from the Agent Sandbox.

## Workflow

1. Read `references/op-query-contract.md` before the first query in a task.
2. Resolve exactly one target from the ticket: `vida` or `monica`. Never use a
   default or infer one target from Account Alias alone.
3. Under Agent9, call only `managed_auto_oncall_manus`. Pass the exact issue
   key, canonical Account Alias `Manus`, exact target, bounded time range, and
   one supported operation. The Tool script validates the APID key, bundled
   target, operation, and operation-specific maximum time range; never take
   current-run values from installation policy. In the temporary legacy
   runtime, use only the target-specific provider script. Its target-specific
   credentials come from the auto-oncall process environment: `vida` uses
   `MANUS_DASHBOARD_*`, `monica` uses `MANUS_MONICA_DASHBOARD_*`, and `vida`
   metrics also use `MANUS_GRAFANA_*`. Never obtain, print, or persist
   credentials from the agent.
4. Under Agent9, treat a managed Tool result or bounded provider error as the
   connectivity signal. In the legacy runtime, run `health --target <target>`.
   `vida` uses its exact Grafana datasource; `monica` uses its exact direct
   Prometheus endpoint.
5. Choose the narrowest operation and time window. OP provider queries are
   always serial to avoid query pressure. Under Agent9, invoke each selected
   managed Tool operation sequentially. In the legacy runtime, write one
   bounded batch plan and invoke `batch` exactly once; the helper executes
   every selected query and bounded retry sequentially. Do not mix managed and
   legacy calls in one Evidence Agent round:
   - `metrics` with the narrowest useful Agent-authored PromQL. When the ticket
     names an alert or incident time,
     start with the 20-minute envelope centered on it (10 minutes before and
     after). When the affected instance is known, under Agent9 pass its opaque
     `instanceRef`; the Tool applies the exact `instance` label internally. In
     the legacy batch, when the affected instance is known, include its exact `instance`
     label in PromQL before querying. Query one load-bearing metric
     at a time: the direct mechanism, its counterpart, then the strongest
     alternative.
   - `logs` for TiDB/TiKV/TiFlash/PD logs.
   - `topsql` for TopSQL; first use time-aligned metrics to select one
     affected/highest-impact instance, pass its `instanceRef`, and query only
     that instance. The provider never substitutes the first discovered
     instance. Default to 10–15 minutes and Top 10 Digests.
   - `slow_query` for slow query rows. It selects the supported
     diagnostic projection before interpreting scan, Cop wait, or RocksDB data.
     Its `Time`/`timestamp` is the finish-side log print time. The managed Tool
     uses up to 15 minutes of finish-time lookahead beyond the incident end;
     the legacy Provider Executor uses the same 15-minute bound. Both derive
     `start_time=finish_time-query_time` and return only executions that overlap
     the original incident window. Never treat raw timestamp as query onset or
     interval overlap as causal proof.
   - `statements` for aggregated SQL statements.
6. Summarize only compact JSON. Returned instance addresses, SQL, PromQL and
   diagnostic specifications are retained; credentials remain redacted.
   Under Agent9, treat opaque instance references
   as selectors only; never decode or describe them as addresses, and do not
   expect raw payloads in the Agent workspace. In the legacy runtime, the
   `batch` helper owns distinct query-specific output directories and one
   atomic batch result. Do not open or deserialize the complete raw payload
   merely because a field is absent; plan one narrower exact-instance,
   Digest, or field query or record a bounded provider limitation. Legacy
   batch arguments may be nested under `params` or placed directly on the
   query; the helper normalizes supported names and ignores planning metadata.

### Legacy batch plan contract

When runner-owned `comparisonWindows` is present for a `workload-hotspot`
refinement, plan exactly seven independent `metrics` entries. Each entry must
use one exact daily `start`/`end` pair from that list with identical metric
semantics, entity grouping, unit, aggregation, and step. One batch is a
transport container only; never replace the entries with one multi-day range.

For the Kubernetes Provider Executor, write exactly one
`auto-oncall-op-query-batch-plan-v1` object. The top level requires
`schemaVersion`, `provider="manus"`, the exact runner-owned `scenarioId`,
`timeWindow`, and `target`, plus `queries`. Copy the runner-owned target exactly;
it must be the single literal `vida` or `monica`. Never derive or default it in
the plan.

Each query requires a unique semantic `queryId`, one `operation`, and `params`.
Use at most 12 selected queries. Supported operations are:

- `metrics`: `params` requires `name` and PromQL `query`; optional `step`,
  `unit`, `start`, and `end`.
- `dashboard`: `params` requires `kind=topsql|slow-query|statements`; optional
  `limit`, `previewLimit`, `text`, `fields`, `instance`, `instanceType`,
  `groupBy`, `window`, `start`, and `end`. A `kind=slow-query` query may also
  contain an ordered `handoffFields` array with at most 12 safe field names.
- `logs`: `params` may contain `component`, `level`, up to three `keywords`,
  `limit`, `targetLimit`, `pollTimeout`, `pollInterval`, `start`, and `end`.

All query windows must stay inside the runner-owned finite window. The helper
executes queries and bounded retries strictly serially and writes one atomic
`auto-oncall-op-query-batch-v1` result.

### Metrics timeout recovery

- A `metrics` invocation performs one query at a time. On a timeout or HTTP
  504, the client retries that same PromQL against that same target at most
  once, using the centered half of the original window. Do not widen the
  window, change targets, remove an instance filter, or start the retry until
  the original attempt has failed. Never run duplicate retries for the same
  timed-out PromQL concurrently.
- Keep every successful metric result in the evidence chain. If the bounded
  retry also fails, mark only that metric dimension `unverified`; do not call
  Grafana, Prometheus, the Manus provider, or the whole diagnosis unavailable.
- Stop after the direct mechanism, counterpart, and strongest alternative are
  sufficient for a bounded conclusion. Do not run a metric inventory.
- TiKV pending scheduler commands use the historical exported metric name
  `tikv_scheduler_contex_total`. Do not query the nonexistent
  `tikv_scheduler_pending_commands` metric.

### Evidence Agent semantic repair

After deterministic provider retries, return an executed-query semantic error
to the same Evidence Agent thread. It may rewrite the failed load-bearing
objective up to four times in the same acquisition round, including its query,
aggregation, labels, bounded window, step, ordering, projection, or supported
surface. Preserve the exact target and diagnostic question. Stop when the
failed query is non-load-bearing, already answered, unsupported, or has no
bounded changed plan; never execute an unchanged plan. For every metric plan,
set `emptyResultExpectation` to `expected_non_empty`, `sparse_allowed`, or
`unknown`. Use the first only for a common baseline that this skill establishes
for the exact target/component and window; use the second only for a
legitimately sparse event/condition metric whose exact selector/label contract
is established here. Otherwise use `unknown`.

A successful expected-baseline empty gets one same-round, same-family, minimal
selector/label validation. If it remains empty, preserve an unexplained gap and
never use it as counter-evidence. A sparse empty is verified only under the
trusted contract above. A rejected or nonexistent metric family remains failed.

## Managed Tool operations

- `metrics`: accepts Agent-authored PromQL. When using an opaque `instanceRef`
  returned by an earlier metrics call, place the literal `{{instance}}` where
  the PromQL string value should be inserted, for example
  `metric_name{instance={{instance}}}`.
- `topsql`: requires an opaque `instanceRef` selected from time-aligned metrics.
- `slow_query` and `statements`: accept only a bounded time range, result limit,
  and short filter.
- `logs`: accepts one component, one level, and at most three short keywords.

The legacy `scripts/manus_op_grafana.py` entrypoint remains temporarily for the
pre-Agent9 Auto-oncall runtime. It must not be installed in the Agent9 Agent
Sandbox and should be removed only after both Manus targets pass the managed
Tool staging rollout.

## Legacy runtime

Run the legacy script only inside the allowlisted auto-oncall workload:

```bash
python3 scripts/manus_op_grafana.py health --target vida
python3 scripts/manus_op_grafana.py health --target monica
python3 scripts/manus_op_grafana.py batch \
  evidence/scenarios/query-execution/op-query-context.json \
  evidence/scenarios/query-execution/op-query-plan.json \
  evidence/scenarios/query-execution/op-query-batch.json
```

## Examples

```bash
python3 scripts/manus_op_grafana.py metrics --target vida \
  --name qps --query 'sum(rate(tidb_server_query_total[2m]))' --last 1h --step 60 --unit qps

python3 scripts/manus_op_grafana.py metrics --target vida \
  --name pending-commands \
  --query 'max(tikv_scheduler_contex_total{instance="10.0.0.8:20160"})' \
  --start 1784599200 --end 1784600400 --step 30 --unit commands

python3 scripts/manus_op_grafana.py logs --target vida \
  --component tidb --level error --last 15m --keyword timeout --limit 20

python3 scripts/manus_op_grafana.py dashboard --target vida --kind topsql \
  --instance 10.0.0.8:10080 --last 10m --limit 10
python3 scripts/manus_op_grafana.py dashboard --target vida --kind slow-query --last 30m --limit 20
python3 scripts/manus_op_grafana.py dashboard --target vida --kind statements --last 30m --preview-limit 20
python3 scripts/manus_op_grafana.py metrics --target monica \
  --name qps --query 'sum(rate(tidb_server_query_total[2m]))' --last 30m --step 60 --unit qps
python3 scripts/manus_op_grafana.py dashboard --target monica --kind slow-query --last 30m --limit 20
```

For Slow Query, the Provider Executor reads `/api/slow_query/available_fields`,
intersects the safe core plus Evidence Agent-selected `handoffFields`, and
passes the result as `fields` to
`/api/slow_query/list`. The projection includes `process_keys`, `total_keys`,
Cop processing/wait timing, backoff, and RocksDB counters required by
`tidb-query-tuning`. Treat `field_selection.unsupported_fields` as unavailable,
never as zero. Use `--fields` only for a narrower explicit projection; large
plan payloads are not selected by default.

Use `handoffFields` only for facts that answer the current Scenario Diagnostic
Agent question or distinguish its strongest alternative. Identity, digest
prefix, instance, finish timestamp, derived execution interval/overlap, and
`query_time` are always preserved. Choose among statistics freshness; Cop
max/address pairs; memory/spill; RU/resource-control delay; scan/RocksDB;
lock/backoff; and optimizer-phase timing. Do not request every field.

## Boundaries

- Resolve `vida` metrics only from its exact Grafana datasource and `monica`
  metrics only from its configured direct Prometheus endpoint. Do not fall back
  to Grafana's default datasource or another cluster.
- Require an explicit `--target vida|monica` for every command. Never default
  between clusters or retry one target against the other target's endpoint.
- Refuse use outside the auto-oncall runtime or for a ticket whose canonical Account Alias is not exact case-insensitive `Manus`.
- Dashboard login uses its published RSA key and keeps the bearer token in memory only.
- Log search creates the Dashboard's required temporary task group, polls it, and reads preview rows. Do not cancel, retry, or delete task groups automatically.
- Never include passwords, basic-auth headers, bearer tokens, or cookies in stdout, exceptions, or evidence.
- Never diagnose MVCC or scan amplification from raw zero values for fields that
  were not present in `field_selection.requested_fields`.
- Do not use Clinic APIs for this OP cluster.