distributed-trace-analysis

Distributed Trace Analysis (Chinese Version)

When to Use

You need to use traces, spans, and service topology to locate cross-service latency, error propagation, and dependency anomalies.
You need to perform a risk review of existing solutions, results, or evidence, and form actionable improvement items.
The input is incomplete, but a usable first version with assumptions and information gaps still needs to be provided first.

The default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enum values, and required items.

First read and follow prompts/distributed-trace-analysis.md 's input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, constraints, evidence, and success criteria that truly affect judgment.
First conduct an input audit, then distinguish confirmed facts, reasonable assumptions, and open questions.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or verified.
When information is insufficient, do not stop at asking questions: first deliver a limited first version, and explain which conclusions cannot currently hold.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized inputs, item-by-item expectations, and recalculation basis.
Each execution must read prompts/distributed-trace-analysis.md; it is the complete execution specification of this Skill.
When evaluating or regressing this Skill, read evals/eval.yaml and the matching evals/cases/ test cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Pin down trace/span ID, parent ID, asynchronous links, service/deployment version, start and end times, and sampling scope; verify parent-child containment and clock skew, and do not automatically treat links as synchronous parent-child relationships.
Within the same clock domain, subtract synchronous child spans by interval union to obtain observed exclusive time; overlapping child spans cannot be added together. When spans are missing, report only the visible interval and do not claim true exclusive time.
The critical path is identified based on the true dependency order and blocking waits; queue time requires enqueue/dequeue evidence, and unexplained gaps should not all be attributed to queuing.
The slowest span is only an investigation candidate; the root cause requires support from logs/metrics/fault experiments; missing spans, sampling, and clock uncertainty each limit conclusions separately.

Correlation does not equal root cause
State sampling and clock skew
Do not focus only on total elapsed time while ignoring retries and queuing
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide verification methods.
Priority must state the basis in business impact, likelihood of occurrence, or detectability.

Covered: critical path, span duration, error propagation, retry amplification, context loss, sampling bias, cross-zone dependencies, change correlation.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priorities, evidence, owners, or next steps.
The output includes verifiable judgment criteria rather than generalities.
No unauthorized production writes or destructive actions were performed.

Listing only checkpoints without stating input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of prioritization.
Replacing domain judgment with tool names or generic theory.
Rejecting outright when input is incomplete, or conversely pretending the conclusion is already certain.

Start from the paths most likely to cause business loss, security issues, or release blockers.
Use the smallest verifiable experiment to reduce uncertainty, and record the reproduction conditions.
Make the output something another engineer can directly execute and review.