investigate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Investigate

调查

You are conducting a cross-product investigation. Real investigations almost always touch more than one product — a log error leads into traces, a slow trace reveals a failing span, a failing span correlates with a specific session. Walk the evidence until you have a concrete root cause.

你正在进行跨产品调查。实际调查几乎总是涉及多个产品——日志错误关联到追踪，缓慢的追踪揭示出失败的span，失败的span与特定会话相关联。逐步梳理证据，直到找到明确的根本原因。

Prerequisites

前提条件

This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.

Required MCP tools:

```
query-logs
```
— fetch paginated log entries
```
query-traces
```
— fetch paginated trace/span entries
```
query-error-groups
```
— fetch error groups with stack traces and frequency
```
query-sessions
```
— fetch session replays with user details
```
query-aggregations
```
— bucketed aggregations across a product type for trends and counts
```
query-timeline-events
```
— pull the chronological event timeline within a session
```
get-keys
```
— discover valid attribute/grouping keys for a product type

本skill需要在你的环境中配置远程托管的LaunchDarkly MCP服务器。

必需的MCP工具：

```
query-logs
```
—— 获取分页的日志条目
```
query-traces
```
—— 获取分页的追踪/span条目
```
query-error-groups
```
—— 获取包含堆栈追踪和出现频率的错误组
```
query-sessions
```
—— 获取包含用户详情的会话重放
```
query-aggregations
```
—— 针对产品类型的分桶聚合，用于分析趋势和统计数量
```
query-timeline-events
```
—— 提取会话内按时间顺序排列的事件 timeline
```
get-keys
```
—— 发现产品类型的有效属性/分组键

Workflow

工作流程

Plan first. Before the first tool call, present a concise numbered plan of what you intend to query and why. Then execute it. Skip this only for trivial lookups.
Start narrow. Pick a focused time window (default 24h if the user didn't specify) and the most-specific identifier you have — trace ID, session ID, error group ID, flag key. Broad queries return noise.
Let each result inform the next. Do not rely on one tool call. Run multiple invocations of
```
query-logs
```
,
```
query-aggregations
```
,
```
query-traces
```
,
```
query-error-groups
```
, and
```
query-sessions
```
, using the findings of each to sharpen the next.
Respect the 50-entry limit.
```
query-logs
```
,
```
query-traces
```
,
```
query-error-groups
```
, and
```
query-sessions
```
tools return at most 50 entries per call. For larger datasets, run a
```
query-aggregations
```
query first to aggregate, then narrow with targeted fetches.
Cross-reference aggressively. Trace IDs in logs, session IDs in errors, error messages in session replays — the point where products connect is usually where the root cause sits.
Maintain a running checklist. Periodically summarize what you've confirmed vs. what you still need to test. Keeps investigations from drifting.
End with actionable output. Clear insights that answer the original question, direct references the user can click through (log excerpts, trace IDs, session IDs, error group IDs), a severity assessment, and at least one concrete remediation — a config change, a flag flip, a code-level fix with file and line, or a specific diagnostic step with the exact query to run.

先制定计划。在首次调用工具前，呈现一份简洁的编号计划，说明你打算查询的内容及原因。然后执行计划。仅在简单查询时可跳过此步骤。
从窄范围入手。选择一个聚焦的时间窗口（如果用户未指定，默认24小时）和你拥有的最具体的标识符——追踪ID、会话ID、错误组ID、标志键。宽泛的查询会返回无用信息。
让每个结果指导下一步。不要依赖单次工具调用。多次调用
```
query-logs
```
、
```
query-aggregations
```
、
```
query-traces
```
、
```
query-error-groups
```
和
```
query-sessions
```
，利用每次的发现来优化下一次查询。
遵守50条目限制。
```
query-logs
```
、
```
query-traces
```
、
```
query-error-groups
```
和
```
query-sessions
```
工具每次调用最多返回50条条目。对于更大的数据集，先运行
```
query-aggregations
```
进行聚合，再通过针对性查询缩小范围。
积极交叉引用。日志中的追踪ID、错误中的会话ID、会话重放中的错误消息——产品之间的连接点通常就是根本原因所在。
维护动态检查清单。定期总结已确认的内容和仍需测试的内容。防止调查偏离方向。
以可操作的输出收尾。清晰的见解以回答原始问题，用户可点击的直接引用（日志片段、追踪ID、会话ID、错误组ID），严重性评估，以及至少一个具体的补救措施——配置更改、标志切换、带文件和行号的代码级修复，或带有确切查询语句的特定诊断步骤。

Load companion files when relevant

Universal guidance

通用指南

Prefer aggregation over pagination. If you want to list unique users, count distinct values, or summarize, use
```
query-aggregations
```
with
```
group_by
```
— don't paginate through individual records. Use
```
get-keys
```
to discover the right grouping dimension first.
Call
get-keys
before attribute filters. Attribute names vary across product types and services (
```
spanName
```
vs
```
span_name
```
,
```
hasErrors
```
vs
```
has_errors
```
). One
```
get-keys
```
call upfront prevents wasted queries with wrong field names.
Cite specific identifiers. Every recommendation should reference the exact flag key, service name, session ID, trace ID, or file path you pulled from the data. The user should be able to act on your summary without redoing your investigation.
Handle large tool outputs. When a tool result is persisted to a file (you'll see "Output too large ... Full output saved to: <path>"), do NOT use Read — it has the same token limit. Use Bash with
```
python3
```
or
```
jq
```
to extract the specific slice you need.
Graceful degradation on tool failure. If a tool call fails (buffer overflow, timeout, server error), don't end silently. Try an alternative tool or approach. If nothing works, deliver what you've found so far plus concrete next steps the user can take manually.
Handling vague requests. "Investigate this" or "what's going on" is an invitation to dig, not to summarize. Iterate tool calls until you have a root cause or have exhausted the available data.

If a tool isn't available in your environment, the corresponding MCP server may not be connected — surface that rather than working around it.

优先选择聚合而非分页。如果你想列出唯一用户、统计不同值的数量或进行汇总，请使用带
```
group_by
```
的
```
query-aggregations
```
——不要遍历单个记录进行分页。先使用
```
get-keys
```
找到正确的分组维度。
在使用属性过滤器前调用
get-keys
。属性名称因产品类型和服务而异（
```
spanName
```
vs
```
span_name
```
，
```
hasErrors
```
vs
```
has_errors
```
）。提前调用一次
```
get-keys
```
可避免因字段名称错误而浪费查询。
引用具体标识符。每个建议都应引用你从数据中提取的确切标志键、服务名称、会话ID、追踪ID或文件路径。用户应能够根据你的总结采取行动，无需重复你的调查。
处理大型工具输出。当工具结果被保存到文件时（你会看到“Output too large ... Full output saved to: <path>”），请勿使用Read——它有相同的令牌限制。使用Bash配合
```
python3
```
或
```
jq
```
提取你需要的特定部分。
工具失败时优雅降级。如果工具调用失败（缓冲区溢出、超时、服务器错误），不要无声结束。尝试替代工具或方法。如果都不行，交付你已找到的内容，加上用户可手动执行的具体下一步操作。
处理模糊请求。“调查这个”或“发生了什么”是邀请你深入挖掘，而非总结。反复调用工具，直到找到根本原因或用尽可用数据。

如果你的环境中没有某个工具，可能对应的MCP服务器未连接——请告知用户这一点，而非尝试绕过。