登录日志与管理员审计日志存储决策日期2026-08-26上下文mybilibili 项目架构讨论目标环境k3s 轻量部署 弱设备盒子/老电脑 不深入复杂运维1. 背景与问题项目需要支持用户个人中心查看自己的登录历史login logs管理员后台查看和搜索用户登录日志 管理员操作审计audit logsAI 用量统计日志ai_usage_logs核心问题这种业务审计数据应该写到哪里和 observability 日志Loki有什么区别NATS / Kafka 能不能当日志数据库用在只玩 k3s、不想深玩运维的情况下最简单的标准做法是什么2. 关键概念区分本次讨论核心类型例子查询特点推荐存储应用运行日志debug、error、请求 trace全文搜索、标签过滤LokiK8s 平台审计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 JetStreamK8s 自身审计如果需要 → 单独配置 API Server audit policy可选运维层面核心原则业务可查询的历史记录 → 关系型数据库可观测性日志 → Loki事件解耦 → NATS5. 最终决策保持当前实现用户登录日志和管理员操作日志继续放在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.md8. 后续建议保持简单优先不要把登录/审计日志混到 LokiNATS 主要用于事件异步和广播弹幕、任务、索引同步等如果未来需要事件 sourcing可让 NATS 作为事件源消费者再写 PG保持当前表结构 分区即可满足需求结论单纯的用户登录日志和管理员操作日志在只玩 k3s、不深运维的情况下放在 Postgres 时间分区是最正确、最简单的选择。已按此方向实施并记录。文档位置/home/a1/文档/登录日志与管理员审计日志存储决策.md