该技能用于指导在 Honeycomb 的追踪（trace）与事件数据集上编写和解读查询，重点讲“何时、为何”使用某种模式，而非工具调用方式。
用途：帮助分析延迟、流量、错误与分布等问题，避免用错误聚合掩盖真实情况。
主要原则：延迟不要用 AVG，应使用 P99（或 P95/P90）；分布用 HEATMAP 以发现双峰；可在一条查询中组合 COUNT、P99(duration_ms)、HEATMAP(duration_ms)；先宽后窄，先用 COUNT/GROUP BY 了解形态再加 WHERE；写新查询前先调用 find_queries 查看已有工作。
操作选择：流量用 COUNT 按 route/service 分组；唯一用户用 COUNT_DISTINCT；多数用户体验用 P50；最差体验用 P99；双峰用 HEATMAP；最坏情况用 MAX；并发用 CONCURRENCY；是否恶化用 RATE_AVG。
关系型字段：用 any.service.name 找出某下游参与的追踪并按 root.http.route 分组；用 any.error = true 按 root.name 分组查看错误入口；用 none.service.name = "health-check" 排除噪声。
计算字段：为按事件求值的表达式，分查询级（不保存）、数据集级、环境级三种范围，应选最窄范围。常见模式包括错误率 MUL(IF($error, 1, 0), 100)、状态分类、延迟分桶 BUCKET($duration_ms, 500, 0, 3000)、前缀路由，精确匹配用 SWITCH。注意：不要创建仅重命名的展示字段；避免对长字段做正则，必要时先用 CONTAINS；EQUALS 有严格类型匹配，先用 find_columns 确认类型；FORMAT_TIME 开销大；一次性工作保存为查询级。
每次查询前：测量用户侧延迟时过滤 is_root；使用人类可读时间范围；先用 find_columns 校验字段。
结果解读：元数据中 query_result_json 是原始 JSON 的签名 URL，可用 jq 或 python 解析；P99/P50 超过 10 倍可能双峰；TOTAL 为聚合，OTHER 为超出限制的分组；ASCII 热力图两带表示两个群体；query_run_pk 可直接传给 run_bubbleup 做异常分析。
限制与暂未提供：官方未提供具体收费、平台支持范围或安装命令；技能引用的详细语法与示例位于本地参考文件中，此处不展开。