一键导入
observability
Investigate production issues using logs, traces, and errors — how to triage, correlate signals, and know when to escalate.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Investigate production issues using logs, traces, and errors — how to triage, correlate signals, and know when to escalate.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
OpenCode agent runtime — manage sessions, dispatch tasks, repair DB issues, and reset diffs
Look up people, projects, products, and decisions locally first: contact info (email, Slack ID, GitHub handle), titles and teams, project/product status, who works on what, and past decisions. Check before searching Slack, email, calendar, or GitHub — this is the first stop for any contact detail, project context, or decision-history question.
Load when reviewing a diff, naming a code smell or anti-pattern, deciding refactoring direction, or grading review-comment severity. Required reading when a named pattern is cited — load explicitly rather than paraphrasing from memory.
Load before creating, restacking, or landing a branch in a git-spice–managed stack — branch naming, stack navigation, and conflict/restack recovery. Use instead of raw git commands whenever the repo has a git-spice stack.
Load when investigating production errors, latency, or trace data that requires querying Elasticsearch/APM directly — index patterns, field names, auth setup, and time-range syntax. Use before hand-rolling a query DSL call or guessing field names.
Manage dotfiles via chezmoi — apply safely, destroy files, manage LaunchAgents and externals, config and template gotchas
| name | observability |
| description | Investigate production issues using logs, traces, and errors — how to triage, correlate signals, and know when to escalate. |
| license | MIT |
Use this skill to investigate production problems. For query syntax, index patterns, and example queries, consult the log query reference.
Start with the symptom, not the tool. Before querying anything:
This prevents aimless log-scrolling and makes findings interpretable.
Work top-down — coarser signals first, drill into finer ones only when needed:
| Signal | What it tells you | When to use |
|---|---|---|
| Error rate / rate spike | Something broke at scale | First check — confirms the problem is real |
| APM traces | Which transaction is slow or failing, full call chain | Once you know the scope |
| APM errors | Exception type, stack trace, grouping key | When you need the root cause code path |
| Logs | Raw context around a specific event | When traces don't have enough detail |
Don't start with logs. Start with traces or error groups, then use trace.id to pull the surrounding log context.
The trace.id field links all three indices (logs-*, traces-apm*, logs-apm.error-*). Once you have a trace.id from an error or slow trace, use it to pull all logs from that same request:
{"term": {"trace.id": "<trace-id-here>"}}
Before querying, write down what a "confirmed" answer looks like. Examples:
This prevents misreading absence of evidence as evidence of absence.
Stop investigating and escalate to the team when:
| Symptom | Where to look first |
|---|---|
| Slow page loads | APM traces — sort by transaction.duration.us desc |
| 500 errors spiking | APM errors — group by error.grouping_key |
| One user affected | Logs — filter by user ID or session ID |
| Periodic issue | Logs — look for time pattern in @timestamp |
| After a deploy | APM errors — filter by @timestamp after deploy time |