先把访问日志、错误日志、慢查询日志分开看，再把CPU、内存、磁盘I/O、带宽四类指标设好阈值，告警规则宁可多设不可漏设，最后用“日志→指标→告警→排查”的闭环流程兜底。这套组合拳打下来，大促流量冲垮服务器、半夜睡梦中被报警吵醒、客户投诉页面打不开这类事故，基本能提前摁死在萌芽状态,下面从实操角度拆开讲。
日志监控到底在监控什么：三类日志必须分开处理
日志不是越全越好，而是越“分得清”越好，很多电商团队把access.log、error.log、慢查询日志全塞一个目录，出问题的时候翻半天找不到头绪，行业共识认为,日志分类清晰度直接决定故障定位速度。
访问日志：看流量异常和用户行为痕迹
访问日志记录的是每一次HTTP请求的来龙去脉,电商场景下重点盯三样东西：
- 状态码分布：4xx比例突然上升，大概率是爬虫入侵或用户请求异常；5xx比例连续5分钟超过5%，基本可以判定后端服务出问题了
- 请求耗时P99：P99超过800毫秒，用户体感已经明显卡顿，这时候该查代码逻辑而不是加带宽
- 来源IP的集中度：某个IP每秒请求数超过50次，直接拉黑，十有八九是脚本刷接口
错误日志：先看堆栈再谈修复
错误日志不是所有Exception都值得半夜爬起来处理,真正的优先级排序是：
- 数据库连接池耗尽：
Connection pool exhausted这类报错直接导致订单无法提交，必须最高优先级 - 接口超时：外部第三方支付回调超时，影响的是真实交易链路
- 内存溢出（OOM）：Java应用最常见，OOM之前往往有GC频繁的先兆，日志里会反复出现
GC overhead limit exceeded - 业务自定义异常：库存不足、优惠券过期这类属于业务逻辑，告警级别可以放低
慢查询日志：数据库层面的隐形杀手
电商系统里，慢SQL造成的故障占比相当大，mysql的慢查询日志打开后,重点看两个参数：
long_query_time设置为
1秒
就够，不用设成0.5秒，否则日志量太大淹没有效信息log_queries_not_using_indexes打开，专门抓那些没走索引的全表扫描
实操命令参考：tail -f /var/log/mysql/slow.log实时盯，配合pt-query-digest做离线分析。
安全日志：别等被攻击了才想起来看
很多电商团队忽略了安全日志，其实登录失败的连续记录、敏感接口的异常访问都在这里，建议把/var/log/secure或/var/log/auth.log纳入监控范围，暴力破解的特征是同一IP短时间大量Failed password条目。
负载告警的阈值设置：必须贴合电商业务特性
负载告警不是单纯的“CPU超过80%就报警”，而是要结合电商的流量波浪线，电商业务有明显的平峰期（工作日白天）、晚高峰（20-23点）、大促期（618、双11、年货节）,阈值不能一套走天下。
四类核心指标的阈值参考
| 指标 | 常规阈值 | 大促临时放宽 | 说明 |
|---|---|---|---|
| CPU使用率 | 连续5分钟>75% | 可放宽到90%，但需缩短检查间隔 | 电商的CPU峰值来得快退得也快，5分钟窗口能过滤毛刺 |
| 内存使用率 | >80%且持续10分钟 | >90%且持续3分钟 | 重点看swap使用情况，swap开始增长说明内存真的吃紧了 |
| 磁盘I/O等待 | >15%持续5分钟 | >25%持续2分钟 | 大促时订单写入频繁，I/O等待过高会拖垮数据库 |
| 带宽占用 | 峰值超过总带宽70% | 超过85%且持续3分钟 | 带宽打满不一定会挂，但会导致请求超时连锁反应 |
告警级别别只设一种，分三档才科学
- Warning（黄色）：短信通知技术负责人，处理时限2小时，适合单指标越界但系统仍可用的情况
- Critical（红色）：电话通知+自动降级预案触发，适合双指标同时越界或核心交易接口成功率下跌
-
Info（蓝色）
：仅记录日志，适合监控项恢复、流量自然回落等状态变化
告警疲劳怎么破：聚合规则比数量更重要
业内专家指出，告警信息“轰炸”是运维团队最头疼的问题，一套有效的规则比多发一百条通知有用，具体做法：同一台服务器5分钟内同类告警只发一次；同一业务集群的告警自动聚合成一条摘要；深夜时段（0点-6点）只发Critical级别。
日志与负载的关联分析：两个场景帮你快速定位
日志和监控指标分开看都是“死数据”，合在一起才是“活线索”,电商运维最常遇到的两个场景可以用关联分析快速定位。
CPU飙升但找不到凶手进程
这种“只见贼吃肉，不见贼挨打”的情况,常规思路是三板斧：
top找到CPU占用最高的进程PIDtop -Hp PID查线程IDjstack PID导出线程快照，搜线程ID对应的堆栈
但更高效的路子是先看访问日志：awk '{print $9}' access.log | sort | uniq -c | sort -rn | head，如果发现某类请求量激增,直接锁定时段回查该接口的代码逻辑即可确定原因。
大促前压测时内存告警
压测发现内存持续走高，先别急着加配置，日志里有没有OOM异常？GC日志里Full GC频率多长时间一次？如果Full GC超过每秒1次，说明堆内存设置不合理,调JVM参数比扩内存省钱得多。
监控方案的选型：云厂商自带工具还是开源生态自建
- 云厂商方案（简米云监控、酷番云云监控）：部署门槛低，Agent装上即有默认告警模板可用，适合中小电商团队，但自定义告警规则和日志分析能力相对有限
- 开源方案（Prometheus + Grafana + Alertmanager）：灵活度最高，是多数中大型电商的选择，能支持复杂的业务指标，但需要专人维护
- 商业APM（听云、博睿数据）：端到端追踪能力强，能看到从用户点击到后端处理的全链路时序图，价格上通常确实比自建方案贵不少
不差钱的电商团队选商业APM，追求性价比选开源三件套，人手不足且业务规模小选云厂商自带方案。
日志治理的日常工作流：三个动作形成闭环
告警不是终点，日志归根结底要服务于排查和优化,建议每个团队固定下来的三个日常动作：
- 每日：花费10分钟查看前一日的错误日志Top5，顺便结合访问日志筛选出独立访客数、订单转化量等基础数据作为后续分析依据
- 每周：整理一次慢查询列表，逐个确认是否因数据量自然增长而需要加索引
- 每月：做一次日志存储空间的容量评估，确认磁盘是否够用，不需要算得太精确，估算出大致趋势即可
Q&A：电商服务器日志监控与负载告警高频问题
Q：跨境电商团队的日志监控与国内电商有什么区别？
A：最主要的差异在于时区与峰值时段不同国内电商晚高峰集中在20-23时，跨境电商则因为面向北美或欧洲用户，流量高峰往往出现在北京时间的下午，跨境团队需要把不同的自然商户流量高峰叠加起来看，或直接优先关注支付链路日志，此外不同云厂商的日志服务在海外节点支持度上常有差异,部署时建议以就近原则为准。
Q：不开通服务器日志的云主机怎么排查负载问题？
A：使用云服务商的基础监控API获取数据仍是可行路径，常规排查逻辑是，先看网络与磁盘I/O是否存在明显波动，再结合服务端错误率判断是否指向应用自身，如果仍然没有头绪，最简单的办法是从客户端发起压测，模拟出现问题的路径，边压边观察服务器响应趋势的变化，部分云厂商的轻量日志服务也有免费额度可用,临时开通的价值大于保留观测数据本身。
Q：日志监控与负载告警的自动化执行适合用脚本实现吗？
A：适合，但在正式环境批量执行前需要经过充分验证并加好规则限制，常见做法是用Shell脚本做定时任务扫查日志文件大小与最新写入时间，配合健康检查脚本测试关键接口返回状态，生产环境务必为所有脚本设置超时时间与异常退出码,防止监控任务自身卡死反而造成额外负担。