1. 监控系统概述：日志监控的价值、核心指标与选型准备

大家好，我是你们的讲师。今天咱们聊聊日志监控系统选型的第一步——搞清楚它到底值不值得做，以及怎么下手。

说实话，我见过太多团队一上来就急着选数据库，结果用了一段时间发现根本不适合自己的场景。嗯，这其实挺浪费时间的。所以这一章，我们先打好基础。

1.1 日志监控的价值：不只是“看日志”

很多人觉得日志监控就是“把日志收集起来，出问题了翻一翻”。其实远不止这些。

我个人习惯把日志监控的价值归纳为三点：

• 故障定位：系统挂了，你能在几分钟内找到根因，而不是靠猜
• 业务洞察：从日志里分析用户行为、交易趋势，帮产品做决策
• 安全审计：谁在什么时候做了什么操作，留痕可查

我在项目中遇到过一家电商公司，双十一大促时订单量暴增，数据库扛不住了。他们靠日志监控系统，5分钟内定位到是某个慢查询导致的。你想想看，如果没有日志监控，光靠人工翻文件，估计得折腾到天亮。

1.2 核心指标：延迟、吞吐、准确性

选型之前，你得先搞清楚三个关键指标。说白了，它们决定了你的系统能不能用、好不好用。

指标	定义	我见过的坑
延迟	从日志产生到可查询的时间差	曾经有个团队要求“秒级可见”，结果选了不适合的存储，查询时卡成PPT
吞吐	系统每秒能处理多少条日志	某次压测发现，写入峰值一上来，数据库直接OOM
准确性	日志是否完整、不丢不重	我曾经因为网络抖动丢了一批日志，排查问题花了整整两天

为什么会这样？因为这三个指标是相互制约的。比如你追求极低的延迟，可能就得牺牲吞吐；你要保证准确性，写入性能就会下降。选型时得找到平衡点。

1.3 选型前的准备工作：别急着动手

很多工程师一上来就问我：“老师，Prometheus和InfluxDB哪个好？” 我通常会反问一句：“你的日志量有多大？查询模式是什么样的？”

准备工作做扎实了，选型才不会跑偏。我个人习惯按以下步骤来：

1. 评估日志量：每天产生多少条日志？峰值是多少？
2. 明确查询场景：是全文搜索多，还是聚合分析多？
3. 确定保留周期：日志要存多久？7天还是90天？
4. 考虑扩展性：未来半年到一年，日志量会增长多少？
5. 预算约束：能花多少钱买硬件或云服务？

我曾经帮一个创业团队做选型，他们每天只有几百万条日志，却选了一套分布式集群方案。结果运维成本比日志本身还高。说白了，杀鸡用牛刀了。

1.4 知识体系总览

下面这张图是我自己画的，帮你快速理解本章的核心逻辑。从价值到指标，再到准备工作，环环相扣。

1.5 小结

这一章我们聊了日志监控的价值、三个核心指标，以及选型前需要做的准备工作。你想想看，这些基础打好了，后面选型才不会跑偏。

我个人习惯在开始任何项目前，先把这些问题列出来，写在白板上。嗯，这招挺管用的，推荐你也试试。