Management API
Aidy 的 management 端口同时提供:
- 运维 HTTP 路由:
/health、/ready、/metrics、/debug/pprof/*、/dashboard/* - 基于 ConnectRPC 的管理面 API
默认监听 :12581。
HTTP 路由
GET /health
curl http://localhost:12581/health
成功响应:
{"status":"ok"}
GET /ready
检查 PG runtime store 是否可访问:
curl http://localhost:12581/ready
成功时:
{"status":"ready"}
GET /metrics
Prometheus 指标端点。
GET /debug/pprof/*
标准 Go pprof。
ALL /proxy?url=...
Dashboard Chat 使用这个路由把浏览器请求代理到目标上游,以规避 CORS。
ConnectRPC 资源
当前管理面覆盖这些资源:
tenantsprovidersprovider_pricingsroutesroute_plugin_configsupstreamsupstream_modelsconsumersconsumer_api_keysrequest_logs
关键模型变化
Provider
protocol支持:chat-completionsopen-responsesclaude-messages
metadata已删除status已删除- 新增
check_model - 新增
disabled_at
Provider Pricing
provider_pricings取代了旧的pricing_plans/pricing_plan_items- 定价直接挂在 provider 上,按
(provider_id, model)唯一 - global provider 的 pricing 使用空
tenant_id - tenant provider 的 pricing 会和 provider 的
source_ref_id对齐 pricing字段是原样存储的jsonbpricing现在固定使用aidy.v2.ext.billing.Pricing的 canonical protobuf JSON:basePricing+ 可选adjustments- 所有 rate 数值都表示每 1,000,000 tokens 的 credit
- 不再接受旧的
input/output/unit/unit_size/currency结构
Upstream
当前字段直接使用:
base_urlheaderscompatrequest_header_overridesapi_keyscheck_modeldisabled_atapi_keys直接内嵌在 upstream 中
补充约束:
headers当前只接受扁平string -> string映射request_header_overrides当前不支持覆盖、删除或透传Host
Upstream API Key
Management API 仍保留 Upstream API Key 相关 RPC,便于 dashboard 做局部编辑,但底层存储已经不是独立表。
当前字段重点是:
idtenant_idupstream_idnamekeyprioritylb_weightdisabled_atexpires_at
Route
当前 Route 资源新增:
max_attempts:单次请求进入真实转发/fallback 计划的最大候选数,默认2
Upstream Model
- 字段使用
model - DB 主键是
(upstream_id, model) - API 返回的
id只是前端展示用的合成值 is_alias表示该行是否为 alias- alias 直接作为
upstream_models中的独立行
认证相关 route 字段
当前 route 相关的认证字段是:
disable_authlegacy_bearer_auth_tokenspassthrough_auth_token
优先级:
disable_authpassthrough_auth_tokenlegacy_bearer_auth_tokens- 默认
consumer_api_keys
Route Plugin Configs
管理面不再通过 Route.plugin_config 读写插件配置。
当前改为独立的 RoutePluginConfigService,分成两类接口:
- 聚合接口:
ListRoutePluginConfigsGetRoutePluginConfigCreateRoutePluginConfigUpdateRoutePluginConfigDeleteRoutePluginConfig
- 明细接口:
GetAllRoutePluginConfigsReplaceAllRoutePluginConfigs
语义区别:
RoutePluginConfig是 route 级资源,直接持有entries- 明细接口直接面向
plugin_configs表的 route 级全量替换
写入约束:
Create/Update不接受空entries- 清空配置应使用
DeleteRoutePluginConfig - 明细
ReplaceAllRoutePluginConfigs允许空entries,语义等同于清空该 route 的全部plugin_configs - 明细请求中的
tenant_id不接受客户端指定,统一由 route 推导 - 明细请求中的
(plugin_key, plugin_sub_key)必须唯一
注意:
- 运行时
route.plugin_config仍然存在 - 它不是管理面
Route资源的一部分,而是 runtime 读取plugin_configs表后聚合出来的视图
协议转换
当前 route 还包含协议转换字段:
protocol_transformation_type
允许值:
enabledif-different-protocoldisabled
默认值:
if-different-protocol
当前状态:
- 该字段仍会通过管理面校验并持久化到 runtime 配置
- 当前 chat 主线路径已经固定采用“入站协议解析为 IR -> 按候选 upstream 协议组装请求 -> 成功响应再按入站协议回组装”的模型
- 也就是说,当前运行时不会再按
enabled / if-different-protocol / disabled这三种值切换不同转发行为 - 非 chat 路径这轮仍不做跨协议转换
当前支持的协议判断:
- 请求协议按请求路径判断:
/chat/completions/responses/messages
- 上游协议按
upstream -> provider -> protocol判断
分组
用于选 upstream 的分组字段有:
routes.groupsconsumers.groupsconsumer_api_keys.groupsupstreams.group
语义:
- route / consumer / api key 的空数组表示“不限制”
- upstream 仍然只有一个
group - 如果最终没有任何显式分组约束,则回落到 upstream 的
default组
Request Logs
Management API 现在提供只读的 request log 查询:
RequestLogService/ListRequestLogsRequestLogService/GetRequestLogRequestLogService/GetFullRequestLog
用途主要是给 dashboard 的 Request Logs 页面查看近期请求日志。
当前行为:
- 只读,不提供 create / update / delete
ListRequestLogs需要tenant_idListRequestLogs.limit未传时默认100- 单次最大
limit = 500 GetRequestLog返回 PG 摘要GetFullRequestLog返回request_logs.raw反序列化后的完整日志视图
返回内容对应 request_logs 表中的 PG 摘要字段:
requestresponseupstream_requeststimingdurationext_fields
其中 ext_fields 是松散的扩展字段对象;当前已知字段定义见 日志扩展字段。
注意:
route_labels不在这里返回,因为它不落 PG- body 也不在这里返回,因为
request_logs在入库时会单独裁剪成摘要 upstream_requests是数组,按真实尝试顺序保存每次上游 request/response 摘要与 attempt metadata
GetFullRequestLog:
- 复用同一个
RequestLogmessage,不新增 full 专用 schema - 优先读取
request_logs.raw - 只要
raw存在,就返回完整 body raw为空时会自动回退到 PG 摘要映射