一组你可能感兴趣的数字。
政策快报平台的日志系统，每天处理的数据量：
-
用户行为日志：约350万条（点击、浏览、搜索、收藏等）
-
系统运行日志：约100万条（API调用、服务状态、错误记录）
-
业务数据日志：约50万条（政策更新、推送记录、用户画像变更）
约500万条/日
这些日志的总存储量：约30GB/日，年化约10TB。
500万条日志背后，是用户行为的记录、系统健康的监测、数据问题的追踪。
本文从技术角度，拆解政策信息平台的日志系统架构。
技术深潜
一、日志系统的核心价值
日志不是"可有可无"的附属品。它是：
-
问题排查的基础：用户反馈"推送没收到"，查日志
-
行为分析的依据：推荐算法优化，依赖行为日志
-
系统监控的数据源：告警规则，依赖日志指标
-
业务决策的支撑：用户留存、转化漏斗，来自日志
没有日志，就像飞机没有黑匣子------出了问题不知道原因，做优化没有依据。
二、日志系统架构
一个完整的日志系统包含4层：
text
采集层 → 传输层 → 存储层 → 应用层第一层：采集层
目标：从各个服务中收集日志。
技术方案：
| 日志类型 | 采集方式 | 工具 |
|---|---|---|
| 前端行为日志 | 埋点上报 | SDK → HTTP API |
| 后端服务日志 | 文件采集 | Filebeat |
| 数据库日志 | Binlog订阅 | Canal |
| 容器日志 | Stdout采集 | Fluentd |
埋点示例：
javascript
// 前端埋点
function track(eventName, properties) {
const log = {
event: eventName,
properties: properties,
user_id: getUserId(),
timestamp: Date.now(),
platform: 'web',
session_id: getSessionId()
};
// 异步发送，不阻塞主流程
navigator.sendBeacon('/api/log', JSON.stringify(log));
}第二层：传输层
目标：将日志从采集点可靠地传输到存储系统。
关键设计：
-
缓冲队列：使用Kafka作为消息队列，削峰填谷
-
分区键：按user_id或session_id分区，保证同一用户日志顺序
-
数据清洗：过滤无效日志、补充缺失字段、格式标准化
python
# 伪代码：日志清洗
def clean_log(raw_log):
# 过滤机器人
if is_bot(raw_log.user_agent):
return None
# 补充缺失字段
if not raw_log.session_id:
raw_log.session_id = generate_session_id(raw_log)
# 标准化格式
return {
"event": raw_log.event,
"user_id": hash_id(raw_log.user_id), # 脱敏
"timestamp": raw_log.timestamp,
"platform": raw_log.platform or "unknown"
}第三层：存储层
目标：根据使用场景，选择合适的存储引擎。
| 日志类型 | 存储引擎 | 保留周期 | 用途 |
|---|---|---|---|
| 热日志（最近7天） | Elasticsearch | 7天 | 实时查询、问题排查 |
| 温日志（7-90天） | ClickHouse | 90天 | 行为分析、报表统计 |
| 冷日志（90天+） | S3/OSS | 1年+ | 合规审计、历史回溯 |
政策快报平台的存储架构：
text
Kafka → Flink（实时处理）
↓ ↓
Elasticsearch（7天） ClickHouse（90天）
↓
S3（1年+，压缩存储）第四层：应用层
目标：让日志真正"用起来"。
应用1：实时监控
基于日志的实时指标，触发告警。
python
# 伪代码：错误率告警
error_rate = count(error_logs, last_5min) / count(total_logs, last_5min)
if error_rate > 0.01: # 错误率超过1%
alert("API error rate too high: {error_rate:.2%}")应用2：用户行为分析
基于行为日志，构建用户画像、分析转化漏斗。
sql
-- 伪代码：转化漏斗分析
WITH events AS (
SELECT user_id, event, timestamp
FROM clickhouse.logs
WHERE date = '2025-01-15'
)
SELECT
count(DISTINCT CASE WHEN event='search' THEN user_id END) as search_users,
count(DISTINCT CASE WHEN event='click' THEN user_id END) as click_users,
count(DISTINCT CASE WHEN event='consult' THEN user_id END) as consult_users
FROM events应用3：问题排查
支持按用户ID、时间范围、事件类型快速检索日志。
json
// 查询示例
{
"query": {
"bool": {
"must": [
{"term": {"user_id": "12345"}},
{"range": {"timestamp": {"gte": "2025-06-01"}}}
]
}
}
}三、日志数据的3个规律
基于1亿条行为日志的分析，政策快报平台发现了3个规律：
规律1：用户行为呈"双峰分布"
-
上午10-11点：第一个高峰（上班后）
-
下午3-4点：第二个高峰（下午工作时段）
-
晚上8-10点：小高峰（回家后）
规律2：政策详情页的"黄金15秒"
用户打开政策详情页后，前15秒决定去留。
-
停留<15秒：大概率不相关，直接退出
-
停留>2分钟：大概率相关，会继续阅读
规律3：搜索行为集中在"前3个词"
用户输入的搜索关键词，平均长度3.2个词。前3个词覆盖了95%的搜索意图。
四、常见问题与优化
问题1：日志丢失
原因：网络抖动、Kafka积压、存储写入失败。
解决：客户端本地缓存 + 重试机制 + 监控告警。
问题2：日志重复
原因：重试导致同一条日志被发送多次。
解决：在日志中增加唯一ID，下游去重。
python
import uuid
log_id = str(uuid.uuid4()) # 每条日志唯一ID问题3：日志量过大
原因：埋点过多、重复上报、爬虫流量。
解决：
-
采样：部分事件按比例采集（如10%）
-
限流：单用户/单IP限制上报频率
-
过滤：识别并过滤爬虫流量
五、给技术团队的几点建议
建议1：从"全量采集"开始
不要一开始就纠结"采哪些、不采哪些"。先全量采集，后面再优化。
数据多了可以过滤，数据少了补不回来。
建议2：日志结构要"可扩展"
使用JSON格式，便于后续增加字段。
json
// 好的设计
{"event": "click", "user_id": "123", "timestamp": 123456, "extra": {}}
// 不好的设计
"click|123|123456" // 固定格式，难扩展建议3：分级存储，控制成本
热数据用SSD（7天），温数据用HDD（90天），冷数据用对象存储（1年+）。
不要把所有数据都放在Elasticsearch，成本太高。
建议4：日志是资产，不是负担
日志的价值往往被低估。它不仅是"出了问题才看"的东西，更是产品优化的核心依据。
投入资源建设日志系统，回报远超成本。
结尾：技术总结
日均500万条日志，年化10TB。
这不是"负担"，是资产。
日志记录了用户的行为、系统的状态、业务的流转。它是问题排查的工具、行为分析的依据、监控告警的数据源。
政策快报平台的实践表明：投入资源建设日志系统，是技术团队ROI最高的投资之一。
没有日志，就像在黑夜里走路------不知道发生了什么，不知道问题在哪，不知道方向对不对。
有了日志，你才能"看见"。