Java用户行为日志系统核心是“采集可控、格式统一、传输可靠、清洗可溯”，需先实现埋点到落库最小闭环，再逐步增强实时性与分析能力。
在Java中搭建用户行为日志系统，核心是“采集可控、格式统一、传输可靠、清洗可溯”。不追求大而全，先跑通从埋点到落库的最小闭环，再逐步增强实时性与分析能力。
一、前端埋点与后端日志规范设计
用户行为日志必须从源头统一结构。建议采用JSON格式，固定字段包括：user_id（登录态或设备ID）、event_type（如 click、page_view、submit）、page_url、element_id（触发元素）、timestamp（毫秒级）、session_id、ua、ip（服务端补全）。避免使用纯文本日志或随意拼接字符串。
后端统一提供日志接收接口（如 POST /api/log/track），用 Spring Boot + @RequestBody 接收标准 JSON，校验必填字段并过滤空值或非法字符（如 SQL 注入特征、超长字段）。
二、Java服务端日志采集与异步缓冲
不要让日志写入阻塞主业务。推荐用 Disruptor 或 BlockingQueue + 独立消费线程 实现异步日志采集：
立即学习“Java免费学习笔记（深入）”；
- 收到日志请求后，只做轻量校验和封装（转为 LogEvent 对象），立即投递到内存队列
- 后台线程批量拉取（如每 200 条或 500ms 刷一次），序列化为 JSON 行格式（每行一个事件）
- 写入本地文件时按天分目录、按小时分文件（如 /logs/behavior/20240615/14.log），方便后续搬运
三、日志传输与去重清洗关键点
本地日志文件需安全、有序地进入数据平台。常见做法是用 Filebeat → Kafka → Flink/Spark Streaming 链路：
- Filebeat 配置 tail_mode + close_inactive，避免重复采集滚动日志
- Kafka Topic 按业务分 partition，key 设为 user_id 或 session_id，保障同一会话顺序
- 清洗阶段重点处理：时间乱序修正（以客户端 timestamp 为主，服务端时间兜底）、重复日志去重（基于 event_id 或 MD5(event_type+user_id+timestamp+element_id) 去重）、缺失字段补全（如 IP 归属地、设备类型 UA 解析）
四、落地存储与简单查询支持
清洗后的日志建议双写：一份进 Elasticsearch（支持快速检索、漏斗分析、看板展示），一份进 Hive/StarRocks（支撑离线报表、用户路径建模）。ES 中注意设置合理 mapping（如 user_id 为 keyword，timestamp 为 date），避免 text 字段参与聚合。
初期可用 Logstash 写 ES，后期替换为 Flink SQL 直写；Hive 表按 dt（日期）分区，字段全部小写下划线命名，保留原始字段 + 清洗标记字段（如 is_valid、clean_time）。
基本上就这些——不复杂但容易忽略的是日志生命周期管理：本地文件保留 7 天、Kafka 保留 3 天、ES 索引按天滚动并设置 ILM 策略。从埋点定义开始，每个环节都带版本号（如 log_schema_v2），才能长期可维护。
