一、日志分析概述
1.1 日志的价值——你每天都在丢掉的金矿
说实话，我做了十几年后端，见过太多团队把日志当「废纸」。
系统崩了才想起来翻日志，平时根本没人看。
但你想过没有——
每一行日志，都是系统在对你「说话」。
日志的价值，我总结为三点：
- 故障定位：系统挂了，日志是唯一的「黑匣子」。我在项目里遇到过，线上服务突然502，查了半小时代码没头绪，最后发现是日志里一条「connection pool exhausted」——说白了，连接池配小了。
- 行为审计：谁在什么时候干了什么？日志一清二楚。安全审计靠的就是这个。
- 业务洞察：用户点击了什么、停留了多久、在哪个页面报错了——这些数据藏在日志里，挖出来就是钱。
核心观点：日志不是「写完了就扔」的东西。它是你系统里最真实、最原始的数据资产。
1.2 实时分析 vs 离线分析——别搞混了
很多人问我：「实时分析和离线分析到底啥区别？」
嗯，这个问题我当年也困惑过。
我直接给你画个对比：
| 维度 | 实时分析 | 离线分析 |
|---|---|---|
| 延迟要求 | 秒级～分钟级 | 小时级～天级 |
| 典型工具 | Flink、Spark Streaming、Kafka Streams | Hive、Spark SQL、Presto |
| 数据量 | 单次处理量小，但持续不断 | 批量处理，数据量大 |
| 典型场景 | 告警、监控大屏、风控拦截 | 日报、月报、趋势分析 |
| 成本 | 较高（需要常驻资源） | 较低（可以按需调度） |
我个人的习惯是：能用离线解决的，绝不实时。
为什么？因为实时系统贵啊！
你想想看，一个Flink任务跑24小时，资源开销是离线任务的5-10倍。所以我的原则是——
- 需要立即响应的（比如系统挂了要报警）→ 实时
- 可以等一等的（比如昨天的PV统计）→ 离线
我的经验：很多团队一上来就搞实时，结果成本爆炸。我建议先做离线分析，等业务验证了价值，再逐步上实时。别一上来就「全栈实时」，那是给自己挖坑。
1.3 典型应用场景——日志分析到底能干啥？
光说理论没意思。我直接给你讲三个真实场景。
场景一：运维监控
这是最基础、也是最刚需的场景。
我记得有一次，凌晨2点被电话吵醒——线上服务大面积超时。我打开日志平台，发现错误日志在1分钟内暴涨了100倍。实时告警直接触发，自动拉起新节点，5分钟后系统恢复。
如果没有实时日志分析，等用户投诉过来，黄花菜都凉了。
运维监控的核心指标：
- 错误率：5xx比例超过阈值就告警
- 延迟：P99延迟超过500ms就告警
- 吞吐量：QPS突然下降，可能是服务挂了
场景二：安全审计
安全这事儿，平时没人管，一出事就是大事。
我曾经帮一个金融客户做过日志审计系统。他们的需求是：检测「异常登录」——比如一个账号在5分钟内从北京和上海同时登录。
这种场景，离线分析根本来不及。必须实时检测，秒级告警。
注意：安全审计的日志必须保证「不丢不重」。我见过有团队用Kafka丢了数据，结果安全事件追溯时发现日志断档了——那叫一个尴尬。所以，生产环境一定要开启Kafka的ACK=all。
场景三：业务洞察
这个场景最容易被忽视，但价值最大。
举个例子：电商网站的「用户行为分析」。
用户搜索了什么商品、在哪个页面停留最久、加购后有没有付款——这些信息都藏在点击日志里。实时分析可以做到：
- 用户刚搜索了「iPhone 15」，立刻推送相关优惠券
- 用户加购后5分钟没付款，触发「购物车放弃」提醒
- 某个商品页面报错率突然升高，自动下架并通知运营
说白了，日志就是用户的「行为指纹」。你分析得越细，赚得越多。
1.4 本章知识体系总览
下面这张图，是我自己梳理的「日志分析知识体系」。你把它存下来，后面每一章都会用到。
这张图你看懂了吗？
从上到下，就是一条完整的数据流：
- 日志从各个系统产生
- 经过采集、传输、存储
- 根据业务需求选择实时或离线分析
- 最终落地到具体的应用场景
后面的每一章，都会围绕这张图展开。
我的建议：学完这一章，你可以先回去看看自己团队的日志系统——
- 日志有没有被有效利用？
- 实时和离线的边界是否清晰？
- 有没有「该实时却离线」或者「该离线却实时」的浪费？
想清楚这三个问题，你这一章就没白学。
公众号:蓝海资料掘金营，微信deep3321