LangWatch 仪表盘实战从 Trace 数据到可共享报表的 5 步搭建法【免费下载链接】langwatchOpen-Source Agent Observability Evals for AI Platform teams. Trace, test, route and govern every agent coding assistant in the company.项目地址: https://gitcode.com/GitHub_Trending/la/langwatch这是一篇 LangWatch 数据可视化 实战教程以AI 应用上线第一周为场景带你一步步搭出 AI 应用监控 仪表盘——从选图表类型、配指标到设阈值告警、保存共享报表全程可直接复用。上线第一周先想清楚要回答哪 3 个问题AI 应用刚上线时数据会迅速堆积海量 Trace、大量用户会话、密集的模型调用。逐条翻 Trace 谁也翻不完这时候你需要的不是更多数据而是一个能回答问题的视图。建议动手前先写下 3 个你要回答的问题好不好用——evaluations 通过率、guardrail 检查是否稳定快不快——完成时间、首 token 延迟有没有偶发飙高贵不贵——token 总量和成本趋势如何。每个问题对应一到两张图按问题搭图是最省事的路线比对着 11 种图表类型逐个试摆高效得多。LangWatch 的 Analytics 页面把 Messages、Threads、Users 等核心指标组织成折线图与汇总卡片Top Topics 和情绪占比环形图也一并呈现。全文按 5 步主线展开选图表类型 → 选指标与聚合 → 配分组与时间粒度 → 配监控阈值 → 保存共享。选图表类型11 种内置类型的 3 个判断标准LangWatch 内置 11 种图表类型line、area、stacked_area、bar、stacked_bar、horizontal_bar、scatter、pie、donnut、summary、monitor_graphAPI 字段名以官方文档为准。数量不可怕怕的是不知道选哪个。经验上问自己 3 个问题就够。看时间趋势怎么选问题是XX 随时间怎么变选line或arealine 强调趋势本身area 强调总量累积。响应时间、成本曲线基本是 line 的天下想看各成分随时间的变化比如各模型 token 量的占比走势用stacked_area。看构成与排名怎么选问题是占多少比例或谁排第几用pie/donnut看构成用bar做分类对比标签很长时模型名、用户 IDhorizontal_bar比竖排 bar 好读得多。要一次对比两个维度上stacked_bar。怀疑两个指标之间存在关系如 token 量 vs 完成时间用scatter。看单个数字或告警怎么选只需要一个数比如本周总成本 $450用summary这个数字还要被盯住、需要按数值变状态用monitor_graph后面单独展开。类型什么时候用line / area / stacked_area时间趋势、总量累积、成分变化bar / horizontal_bar / stacked_bar分类对比、长标签排名、双维对比scatter两个指标的关系探索pie / donnut占比构成summary单个 KPI 数字monitor_graph数值监控与阈值状态选指标与聚合最容易踩坑的一步内置指标分四大类series 里的 metric 字段形如类别.字段。LangWatch 提供一批预定义指标按用途分四类具体字段清单以官方文档为准流量与用户metadata.trace_idcardinality 去重计数即总请求量、metadata.user_id独立用户数、metadata.thread_id会话数性能performance.completion_time完成时间、performance.first_token首 token 时间、performance.tokens_per_second生成速度成本与用量performance.prompt_tokens、performance.completion_tokens、performance.total_tokens总量、performance.total_cost总成本评估与质量evaluations.evaluation_pass_rate通过率、evaluations.evaluation_score分数以及sentiment.thumbs_up_down这类用户反馈指标。注意这里容易踩坑有些指标需要同时指定 key 才有意义——比如看通过率时要指定看哪个 evaluator配置 key 的名称以官方文档为准。指标和聚合方式的匹配陷阱聚合方式常见 cardinality、sum、avg还有 min/max 以及 p95、p99 等分位数。对应关系有坑ID 类字段只能用 cardinality——今天多少请求本质是 trace_id 去重计数不能对它求 sum成本与 token 量一般用 sum——你要的是总量avg 出来的平均成本业务意义不大延迟看 avg 够但要盯尾部——怀疑偶发飙高时把聚合换成 p95/p99真实的长尾才看得见。一张图可以混排多个 series比如做一张多模型 A/B 对比图{ graphType: line, timeScale: 360, groupBy: metadata.model, series: [ { name: 总请求量, metric: metadata.trace_id, aggregation: cardinality, colorSet: orangeTones }, { name: 平均完成时间, metric: performance.completion_time, aggregation: avg, colorSet: greenTones } ] }colorSet控制系列配色blueTones、greenTones、tealTones 等均可选。建议同一张图内的 series 用同一色系的不同色调避免满屏彩虹。分组与时间粒度一张折线图看多维度常用分组维度给配置加一行groupBy公司大盘的折线图就变成按维度拆开的多条并行线。最常用的 4 个维度按用户metadata.user_id识别谁的量大、谁的体验差按主题看话题分布哪些咨询集中爆发按模型metadata.model多模型性能与成本对比A/B 看板的核心按 Span 类型定位 pipeline 里哪一步是瓶颈。坑在分组基数维度值太多比如用户 ID 有几千个时折线会糊成一团。建议先用 filters 过滤出 Top N或干脆换成 horizontal_bar 排名。时间粒度怎么选timeScale控制横轴聚合粒度填数字表示粒度如 60 表示 1 小时桶也可以设full整段聚合——summary 图会自动按全周期聚合。经验值供参考实时监控10 分钟粒度尖峰看得清日常分析1 小时粒度曲线稳定可读趋势与成本统计1 天粒度长期回顾7 天或 30 天。粒度越细曲线越毛刺噪声越多拿不准就先按 1 小时出图再往粗或往细调。监控图表阈值怎么设才不会被误报淹没普通图是给人看的monitor_graph是给机器盯的。上线后不可能全天盯屏要把最关键的数字交给监控图例如盯质量检查通过率{ graphType: monitor_graph, series: [ { name: 质量检查通过率, metric: evaluations.evaluation_pass_rate, aggregation: avg } ], monitorGraph: { isGuardrail: true, disabled: false } }isGuardrail: true表示这张图按 guardrail防护栏检查来监控disabled控制是否启用。图表会根据数据值自动变色以通过率为例的参考档位是绿色通过率 80%正常黄色40%–80%需要关注红色 40%异常需要处理。注意这里最容易踩的坑别一开始就把阈值定得过于激进。建议先按默认档位跑一两周观察历史数据的自然波动区间再收紧或放宽。天天报红的监控大家很快就会视而不见仪表盘等于白搭。这类延迟监控图会同时展示当前值与周期基线虚线尖峰是否越过基线一眼可判适合作为值班同学的第一屏。保存与共享把仪表盘变成团队资产用 REST API 保存图表图调到自己满意后可以把它存为报表。除了界面操作还可以用 REST API 写入实现仪表盘即代码curl -X POST https://YOUR_DEPLOY_DOMAIN/api/v1/graphs \ -H X-Auth-Token: $API_KEY \ -H Content-Type: application/json \ -d { name: 多模型对比日报, graph: { graphType: bar, series: [/* 同上 JSON */] }, filters: {} }新接入一个项目时自动批量生成一套仪表盘走的就是这条路。请求体字段以官方文档为准。权限级别与共享方式报表存好后用三级权限管理级别能做什么适合谁查看者只读访问业务方、干系人编辑者修改图表配置分析师管理员完全控制团队负责人共享方式有三种生成只读公开链接给无账号的人看、邮件订阅定期推送报表、嵌入集成到自有系统。建议上线后第一件事就是把日报配成邮件订阅——成本最低但能逼着团队每天真的看数据。数据链路图表上的数是怎么来的排障数据为什么延迟时理解这条链路很有用数据收集OpenTelemetry Collector 接收各 SDK 上报的 Trace 数据近实时存储存储层使用 ClickHouse数据入库即可被查询按需聚合打开仪表盘时才按 series 配置做 cardinality/sum/avg 等聚合不是全量预计算结果缓存重复查询直接命中缓存同一仪表盘反复打开会越来越快。所以仪表盘比 Trace 详情页慢一点通常只是聚合口径与数据量的问题而不是数据丢了如果长时间缺数据优先检查第 1 步的采集链路。下一步可以做什么写下你当前项目的 3 个问题好不好用 / 快不快 / 贵不贵每个问题先定一个图表类型再定指标照抄文中的多模型对比配置先把 token 总量 平均完成时间的 bar 对比图跑出来给通过率配置monitor_graph并开启 guardrail 模式按默认档位跑 1–2 周后再校准阈值用 REST API 保存第一个仪表盘给干系人发只读链接并配好日报邮件订阅。【免费下载链接】langwatchOpen-Source Agent Observability Evals for AI Platform teams. Trace, test, route and govern every agent coding assistant in the company.项目地址: https://gitcode.com/GitHub_Trending/la/langwatch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LangWatch 仪表盘实战从 Trace 数据到可共享报表的 5 步搭建法【免费下载链接】langwatchOpen-Source Agent Observability Evals for AI Platform teams. Trace, test, route and govern every agent coding assistant in the company.项目地址: https://gitcode.com/GitHub_Trending/la/langwatch这是一篇 LangWatch 数据可视化 实战教程以AI 应用上线第一周为场景带你一步步搭出 AI 应用监控 仪表盘——从选图表类型、配指标到设阈值告警、保存共享报表全程可直接复用。上线第一周先想清楚要回答哪 3 个问题AI 应用刚上线时数据会迅速堆积海量 Trace、大量用户会话、密集的模型调用。逐条翻 Trace 谁也翻不完这时候你需要的不是更多数据而是一个能回答问题的视图。建议动手前先写下 3 个你要回答的问题好不好用——evaluations 通过率、guardrail 检查是否稳定快不快——完成时间、首 token 延迟有没有偶发飙高贵不贵——token 总量和成本趋势如何。每个问题对应一到两张图按问题搭图是最省事的路线比对着 11 种图表类型逐个试摆高效得多。LangWatch 的 Analytics 页面把 Messages、Threads、Users 等核心指标组织成折线图与汇总卡片Top Topics 和情绪占比环形图也一并呈现。全文按 5 步主线展开选图表类型 → 选指标与聚合 → 配分组与时间粒度 → 配监控阈值 → 保存共享。选图表类型11 种内置类型的 3 个判断标准LangWatch 内置 11 种图表类型line、area、stacked_area、bar、stacked_bar、horizontal_bar、scatter、pie、donnut、summary、monitor_graphAPI 字段名以官方文档为准。数量不可怕怕的是不知道选哪个。经验上问自己 3 个问题就够。看时间趋势怎么选问题是XX 随时间怎么变选line或arealine 强调趋势本身area 强调总量累积。响应时间、成本曲线基本是 line 的天下想看各成分随时间的变化比如各模型 token 量的占比走势用stacked_area。看构成与排名怎么选问题是占多少比例或谁排第几用pie/donnut看构成用bar做分类对比标签很长时模型名、用户 IDhorizontal_bar比竖排 bar 好读得多。要一次对比两个维度上stacked_bar。怀疑两个指标之间存在关系如 token 量 vs 完成时间用scatter。看单个数字或告警怎么选只需要一个数比如本周总成本 $450用summary这个数字还要被盯住、需要按数值变状态用monitor_graph后面单独展开。类型什么时候用line / area / stacked_area时间趋势、总量累积、成分变化bar / horizontal_bar / stacked_bar分类对比、长标签排名、双维对比scatter两个指标的关系探索pie / donnut占比构成summary单个 KPI 数字monitor_graph数值监控与阈值状态选指标与聚合最容易踩坑的一步内置指标分四大类series 里的 metric 字段形如类别.字段。LangWatch 提供一批预定义指标按用途分四类具体字段清单以官方文档为准流量与用户metadata.trace_idcardinality 去重计数即总请求量、metadata.user_id独立用户数、metadata.thread_id会话数性能performance.completion_time完成时间、performance.first_token首 token 时间、performance.tokens_per_second生成速度成本与用量performance.prompt_tokens、performance.completion_tokens、performance.total_tokens总量、performance.total_cost总成本评估与质量evaluations.evaluation_pass_rate通过率、evaluations.evaluation_score分数以及sentiment.thumbs_up_down这类用户反馈指标。注意这里容易踩坑有些指标需要同时指定 key 才有意义——比如看通过率时要指定看哪个 evaluator配置 key 的名称以官方文档为准。指标和聚合方式的匹配陷阱聚合方式常见 cardinality、sum、avg还有 min/max 以及 p95、p99 等分位数。对应关系有坑ID 类字段只能用 cardinality——今天多少请求本质是 trace_id 去重计数不能对它求 sum成本与 token 量一般用 sum——你要的是总量avg 出来的平均成本业务意义不大延迟看 avg 够但要盯尾部——怀疑偶发飙高时把聚合换成 p95/p99真实的长尾才看得见。一张图可以混排多个 series比如做一张多模型 A/B 对比图{ graphType: line, timeScale: 360, groupBy: metadata.model, series: [ { name: 总请求量, metric: metadata.trace_id, aggregation: cardinality, colorSet: orangeTones }, { name: 平均完成时间, metric: performance.completion_time, aggregation: avg, colorSet: greenTones } ] }colorSet控制系列配色blueTones、greenTones、tealTones 等均可选。建议同一张图内的 series 用同一色系的不同色调避免满屏彩虹。分组与时间粒度一张折线图看多维度常用分组维度给配置加一行groupBy公司大盘的折线图就变成按维度拆开的多条并行线。最常用的 4 个维度按用户metadata.user_id识别谁的量大、谁的体验差按主题看话题分布哪些咨询集中爆发按模型metadata.model多模型性能与成本对比A/B 看板的核心按 Span 类型定位 pipeline 里哪一步是瓶颈。坑在分组基数维度值太多比如用户 ID 有几千个时折线会糊成一团。建议先用 filters 过滤出 Top N或干脆换成 horizontal_bar 排名。时间粒度怎么选timeScale控制横轴聚合粒度填数字表示粒度如 60 表示 1 小时桶也可以设full整段聚合——summary 图会自动按全周期聚合。经验值供参考实时监控10 分钟粒度尖峰看得清日常分析1 小时粒度曲线稳定可读趋势与成本统计1 天粒度长期回顾7 天或 30 天。粒度越细曲线越毛刺噪声越多拿不准就先按 1 小时出图再往粗或往细调。监控图表阈值怎么设才不会被误报淹没普通图是给人看的monitor_graph是给机器盯的。上线后不可能全天盯屏要把最关键的数字交给监控图例如盯质量检查通过率{ graphType: monitor_graph, series: [ { name: 质量检查通过率, metric: evaluations.evaluation_pass_rate, aggregation: avg } ], monitorGraph: { isGuardrail: true, disabled: false } }isGuardrail: true表示这张图按 guardrail防护栏检查来监控disabled控制是否启用。图表会根据数据值自动变色以通过率为例的参考档位是绿色通过率 80%正常黄色40%–80%需要关注红色 40%异常需要处理。注意这里最容易踩的坑别一开始就把阈值定得过于激进。建议先按默认档位跑一两周观察历史数据的自然波动区间再收紧或放宽。天天报红的监控大家很快就会视而不见仪表盘等于白搭。这类延迟监控图会同时展示当前值与周期基线虚线尖峰是否越过基线一眼可判适合作为值班同学的第一屏。保存与共享把仪表盘变成团队资产用 REST API 保存图表图调到自己满意后可以把它存为报表。除了界面操作还可以用 REST API 写入实现仪表盘即代码curl -X POST https://YOUR_DEPLOY_DOMAIN/api/v1/graphs \ -H X-Auth-Token: $API_KEY \ -H Content-Type: application/json \ -d { name: 多模型对比日报, graph: { graphType: bar, series: [/* 同上 JSON */] }, filters: {} }新接入一个项目时自动批量生成一套仪表盘走的就是这条路。请求体字段以官方文档为准。权限级别与共享方式报表存好后用三级权限管理级别能做什么适合谁查看者只读访问业务方、干系人编辑者修改图表配置分析师管理员完全控制团队负责人共享方式有三种生成只读公开链接给无账号的人看、邮件订阅定期推送报表、嵌入集成到自有系统。建议上线后第一件事就是把日报配成邮件订阅——成本最低但能逼着团队每天真的看数据。数据链路图表上的数是怎么来的排障数据为什么延迟时理解这条链路很有用数据收集OpenTelemetry Collector 接收各 SDK 上报的 Trace 数据近实时存储存储层使用 ClickHouse数据入库即可被查询按需聚合打开仪表盘时才按 series 配置做 cardinality/sum/avg 等聚合不是全量预计算结果缓存重复查询直接命中缓存同一仪表盘反复打开会越来越快。所以仪表盘比 Trace 详情页慢一点通常只是聚合口径与数据量的问题而不是数据丢了如果长时间缺数据优先检查第 1 步的采集链路。下一步可以做什么写下你当前项目的 3 个问题好不好用 / 快不快 / 贵不贵每个问题先定一个图表类型再定指标照抄文中的多模型对比配置先把 token 总量 平均完成时间的 bar 对比图跑出来给通过率配置monitor_graph并开启 guardrail 模式按默认档位跑 1–2 周后再校准阈值用 REST API 保存第一个仪表盘给干系人发只读链接并配好日报邮件订阅。【免费下载链接】langwatchOpen-Source Agent Observability Evals for AI Platform teams. Trace, test, route and govern every agent coding assistant in the company.项目地址: https://gitcode.com/GitHub_Trending/la/langwatch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
