FreeLLMAPI 仪表盘 Server Logs 实时日志查看器：轮询 API、过滤与两级存储怎么用

FreeLLMAPI 仪表盘 Server Logs 实时日志查看器轮询 API、过滤与两级存储怎么用【免费下载链接】freellmapi7.4 billion tokens per month. 34 free LLM providers. 635 free model endpoints. All behind one /v1 endpoint, plus any custom OpenAI-compatible endpoint. Smart routing, automatic failover, encrypted keys. Personal experimentation only.项目地址: https://gitcode.com/GitHub_Trending/fr/freellmapi调试 freellmapi 网关时最想知道的往往不是“请求量多少”而是“这次请求为什么走了这条路径”路由决策、provider 健康检查、key 冷却、配额耗尽、压缩保真度门控以及任何warn/error级事件。仪表盘内置了 Server Logs 页面让你在浏览器里看到服务器写入 stdout 的同一批诊断行不需要 SSH 或容器日志访问。本文围绕这个查看器的三件事展开轮询 API 怎么用、各过滤参数有什么行为、两级日志存储如何分工。对应文档是 docs/en/logs/01-server-logs-viewer.md中文版本见 docs/zh-cn/logs/01-server-logs-viewer.md。两级存储环形缓冲与 server_logs 表日志存储对两个层级使用同一个 id 空间层级容量级别持久化用途环形缓冲ring buffer1,000 条最新trace、debug、info、warn、error仅内存仪表盘轮询用的实时尾部能扛过滤条件变化扛不住重启server_logs表可配置SERVER_LOGS_MAX_ROWS默认 50,000仅warn、errorSQLite重启后保留保存最重要的 warn/error 历史有几条规则决定了你实际会看到的行为实现在 server/src/lib/server-logs.tsid 由存储分配而不是 SQLite 分配。计数器在初始化时从表中MAX(id)取种因此 id 跨重启持续递增已打开的仪表盘标签页持有的sinceId游标不会倒退。启动时存储会把最多 200 条最近的持久化行新→旧读取预载进环形缓冲重启后仪表盘显示的是重启前发生的警告而不是空面板。采集发生在脱敏包装器lib/log-redaction.ts内部进程里只有一个 console 补丁先脱敏API key、Bearer token、URL token 等存储拿到的永远是脱敏后的文本。密钥不会进入环形缓冲或数据库。匹配GET|HEAD /api/(logs|ping)的行在入库前被过滤掉。否则轮询端点本身会成为日志里最吵的条目形成自喂缓冲。轮询 APIGET /api/logs所有日志端点挂在/api/logs下位于仪表盘会话门禁之后server/src/app.ts 中app.use(/api/logs, requireAuth, logsRouter)。/v1的统一 key 只打开推理面不能打开这组端点——这些日志行包含 provider、模型、key 编号与失败原因。直接调用时使用登录/设置流程签发的会话 token以Authorization: Bearer token发送。查询参数实现见 server/src/routes/logs.ts参数类型说明sinceId整数可选返回 id大于该值的条目省略时返回最新limit条默认 200levelsCSV可选逗号分隔的级别过滤trace,debug,info,warn,error未知级别直接返回400q字符串可选大小写不敏感文本搜索覆盖message、provider、source、eventprovider字符串可选provider 名称精确匹配如openai、anthropiclimit整数可选钳制到[1, 500]默认200响应是三段结构entries页内按旧→新排序、nextId、counts整个环形缓冲的各级计数trace并入debug{ entries: [ { id: 12345, ts: 2026-08-23T14:32:11.123Z, level: warn, source: CooldownProbe, provider: openai, model: gpt-4o, event: cooldown_triggered, requestId: req_abc123, message: [CooldownProbe] openai:gpt-4o key #3 entered 45s cooldown (rate limit) } ], nextId: 12345, counts: { debug: 12, info: 145, warn: 8, error: 2 } }以上是文档给出的示例输出不是固定预期值。游标设计的关键点nextId是存储当前最高的 id而不是本次返回的最高 id。匹配项即使全被过滤掉游标也会前进不会永远重扫同一段尾部。已经追平sinceId lastId的调用方得到entries: []代价是一次整数比较——服务空闲时这就是稳定状态不是错误。下面命令中的BASE替换为仪表盘实际提供的源浏览器打开仪表盘用的那个源TOKEN替换为仪表盘会话 token# 首次轮询省略 sinceId拿最新 200 条 curl -s http://BASE/api/logs -H Authorization: Bearer TOKEN记下响应里的nextId后续轮询把它作为游标带回去# 增量轮询12345 是上一次响应的 nextId文档示例中的值 curl -s http://BASE/api/logs?sinceId12345 -H Authorization: Bearer TOKEN仪表盘页面就是按这个模式运行的每 3 秒轮询一次LOG_POLL_MS把上次响应的nextId作为sinceId发送页面进入后台时轮询暂停。三个过滤器怎么发挥作用仪表盘的级别复选框、provider 下拉和搜索框分别对应levels、provider、q三个参数有几个边界值得知道levels是服务端过滤客户端始终把当前选中集合作为 CSV 发送。传一个不属于五级之一的值会得到400如Unknown log level warning. Known levels: trace, debug, info, warn, error。实现上这是刻意拒绝而不是静默忽略显示一个与所请求过滤条件不符的视图比报错更糟。q在message、provider、source、event上做大小写不敏感搜索。仪表盘的搜索框有 300ms 防抖SEARCH_DEBOUNCE_MS服务器对每次过滤变化都从头重跑整条查询。provider是精确匹配不是前缀或子串。仪表盘的 provider 下拉不来自独立的“列出 provider”接口而是从当前会话看到过的条目provider字段累积且不会随旧条目被淘汰而减少client/src/lib/logs.ts 的collectProviders。过滤条件变化会重置流仪表盘清空本地缓冲、游标置空、重新取最新 200 条而不是从旧游标继续增量。默认只勾选info、warn、error三级DEFAULT_LOG_LEVELSdebug默认关闭——源码注释的理由是它是 firehose需要时再手动打开。客户端测试里有一条完整的组合示例可以作为参数叠加的参考来自 client/src/lib/logs.test.tsGET /api/logs?levelswarn%2CerrorqratelimitprovidergroqsinceId123limit200清空日志POST /api/logs/clearcurl -s -X POST http://BASE/api/logs/clear -H Authorization: Bearer TOKEN返回{ ok: true }。这次调用同时清空环形缓冲并截断server_logs表即两级一起清空。id 计数器不会重置——否则持有游标的仪表盘标签页会拿到已经见过的 id。仪表盘上的 Clear 按钮是确认式操作调用该接口后会失效查询缓存并重置本地状态。注意这个操作的影响面它清掉的是 SQLite 里已持久化的 warn/error 历史。需要保留这些历史警告时不要随手调用。存储上限与保留期调整两个环境变量控制第二级的规模均在 server/src/services/request-retention.ts 中解析变量默认值行为SERVER_LOGS_RETENTION_DAYS7早于该天数的行由每日维护任务删除SERVER_LOGS_MAX_ROWS50000server_logs表的硬上限超出时在下一次插入时删除最旧行两者都在服务器启动时读取修改后需要重启才生效。直接在仪表盘页面操作不直接调接口时从仪表盘的Analytics导航菜单进入 Server Logs 页面client/src/pages/LogsPage.tsx。它与分析图表并列图表回答“发生了什么”请求量、延迟、错误日志回答“为什么”。使用时会碰到这些行为轮询周期 3 秒标签页进入后台时暂停轮询。只有光标停在底部40px 范围内时视图才自动跟随滚动往上滚即脱离此时若有新行到达会出现一个“Jump to latest”按钮。长消息被截断折叠点击展开/收起。四个级别徽章error红、warn琥珀、info蓝、debug灰用轮询响应里的counts字段显示实时计数。provider 下拉从当前流中见过的条目动态填充。关于counts文档还描述了一个独立的GET /api/logs/counts端点供只需要徽章数字的页面单独拉取但当前路由实现只挂载了GET /与POST /clearcounts随每次轮询响应一并返回仪表盘即从轮询响应中读取。验证与已知边界可以用三个可观察结果核对整条流程首次不带sinceId的轮询返回最新最多 200 条及一个nextId紧接着用该nextId轮询若期间没有新日志entries为空数组nextId仍是存储当前最高 id。重启后仪表盘不空白最多 200 条最近的 warn/error 持久化行被预载回环形缓冲。调用POST /api/logs/clear后面板清空、游标继续向前id 持续递增而不是回退到旧 id。已知边界只有warn/error进入 SQLite 表trace/debug/info只存在于环形缓冲重启即丢。环形缓冲最多保留 1,000 条更早的条目被逐出改变过滤条件不会让它们丢失重启会。仪表盘展示的行与终端相同但已经是脱敏后的形式——行里的密钥在终端里你看到的也是脱敏后的样子。更深的内部实现ingest 链路、结构化providerLog元数据、启动预载、server_logs/requests/request_attempts表结构、桌面端文件日志freeapi.log见 docs/en/architecture/06-observability.md。【免费下载链接】freellmapi7.4 billion tokens per month. 34 free LLM providers. 635 free model endpoints. All behind one /v1 endpoint, plus any custom OpenAI-compatible endpoint. Smart routing, automatic failover, encrypted keys. Personal experimentation only.项目地址: https://gitcode.com/GitHub_Trending/fr/freellmapi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考