API 与可观测性
概览
本页介绍用于暴露接口和遥测的共享运行时块。
这些设置作用于整台路由器,应放在 global: 下,而不是路由局部的插件片段中。
主要优势
- 让可观测性与接口控制在各路由间保持一致。
- 避免在路由局部配置中重复指标或 API 设置。
- 将回放与 Response API 明确为共享服务。
- 把运维控制集中在一层路由器级配置中。
解决什么问题?
如果按路由分别配置 API 和遥测,运维面会碎片化,难以推理。
global: 的这一部分把共享接口和监控设置收拢到一处。
何时使用
在以下情况使用这些块:
- 路由器应暴露共享 API
- 整台路由器应启用 Response API
- 指标和 tracing 只需配置一次
- 回放采集应作为共享运维服务保留
配置
路由器配置校验
管理 API 会校验并规范化候选配置,但不会写入:
POST /api/v1/config/validate
Content-Type: application/json
{"yaml":"version: v0.3\n..."}
成功响应包含 valid: true 以及规范化后的规范 YAML。校验使用与 PATCH /api/v1/config 和 PUT /api/v1/config 相同的解析器和语义检查,但会原样保留 ${ENV_VAR} 引用,而不是读取进程密钥。该端点需要 config.read;不意味着可以查看明文密钥。
API
global:
services:
api:
routing_preview:
request_timeout_seconds: 120
max_concurrency: 16
batch_classification:
max_batch_size: 100
max_batch_size 限制每次 /api/v1/diagnostics/classify/batch 请求的 texts 数量。超过上限会返回 400 INVALID_INPUT。
routing_preview 作用于 POST /api/v1/routing/preview。推理时限从请求体解析完成后开始计算,默认 120 秒。request_timeout_seconds 可设为 1 至 3600 秒,应根据实际输入长度和部署硬件的测量结果选择。该设置支持配置热更新;其他 HTTP 路由保留现有超时设置。
达到时限后,API 返回 504 REQUEST_TIMEOUT,并取消排队中或可取消的推理。已经执行的原生推理可能稍后才结束;在其结束前,模型资源和并发名额都会保留,关闭服务时也不例外。max_concurrency 是正整数,默认允许 16 个推理任务并发执行,不提供等待队列;名额用完后,新请求返回 429 OVERLOADED。修改此并发上限需要重新部署并重启服务,热更新会拒绝该变更。
响应写入另有 5 秒余量,用于发送结果或超时响应。Dashboard Topology 使用配置的 Preview 时限加上该余量,并传递客户端取消信号。Recipe 探测仍使用 probes.yaml 中独立的 evaluation.request_timeout_seconds 客户端时限;应按实际测试配置。如果外部 HTTP 客户端或代理需要收到 Router 的超时响应,其时限应至少多留 5 秒。
Response API
global:
services:
response_api:
enabled: true
store_backend: redis # default; use "memory" only for local development
redis:
address: "redis:6379"
store_backend 控制响应和对话历史的持久化位置。可用后端:
| 后端 | 持久性 | 适用场景 |
|---|---|---|
redis | 路由器重启后仍保留,可在副本间共享 | 生产(默认) |
memory | 路由器重启后丢失 | 仅用于本地开发 |