用途：为 Honeycomb 中的生产问题排查提供结构化工具调用顺序与结果解读方法，目标是定位根因。核心分析循环为定义、可视化、调查、评估；若 BubbleUp 无有效结果，通常是插桩缺失，可补充属性后重试。
主要步骤：一、准备阶段，调用 get_workspace_context 了解环境与数据集，get_slos 检查 SLO 违规，get_triggers 查看告警，find_queries 查找历史排查；二、问题刻画，运行宽查询观察问题形态，延迟尖峰用 P99(duration_ms)、HEATMAP(duration_ms) 按服务或路由分组，错误激增按服务、路由、类别统计 error=true 的失败操作 span，并单独统计 event.name=exception 且 exception.type exists 的异常事件行，再采样 trace.trace_id 下钻；未知问题按 service.name 分组 COUNT 找异常量服务；同时调用 get_service_map 查看服务间 P95 延迟。三、BubbleUp 找差异，对异常区域运行 run_bubbleup，比较离群与基线分布，分类字段值过度代表指向原因，数值字段分布偏移显示相关指标。四、下钻 Trace，用 BubbleUp 发现作为 WHERE 过滤，取代表性 trace ID 调用 get_trace，查看耗时异常 span、可并行的顺序 span、错误 span、子 span 间隙和服务边界。五、验证假设，用包含与不包含疑似原因的查询对比，指标分化即确认。六、记录发现，调用 create_board 写入根因摘要、关键查询 run PK 和相关 SLO。
异常数据处理：操作失败属于 span（error=true、span 状态、低基数 exception.slug/error category）；完整异常诊断可能位于与 trace 关联的 Logs API 事件行，不要假设父 span 上存在 exception.。排查异常应先发现数据集 schema，查询 event.name=exception 且 exception.type exists、trace.trace_id exists，采样后将其 trace.trace_id 传给 get_trace(show_events=true)。旧式 span 事件异常还需检查 name=exception 和 meta.signal_type=trace；Logs API 事件使用 event.name/body 和 meta.signal_type=log。若服务使用异常提升的 LogRecordProcessor，部分 exception. 字段可能出现在父 span 上，这属于客户端兼容特性而非 Honeycomb 保证，事件行仍是完整诊断的权威来源，父 span 字段缺失不代表异常事件缺失。
典型模式：延迟尖峰先 HEATMAP 再 BubbleUp 慢区域、追踪慢请求、用过滤查询验证；错误激增按服务/路由/类别统计失败 span，再统计 Logs API 异常事件，采样 trace.trace_id，调用 get_trace(show_events=true)，最后过滤验证；部署回归按 deployment.version 分组 P99，比较新旧版本 BubbleUp，追踪新版本；依赖故障用 get_service_map、慢依赖 P99、关系查询（any.service.name）衡量用户影响并追踪受影响请求。
限制与注意事项：即使认为原因明显也应遵循工作流，避免跳过 BubbleUp、过早认定部署问题、仅凭单条 trace 下结论或用“问题简单”为由省略验证。结果为空时检查字段名（find_columns）、扩大时间范围、核对环境与数据集；BubbleUp 无信号时可更换时间选择、增加过滤或更换计算；trace 缺少 span 可能是采样、插桩缺失或跨环境 trace 拆分。参考资料包括排查手册、BubbleUp 指南和 Trace 探索文档；概念基础见 observability-fundamentals，查询构建见 query-patterns，SLO/触发器见 slos-and-triggers。平台、收费、价格等信息暂未提供。