企业官网建设流程全解析

CliRelay 是一个自托管的 AI 网关，为 Claude Code、Codex、Gemini CLI 等编程命令行工具提供统一的 OpenAI/Claude/Gemini 兼容接入点。本文带你走进它的监控中心与请求日志：如何看懂 P50–P99 延迟分布、首 Token 时间（TTFT），以及如何分析每个模型、渠道和用户的真实成本，帮助新手在几分钟内建立完整的 AI 用量观测思路。

一、5 分钟看懂 CliRelay 监控中心全景

登录 CliRelay 控制台后，左侧菜单的Observability → Monitor就是监控中心入口。页面顶部提供 1 小时 / 6 小时 / 24 小时 / 今天 / 7 天 / 14 天 / 30 天七种时间范围，以及按门户用户、模型、渠道组合筛选的过滤器。

概览区由六个指标卡组成，每张卡都带环比变化和迷你趋势线：

左侧的健康评分（Health score）则把成功率、渠道状态、延迟汇总成一个 0–100 的分值，适合每天扫一眼。

二、P50–P99 延迟分布：为什么不能只看平均值

监控中心中部的Latency distribution（延迟分布）面板展示了 P50 / P90 / P95 / P99 四个分位数和一张直方图：

• P50：一半的请求比它快，代表"日常体验"；
• P95 / P99：最差的那 5% / 1% 请求比它快，代表"偶发卡顿"。

平均值会被极端值拉高或拉低，而分位数能回答"普通用户实际等多久"。例如上图 P50 仅 12.4s，但 P99 达到 2m 22s，说明大部分请求很快、偶发请求很慢——这正好提示你去查最近的失败与慢请求。

实现原理（对进阶读者）：延迟分位数不需要把每一行明细拉进 Go 内存。CliRelay 在 SQL 层把耗时按近似对数分桶（100ms、150ms……10s、30s、60s……），统计每桶数量与桶内最小/最大值，再在桶内线性插值估算分位点，单样本桶结果是精确的。相关实现在 monitor_detail.go 中，同一套 SQL 兼容 SQLite 与 PostgreSQL。分位数统计只覆盖成功请求，且受请求日志保留期限制（默认 7 天），页面会用coverage_start明确标注实际覆盖范围，避免与聚合数据"静默不一致"。

三、首 Token 时间：判断流式体验的关键指标

首 Token 时间（Time to First Token，TTFT）指从发出请求到收到第一个 token 的等待时间，只有流式请求才会记录。面板中可切换Total / First token两个分布视图：

• Total长而First token短 → 模型推理快，只是输出内容多，属正常；
• First token就很长 → 排队、上游限流或账号额度紧张，需要扩容渠道。

指标卡中的 "Time to first token P50" 给出最直观的日常体感值。统计口径（含流式请求数量、首 Token 平均值）定义在 monitor_types.go 的MonitorLatency结构中，均值只统计真正上报了该测量的请求，因此不会被"未记录"的 0 值稀释。

四、模型表现排行与成本分析

监控中心下半部分是模型表现表，按请求量排序列出每个模型的请求数、成功率、平均延迟、首 Token、速度（tokens/s）、token 与成本，并附迷你趋势：

成本是怎么算出来的？CliRelay 内置model_pricing价格表（输入/输出/缓存读取等单价，单位"每百万 token"），每笔请求结算时按 token 明细折算成本并写入聚合桶，因此排行表里的 Cost 列是逐笔累加的真实花费，而不是估算。价格表支持在控制台的 Models 页面直接维护：

实用分析套路：

1. 按模型排序看 Cost 列→ 找出最烧钱的模型；
2. 对比 Tokens 与 Cost→ 判断是"用得多"还是"单价贵"，考虑换用更便宜的等价模型；
3. 看缓存命中率→ 命中率高的渠道/前缀策略能直接降低输入 token 成本；
4. 点击任意一行→ 整页筛选为该模型，继续下钻渠道与用户。

价格配置的代码入口在 pricing_db.go，聚合与环比对比逻辑见 monitor_rollup.go。

五、流量流向、热力图与失败下钻

把页面继续往下拉，还有三块分析视图：

• 流量流向图（Sankey）：门户用户 → 模型 → 渠道三层流向，一眼看出"谁在用哪个模型走哪个渠道"，低流量项折叠进 "Other" 节点；
• 活跃时段热力图：星期 × 小时的请求密度，帮你判断高峰期并安排容量；
• 失败分析：按渠道 / 模型 / 门户用户三个维度定位失败来源，下方列出最近的失败请求，点 Details 即可打开请求详情；
• 渠道健康与门户用户排行：各渠道的成功率、平均延迟，各用户的请求量、token 与花费。

概览数据全部由服务端组装返回，任一二级查询失败只降级为空值、不会拖垮整页，组装逻辑在 monitor_overview.go 中。

六、请求日志：逐条检索每一笔 token 与费用

监控中心回答"整体怎么样"，Request Logs（请求日志）则回答"这一笔到底发生了什么"。日志页顶部汇总了时间范围（今天 / 7 天 / 14 天 / 30 天）内的记录数、成功率、token 总量、总成本与缓存命中数：

支持按用户、模型、渠道、状态四组条件下拉筛选。表格逐条展示渠道、用户、缓存读取、输入、输出 token 等列；点击任意一行可打开详情弹窗，查看该请求的输入指令、模型输出、耗时与费用明细：

日常排障的典型路径是：监控中心看到 P99 抬高 → 失败分析定位渠道 → 请求日志逐条打开详情。查询与导出能力由 request_log_query.go 实现，日志按租户隔离并有独立的保留期与清理策略，生产环境建议按需调整存储保留天数。

七、总结：建立自己的观测习惯

CliRelay 的监控中心与请求日志围绕"聚合看趋势、明细找原因"两层设计：聚合数据（分钟/小时/天桶）支持长达数十天的回看，分位数与失败明细则依托请求日志保留窗口。把"指标卡 → 分布 → 排行 → 明细"这条下钻路径练熟，你就能快速定位任何一次变慢或超支的根因。