生产环境ERROR日志治理总结
生产环境 ERROR 日志治理总结
原创 有赞技术 有赞 coder;)
有赞 coder
微信号 youzan_coder
功能介绍 有赞技术官方公众号，推广有赞技术干货，偶有有赞技术小哥哥小姐姐们的日常
今天
收录于话题
点击关注 “有赞 coder”
获取更多技术干货哦～
作者：kobe
部门：质量保障
没有仪表盘的车，那是自行车，只要会骑，人人都能骑 ······
有仪表盘的车，没有故障灯，会开车的人可以开但也有坏的时候 ······
有仪表盘的车，如果全是 ERROR 告警，估计也没人敢开，因为不知道会发生什么 ······
1. `客户反馈系统又不好使了，客满找到了技术，技术才知道系统又崩了···`2. `技术开始排查，发现全是ERROR日志，大海捞针，排查难，定位难，故障持续时间长，恢复慢`3. `事后复盘，灵魂拷问：有报ERROR吗？有；有告警嘛？有；那为啥没有第一时间发现呢？日志太多了，告警太多了，被淹没了，关注不到···`
以上这些是问题嘛？是，客观存在，是我们一年前面临的问题，怎么办？想办法解决呗 ··· 面对线上问题，故障频发，发现手段滞后，只能依赖商家客户的反馈，进而导致客服成本高，压力大，针对这种情况，首先明确一个问题，线上问题会被彻底消灭嘛？答案是：不会，那既然不会我们还能做什么呢？第一时间发现，快速修复 —- 要做到这些，监控告警是非常有效的第一时间发现故障的手段，我们期望达到的目标是每一次告警都是有效的，为了这个目标我们做了两个专题：一个是 ERROR 日志治理的专项工作；另外一个是提升系统业务水位监控告警的敏感度和精确度；这两个专题相辅相成，其中重点介绍一些系统 ERROR 日志的治理经验总结，这项治理给我们带来的收益是很明显的。
怎么实现呢？先看看问题：
- ERROR 级别的日志太多 —- 不精准，不全面，不清晰；
- 告警太多，关注不到 —- 不精准，不具体，范围不够广；
我们先说说 ERROR 日志的问题，打印日志简单，打印好日志 ——- 难！！！
写日志主要是为了下面的需求：
- 记录用户操作的行为日志。
- 方便快速定位问题，
- 追踪程序执行的过程
- 追踪数据的变化
- 数据统计和性能分析
- 采集运行环境数据
我们遇到一个问题，什么时候打印 ERROR，什么时候打印 Waring，Info 就不说了？
- info 用于打印程序应该出现的正常状态信息，便于追踪定位；
- warn 表明系统出现不合理但不影响运行和使用；
- error 表明系统出现了错误，无法完成目标操作，必须人工介入分析处理；
以上是官方的解释，但是具体怎么判断呢，一句话 “如果告警出来，你是否需要介入处理，如果是就打 ERROR，如果不是就打 Waring，不要担心写的 ERROR 多了，报警出来的就会多，很多时候系统运行正常的情况下是不会有 ERROR 日志产生的，如果你的 ERROR 日志处理足够细致准确的情况下”。
确定标准，我们要根据各自系统的情况，确定目标：将每天的 error 日志降到多少条，100，200··· 有个目标就行。
具体怎么做的？每天关注生产环境的 ERROR 日志，进行归类分析并及时解决，持续做好直到达成目标。
- 可以利用运维平台统计应用每天 ERROR 日志的量，找出 Top10 并针对性的解决；
- 看一下应用每天磁盘 IO 的量，来判断日志的读写是否影响磁盘的性能；
问题总结：
- 在 ERROR 日志梳理的过程中我们会发现很多线上的 bug，需要对 ERROR 进行深入分析；
- 一些问题可能在代码上线之初是不存在的，但是在数据量达到一定量级的时候就会触发，例如典型 mysql 超时的问题，索引失效的问题；
- 对于上下游系统的一些超时配置是否合理进行验证；
- 对代码进行优化调整，在排查问题的过程中发现因为历史积累的原因，有些代码逻辑已经不用了，或者逻辑顺序需要调整，对性能提升很有帮助；
- 接口的梳理和优化，对于同一个功能的接口可能会因为历史原因有好几个，这个时候可以统一替换成最高效的那个，某些情况下也可以进行拆分；
- 对于依赖上下游解决的问题能够进行一个数据统计，通过拿到的数据去 push 上下游进行改造优化；
- 对于一些 TSP 的任务，已经失效的可以进行清理；
- 堆栈信息缺失，导致定位问题困难或者无从定位；
期待达到的状态：
如果只是针对 ERROR 日志进行处理的话，我们能达到的状态是持续的投入解决问题，来降低 ERROR 日志的数量，另外一个角度要将已经出现的问题进行总结，定期和组内研发 / 测试同学分享，避免问题重复出现，从根本上减少问题的发生，形成一个良性的循环状态。
最终达到目标：每一次告警，都是有效问题需要介入处理，缩短故障的影响时间和影响面，规范的日志内容提高了排查的效率；
带来的其他价值：
- 做好系统稳定性的一个很好的切入点；
- 帮助我们了解系统在线上的一个状态，存在的问题，还能通过定位问题，了解相关的系统；
- 通过对 ERROR 日志的治理，减少不必要的告警，提升告警的敏感度；
- 提升测试在开发团队的影响力；
- 推动告警配置的完善；
- 遇到的问题类型：
- 逻辑需要优化、告警级别需要调整、依赖方的问题、环境问题、历史脏数据问题、上下游发布导致、接口超时、索引问题、mysql 问题、tsp 定时任务问题
取得的成果
近一年绝大部分线上问题都是监控告警首先感知，监控告警的敏感度有了极大的提升，在线上问题升级故障前就发现，有效减少了线上故障。
生产 ERROR 日志的产生类型也极大的减少，从原来每天上百种类型到目前的个位数，数量从之前的最高峰值上万到现在的平均每天 100 条左右；
“有这么一句话，错误日志应该做到，即使离开了代码情境，也能清晰的描述发生了什么。”
这就对了日志提出了如下的要求：
- 日志的可读性；
- 日志的性能；
- 占用的磁盘空间；
- 日志的时效性；
- 日志的级别；
- 日志的内容（打印错误日志内容的基本原则：完整、具体、直接、格式规范、多用关键字）
还有一些情况要介绍一下
我们通常知道对 ERROR 日志进行告警的配置，配置在单位时间内 Waring 达到一定数量进行告警，但是存在这样一种情况，在业务上是正常的报错（例如参数校验未通过，可能是使用姿势的问题），这个时候没有打 ERROR 打的是 Waring，但是正常情况下这个 Waring 会一直处于低水位状态，如果某一天水位出现大幅上升也代表存在问题，这个时候要配置对应的水位告警，具体的水位条件需要根据各个业务的具体情况和发展进行分析和动态的调优。
除了日志级别的监控外，在一些数据统计上也可进行监控，例如我们对出金系统每天的出金数据进行统计并通知出来，每天成功，失败，异常等状态的数据会是一个比较稳定的状态，某一天如果数据出现明显的变化，就代表系统很有可能存在问题，这是另外一个维度的监控。
在与开发同学协作的过程中遇到的问题
- 同一个问题不喜欢提多个 jira（需要我们将同类型的问题进行聚合，需要测试同学有定位问题的能力）
- 开发同学对 jira 比较敏感，习惯于第一时间处理（非紧急类型的问题可以找时间统一处理，不必第一时间处理）
- 对于下游依赖问题，认为推动解决比较困难，并且认为这不是一个问题，认为不应该处理（这一类型的问题需要记录下来，由测试同学 Owner 起来用数据说话推动上下游合作方进行解决，最好给出自己的解决方案）
- 对于已经习惯了的问题知道原因和影响范围不大，自动放过，不处理，缺少深入分析（有问题就一定要处理，如果不是大的问题就要打 ERROR 级别的日志会干扰我们监控告警的敏感度）
- 认为处理这些 jira 会占用开发同学的时间（首先要达成共识，这是一件长期有价值的事情，是在质量保障和长期投入成本投入的角度来讲，是划算的）
拓展阅读：
- 有赞业务中台测试团队介绍
- Dubbo 压测插件 2.0 —— 基于普通 API 调用
- 有赞精准测试实践
- K8S 在有赞 PaaS 测试环境中的实践
- 一次 Logback 发现的隐患
- 有赞持续集成容器化实践
- 前端精准测试探索：覆盖率实时统计工具
Vol.361
预览时标签不可点
收录于话题 #
个
上一篇 下一篇
阅读
分享 收藏
赞 在看
已同步到看一看写下你的想法
前往 “发现”-“看一看” 浏览“朋友在看”
前往看一看
看一看入口已关闭
在 “设置”-“通用”-“发现页管理” 打开 “看一看” 入口
已发送
取消
发送到看一看
发送
生产环境 ERROR 日志治理总结
最多 200 字，当前共字
发送中
喜欢此内容的人还喜欢
[
API 分页设计与实现
API 分页设计与实现
…
高可用架构
不喜欢
不看的原因
确定
- 内容质量低
- 不看此公众号
](javascript:void(0);)[
关于团队，leader 必须要思考的这些问题
关于团队，leader 必须要思考的这些问题
…
架构师之路
不喜欢
不看的原因
确定
- 内容质量低
- 不看此公众号
](javascript:void(0);)[
配置即代码：先有鸡还是先有蛋
配置即代码：先有鸡还是先有蛋
…
ThoughtWorks 洞见
不喜欢
不看的原因
确定
- 内容质量低
- 不看此公众号
](javascript:void(0);)
微信扫一扫
关注该公众号
微信扫一扫
使用小程序
微信版本过低
当前微信版本不支持该功能，请升级至最新版本。
确定删除回复吗？
若有收获，就点个赞吧
0 人点赞
