Investigating With Observability

Troubleshooting with Observability Skills

Core Principle

Random querying wastes time and produces misleading results. Empty results from wrong metric names look identical to "no problem exists." Jumping between signals without a hypothesis leads to thrashing.

Discover before you query. Hypothesize before you correlate. Confirm before you conclude.

If you haven't completed Phase 1, you cannot propose root causes. If you haven't correlated across at least two signal types, your conclusion is a guess.

The Investigation Protocol

Complete each phase before proceeding to the next.

Phase 1: Gather Signals     → What's already known? What's alerting?
Phase 2: Discover and Scope  → What data exists? What are the real names?
Phase 3: Hypothesize and Test → Form one theory, query to confirm or refute
Phase 4: Correlate and Confirm → Cross-reference across signal types, find root cause

Phase 1: Gather Signals

Before writing any query, establish what's already known.

1. Check env var availability — run the gating check from the Subagent Dispatch section.

2. Dispatch signal-gathering subagents in parallel:

If VM_ALERTMANAGER_URL IS available, the AlertManager check agent handles BOTH VM alerts and AlertManager queries — no need to dispatch a separate metrics agent for alerts.

Read the agent prompt files and dispatch in a single Agent tool call. Include in each subagent's prompt:

• The agent file content
• The investigation target (namespace, service, or component name if known)

3. Synthesize results — once subagents return:

• Combine alert findings from all sources
• Establish a timeline: when did symptoms start? What changed?
• If timeline is unclear, ask the user

4. Identify which signal type to start with:

Phase 2: Discover and Scope

Never guess metric names, log field names, or service names. Discovery is not optional — it prevents the single most common investigation failure: drawing conclusions from empty results caused by wrong names.

Dispatch discovery subagents in parallel for ALL available backends. Read each agent prompt file and dispatch in a single Agent tool call. Include in each subagent's prompt:

• The agent file content
• Target namespace and/or service name (from Phase 1 findings)
• Time range for the investigation (RFC3339 format)
• Any specific keywords or components to search for

Synthesize discovery results:

• Merge discovered names across all backends
• Note which backends have data for the target and which don't
• Identify the richest signal source for Phase 3 hypothesis testing

Consult skill references for complex queries. You do NOT know LogsQL syntax from training data — it is NOT Loki LogQL. For complex queries beyond what the subagents already ran, invoke the corresponding *-query skill or use the LogsQL Quick Reference below.

Phase 3: Hypothesize and Test

After discovery, form a specific hypothesis before querying further.

State it clearly: "I think [component X] is [failing/slow/OOM] because [evidence Y from Phase 1]."

Test minimally:

• Query ONE thing to confirm or refute the hypothesis
• Don't query everything at once — you'll drown in data
• Use instant queries first (cheaper, faster) before range queries

If the hypothesis is wrong:

• Don't add more queries on top — form a NEW hypothesis
• Re-examine what Phase 1 and Phase 2 revealed
• Ask: did discovery show anything unexpected?

After 3 failed hypotheses: STOP. Three wrong guesses means you're missing something fundamental. Either:

• A key data source hasn't been discovered yet
• The scope is wrong (different namespace, different service, different time range)
• You need to ask the user for more context

Phase 4: Correlate and Confirm

A single signal type is not proof. Correlate across at least two before concluding.

Dispatch correlation subagents in parallel for the signal types you need. Reuse the same agent prompt files from agents/, but provide specific queries rather than discovery tasks. Include in each subagent's prompt:

• The agent file content
• The specific query to run (metric expression, log filter, trace search parameters)
• The exact time range to query (narrowed from Phase 3 findings)
• What to look for (the confirmed hypothesis from Phase 3)

Example parallel dispatch for correlation:

• Metrics agent: "Query rate(http_requests_total{code=~'5..', namespace='myapp'}[5m]) from T1 to T2"
• Logs agent: "Search {namespace='myapp'} error from T1 to T2, return sample messages"
• Traces agent: "Search traces for service myapp with minDuration=1s from T1 to T2"

Correlation techniques:

• Time-based: Identify anomaly timestamp in metrics, query logs/traces at that time
• Trace ID: Find trace IDs in traces, search logs for trace_id:"<id>"
• Pod name: Get pod name from metrics labels, use it in log stream filters

Only after correlation: propose root cause and remediation.

Red Flags — STOP and Return to Phase 1

If you catch yourself:

• Proposing a root cause after querying only one signal type
• Writing a LogsQL query from memory without checking syntax
• Querying a metric name you haven't confirmed exists via discovery
• Getting empty results and concluding "no problem"
• Skipping the alerts check because "it's probably not that"
• Running five different queries hoping one shows something
• Saying "let me just try..." instead of forming a hypothesis

All of these mean: STOP. You're guessing, not investigating.

Common Rationalizations

Environment

Environment is controlled by env vars. Check current state:

echo "VM_METRICS_URL:      $VM_METRICS_URL"
echo "VM_LOGS_URL:         $VM_LOGS_URL"
echo "VM_TRACES_URL:       $VM_TRACES_URL"
echo "VM_ALERTMANAGER_URL: $VM_ALERTMANAGER_URL"
echo "VM_CURL_CONFIG:      ${VM_CURL_CONFIG:-(unset - no auth)}"

If unsure which environment the application runs in, ask user.

Subagent Dispatch

This skill dispatches parallel subagents at phase boundaries to speed up investigations. Each subagent carries embedded API reference and returns structured findings.

Env Var Gating

Before each dispatch round, check which backends are available:

