日志查看

Sira 在数据库里维护多条独立的日志流。本页讲清楚每条流是什么、谁能看、在哪里看。不存在"5 类日志统一切换"那个 UI——每条流都有自己的产品入口。

全部日志流速查

表 / 流	记录什么	用户可见入口
`monitoring_logs`	跨业务的系统事件：AI 模型调用、MCP 工具调用、路由决策、工作流执行、用户行为、性能、安全	/logs （仅 super_admin）
`api_call_logs`	每次外部 API（OpenAI / LangGraph 兼容）的请求 / 响应 / token / 状态码	API（无独立前端页）
`audit_logs`	通用操作审计：`action / resource_type / resource_id / changes / ip`	API（无独立前端页）
`sandbox_audit_log`	沙箱平台动作：注册 / 撤销 / 路由 / 文件读 / 命令执行	Sandboxes → 平台审计
`sandbox_decision_events`	AI 在员工 PC 沙箱里的每次裁决（allow/deny/warn）	Sandboxes → AI 决策审计
`license_usage_events`	每次 License 网关命中（无论放行还是拒绝）	License 管理 → 用量审计
`cron_job_runs`	定时任务每次执行的结果、错误、token 用量	API：`GET /cron/{id}/runs`

这些流是分开的，不互通

比如想查"昨天有多少次 LLM 调用失败"，要去 monitoring_logs（category=ai_model_call, level=error）；想查"哪些 API Key 调用过 OpenAI 接口"，要去 api_call_logs。它们之间没有自动汇总。

监控日志 (/logs 页)

唯一一个有独立前端页面的日志流。仅 super_admin 可访问。

类目（`category`）

值	含义
`message_processing`	消息处理过程
`ai_model_call`	LLM 调用（含 prompt / 完成 / token / 成本）
`mcp_tool_call`	MCP 工具调用
`route_decision`	编排路由决策
`workflow_execution`	Workflow 编排执行
`system_operation`	系统操作
`user_action`	用户行为
`integration`	外部系统集成（Dify / n8n）调用
`performance`	性能事件
`security`	安全相关

严重级 (`level`)

debug / info / warning / error / critical

过滤条件

level 多选
category 多选
success true/false
search 关键词（在 message 里搜）
时间范围

接口模型还有 userId / sessionId / component / eventType 字段，但当前 UI 只暴露上面这几个过滤器。

列字段（CSV 导出）

id, timestamp, level, category, eventType, message, success, userId, sessionId, component, duration, tokensUsed, cost

导出

页面右上角"导出 CSV"——一次导出最多 1000 行（10 页 × 100 / 页）。

不是实时监控

此页是分页查询历史日志。没有自动滚动 / 实时 tail / WebSocket push——刷新或翻页才能看到新日志。

API 调用日志（`api_call_logs`）

每次外部 API（OpenAI 兼容 / LangGraph 兼容）请求都会落库一条：

字段	说明
`api_key_id` / `application_id`	哪把 key、哪个 Application 触发
`request_path`	路径（如 `/v1/chat/completions`）
`tokens_input` / `tokens_output` / `tokens_total`	Token 用量
`status_code` / `is_stream`	HTTP 状态、是否流式
`error_code` / `error_message`	失败时的错误
`duration_ms`	总耗时

API 端点：

GET /api-call-logs              # 列表（按 user / app / time 过滤）
GET /api-call-logs/{log_id}     # 详情

当前没有专属的前端管理页面——通过 API 自己拉，或在 BI 里接表。

沙箱平台审计 (`sandbox_audit_log`)

记录管理员侧动作：

enroll_create / enroll_consume —— 注册票创建 / 消费
revoke —— 撤销沙箱
route —— 编排器路由到该沙箱
pty_open / file_read / shell_exec —— 平台代理操作
dedicated_create —— 创建专用沙箱

入口：Sandboxes 页 → 平台审计标签（管理员）。

AI 决策审计 (`sandbox_decision_events`)

记录员工 PC 沙箱内 AI 的每次访问决策（量级最大）：

path 访问 / exec 命令 / pty 终端
decision allow / deny / warn
完整调用链信息

入口：Sandboxes 页 → AI 决策审计标签（管理员，需 sandbox.decision_audit License）。

License 用量审计 (`license_usage_events`)

每次 License 功能门命中（不论放行还是拒绝）写一条。schema 与 sandbox_decision_events 对齐。extra_data 含 outcome / source / mode / reason / current_tier / required_tier。

入口：License 管理 → 用量审计标签（super_admin）。

定时任务运行历史 (`cron_job_runs`)

每次定时任务执行写一条，含 status / error / duration_ms / token_usage / delivery_status。

API：

GET /cron/{job_id}/runs?skip=&limit=

详见定时任务 → 可观测性。

留存策略

当前没有自动清理任务

代码里没有定时清理 / 归档 / 滚动表的实现。运维侧建议自行通过 PG 分区或定期 DELETE WHERE created_at < ... 控制表大小。

主要日志流的写入量级（参考）：

monitoring_logs：每条用户消息 ~3-10 行
api_call_logs：每次 API 调用 1 行
sandbox_decision_events：员工 PC 上每次路径访问 / 命令执行 1 行（量级最大，必须考虑分区或冷归档）
license_usage_events：每次 gate.require() 命中 1 行

排查清单

想查	去哪
AI 回复某次为啥失败	`/logs` 页，`category=ai_model_call, level=error`；或对应 `session_id` 翻 `monitoring_logs`
某把 API Key 用了多少 token	`api_call_logs` 按 `api_key_id` 聚合
用户 X 改过哪些资源	`audit_logs` 按 `user_id` 过滤
沙箱被谁、什么时候撤销的	Sandboxes → 平台审计
AI 在员工 PC 上访问了哪些敏感路径	Sandboxes → AI 决策审计，`decision=deny` 排在前
License 拦截了多少请求	License 管理 → 用量审计，`outcome=deny`
定时任务今天为啥没跑	`GET /cron/{id}/runs`，看 `status` / `error`

当前不支持

实时滚动 / WebSocket push / "暂停-恢复"日志流
告警规则（邮件 / 短信 / Webhook）
跨日志流统一查询入口
日志归档 / 自动压缩
CPU / 内存 / 磁盘 / 网络等基础设施指标看板（可考虑接入 Prometheus / Grafana 等外部系统）

日志查看 ​

全部日志流速查 ​

监控日志 (/logs 页) ​

类目（category） ​

严重级 (level) ​

过滤条件 ​

列字段（CSV 导出） ​

导出 ​

API 调用日志（api_call_logs） ​

沙箱平台审计 (sandbox_audit_log) ​

AI 决策审计 (sandbox_decision_events) ​

License 用量审计 (license_usage_events) ​

定时任务运行历史 (cron_job_runs) ​

留存策略 ​

排查清单 ​

当前不支持 ​

相关文档 ​