登录日志与管理员审计日志存储决策
登录日志与管理员审计日志存储决策
日期：2026-08-26
上下文：mybilibili 项目架构讨论
目标环境：k3s 轻量部署 + 弱设备（盒子/老电脑） + 不深入复杂运维
1. 背景与问题
项目需要支持：
- 用户个人中心查看自己的登录历史（login logs）
- 管理员后台查看和搜索用户登录日志 + 管理员操作审计（audit logs）
- AI 用量统计日志（ai_usage_logs）
核心问题：
- 这种业务审计数据应该写到哪里？
- 和 observability 日志（Loki）有什么区别？
- NATS / Kafka 能不能当日志数据库用？
- 在只玩 k3s、不想深玩运维的情况下，最简单的标准做法是什么？
2. 关键概念区分（本次讨论核心）
| 类型 | 例子 | 查询特点 | 推荐存储 |
|---|---|---|---|
| 应用运行日志 | debug、error、请求 trace | 全文搜索、标签过滤 | Loki |
| K8s 平台审计 | API Server 操作 | 集群安全合规 | 专用 SIEM / Loki |
| 业务审计日志 | 用户登录、管理员改权限、AI 调用 | 结构化过滤、分页、关联 | Postgres |
业务审计日志特点：
- 需要精确结构化查询（按 user_id、按时间范围、按操作类型）
- 前端需要直接展示和分页
- 需要和用户表、管理员表关联
- 属于业务数据，而非纯运维日志
3. 各方案评估（针对本项目）
3.1 Postgres（主库）
- 优点：
- 已建表（login_logs、audit_logs、ai_usage_logs）
- 查询能力强（索引、分页、JOIN）
- 事务一致性好
- 前后端已经打通
- 缺点：需要管理增长（已通过分区解决）
- 结论：最适合
3.2 Loki
- 定位是应用 stdout 日志聚合（云原生标准）
- 查询结构化业务数据不友好
- UI 集成成本高
- 结论：不推荐用于登录/审计日志
3.3 NATS JetStream
- 可以作为 append-only 事件流（类似轻量日志）
- 适合短期 retention 和异步处理
- 查询能力很弱（主要是顺序消费）
- 结论：可作为辅助事件通道，不能当主存储
3.4 Kafka
- 功能强大，但资源重（单 broker 常需几百 MB~GB 内存）
- 运维复杂度高
- 与项目“轻量 + 弱设备”目标冲突
- 结论：不推荐
4. k3s 轻量云原生标准做法（不深玩运维版）
标准分层（CNCF 推荐简化版）：
- 应用日志→ stdout → Loki（未来）
- 业务审计日志（登录 + 管理员操作） → 主数据库（Postgres）
- 异步事件→ NATS JetStream
- K8s 自身审计（如果需要） → 单独配置 API Server audit policy（可选，运维层面）
核心原则：
- 业务可查询的历史记录 → 关系型数据库
- 可观测性日志 → Loki
- 事件解耦 → NATS
5. 最终决策
保持当前实现：
- 用户登录日志和管理员操作日志继续放在Postgres
- 使用时间范围分区（RANGE BY month）
- 写入保持简单：登录成功和敏感操作直接 INSERT
- 可选扩展：关键操作同时 publish 到 NATS（作为事件源）
已实施内容：
- sql/007_user_extend.sql、009_admin.sql、013_ai_support.sql 定义表
- sql/025_partition_log_tables.sql（分区迁移，已创建）
- sql/999_go_tables.sql 已同步分区定义
- 前端 Admin 和 Web 个人中心已支持查询
- 文档记录：docs/decisions/01-架构决策记录.md (ADR-5)
6. 保留与清理策略建议
- login_logs：保留最近 6 个月
- audit_logs：保留最近 12 个月
- ai_usage_logs：保留最近 3-6 个月
实现方式（简单）：
- 按月分区
- 定期执行
DROP TABLE login_logs_y202x_mxx;
7. 为什么这个决定符合项目约束
- 符合弱设备 + k3s 轻量目标（不需要额外重组件）
- 最小运维负担（复用现有 Postgres）
- 查询需求直接满足（无需额外开发搜索层）
- 与项目早期技术选型一致（08-technology-selection.md、02-logging-strategy.md）
8. 后续建议（保持简单优先）
- 不要把登录/审计日志混到 Loki
- NATS 主要用于事件异步和广播（弹幕、任务、索引同步等）
- 如果未来需要事件 sourcing，可让 NATS 作为事件源，消费者再写 PG
- 保持当前表结构 + 分区即可满足需求
结论：
单纯的用户登录日志和管理员操作日志，在只玩 k3s、不深运维的情况下，放在 Postgres + 时间分区是最正确、最简单的选择。已按此方向实施并记录。
文档位置：/home/a1/文档/登录日志与管理员审计日志存储决策.md