echo "METRICS:${VM_METRICS_URL:+available}"
echo "LOGS:${VM_LOGS_URL:+available}"
echo "TRACES:${VM_TRACES_URL:+available}"
echo "ALERTMANAGER:${VM_ALERTMANAGER_URL:+available}"

Only dispatch subagents for backends that report available. Do not dispatch a subagent if its env var is empty or unset.

How to Dispatch

1. Read the agent prompt file from the agents/ directory (relative to this skill's directory)
2. Use the Agent tool to dispatch, including:
   • The agent prompt file content as the base instructions
   • Investigation context: target namespace, service name, time range (RFC3339)
   • Any specific queries or metrics to look for
3. Dispatch independent subagents in the SAME tool-call message for parallel execution
4. Set allowed-tools: Bash(curl:*), Bash(jq:*), Bash(date:*) on each subagent

Agent Files

Skill-to-API Mapping

victoriametrics-query  = Metrics only (MetricsQL/PromQL) → $VM_METRICS_URL
victorialogs-query     = Logs only (LogsQL)              → $VM_LOGS_URL
victoriatraces-query   = Traces only (Jaeger API)        → $VM_TRACES_URL
alertmanager-query     = AlertManager (silences, routing) → $VM_ALERTMANAGER_URL

Never cross APIs between backends. Use the correct env var and endpoint for each data type.

AlertManager provides what VM alerts cannot: silences and inhibition state. But it's in-cluster and may be down — fall back to $VM_METRICS_URL/api/v1/alerts when unavailable.

Timestamp Formats

VictoriaLogs start is always required — omitting it scans ALL stored data (extremely expensive).

Discovery Protocol

Follow this order for each signal type. For full API details and additional endpoints, invoke the corresponding query skill.

Metrics Discovery → victoriametrics-query skill

1. Search metadata by keyword: $VM_METRICS_URL/api/v1/metadata?metric=<keyword>&limit=10
2. Label values for scoping: $VM_METRICS_URL/api/v1/label/<label_name>/values (filter with match[])
3. Series for a namespace: $VM_METRICS_URL/api/v1/series?limit=20 with match[]={namespace="X"}
4. Then query — instant at api/v1/query or range at api/v1/query_range (range requires start, RFC3339)

Logs Discovery → victorialogs-query skill

ALL VictoriaLogs endpoints require start (RFC3339). Use --data-urlencode for the query parameter.

1. Stream field names: $VM_LOGS_URL/select/logsql/stream_field_names?start=<RFC3339>
2. Stream field values: $VM_LOGS_URL/select/logsql/stream_field_values?start=<RFC3339>&field=namespace
3. Facets (best discovery tool — all field distributions in one call): $VM_LOGS_URL/select/logsql/facets?start=<RFC3339>
4. Non-stream field names: $VM_LOGS_URL/select/logsql/field_names?start=<RFC3339>
5. Then query (JSON Lines response): $VM_LOGS_URL/select/logsql/query?start=<RFC3339>&limit=100

Traces Discovery → victoriatraces-query skill

Trace discovery endpoints accept NO time-range parameters:

1. List services: $VM_TRACES_URL/api/services
2. Operations for a service: $VM_TRACES_URL/api/services/<service>/operations
3. Dependencies (Unix milliseconds, 13 digits): $VM_TRACES_URL/api/dependencies?endTs=<ms>&lookback=3600000
4. Then search traces (service required, times in Unix microseconds, 16 digits): $VM_TRACES_URL/api/traces?service=<svc>&start=<µs>&end=<µs>&limit=20

LogsQL Quick Reference

For full LogsQL syntax, invoke the victorialogs-query skill. Key points:

• LogsQL is space-separated (AND by default). Pipes use |.
• Stream filters: {namespace="myapp"}
• Word filters: {namespace="myapp"} error
• OR: (error OR warning), Regex: ~"err|warn", Field-specific: level:error
• Time filter: _time:1h (alternative to API start/end params — use one OR the other, never both)
• Negation: -"expected error"
• Stats: | stats by (level) count() as total

Common mistakes: | grep does NOT exist (use word filters or ~"regex"). | filter is valid ONLY after | stats. Stream field names depend on ingestion config — discover them first.

Investigation Playbooks

"Application is slow"

1. Phase 1: Check alerts. Establish timeline — when did latency increase?
2. Phase 2: Discover traced services and metrics matching the app
3. Phase 3: Hypothesize — "latency is in [service X] based on [alert/user report]"
   • Query latency/error rate metrics for that service
   • Search traces with minDuration filter to find slow spans
4. Phase 4: Correlate trace timestamps with logs around those times

"Pod crash looping"

1. Phase 1: Check alerts (may already show KubePodCrashLooping). Get pod name.
2. Phase 2: Discover metrics for restart counts, memory usage. Discover log streams for the pod.
3. Phase 3: Hypothesize — OOM? Liveness probe failure? Startup crash?
   • Regular interval crashes → liveness probe. Memory spike before crash → OOM.
4. Phase 4: Correlate error logs with metric timestamps to confirm cause.

"Resource growing"

1. Phase 1: Check alerts. How fast is it growing?
2. Phase 2: Discover resource usage metrics for the namespace/pod
3. Phase 3: Hypothesize — leak? Increased load? Missing limits?
   • Use deriv() or increase() to quantify growth rate
   • Check per-pod breakdown to isolate the culprit
4. Phase 4: Correlate with deployment events in logs. Did growth start after a deploy?

Common Mistakes