日志分析和故障排查的若干意见
概述
日志中的数据分析本质是属于数据分析的范畴，和故障排查理论上来说应该是分开进行的。不同的数据规模总是会有不同的解决方案。
日志数据分析需要进行的准备工作
一般来说，日志数据的分析都是离线，定时来进行的。常用流式处理框架。很多数据公司都有解决方案。另外需要在日志的生产环节做好定义，越是结构化的数据，分析的难度越低。
日志分析的数据来源一般包括业务日志和容器的日志。也可能还包括操作系统日志。日志级别的定义也是比较重要的。一般也可以考虑从逻辑上将日志按照文件来拆分。总之就是日志生产环节做的工作，好处都会在后面的分析，排查和监控环节放大。
日志分析属于数据分析的范畴，所以在客户端需要做好埋点（需要做到精确定义好不同的用户行为或者系统行为,不要在一个数据埋点中标识多个行为）。服务器端也要做好埋点（一般为了区分，称之为桩）。一般来说服务的日志分析是以请求为核心来做的。每次请求，需要定义好元数据(ip, sessionId, requestId, service信息, 浏览器或者Client信息等),做好埋点和桩，进行pv，uv和其他统计是轻而易举的事情。(多说一句，压力测试的请求在请求报文里要做好标记，不纳入统计,测试客户端类同)
不同数据规模采用的分析方案建议如下。
- 每日日志0~20G时,分析项少于20项 shell脚本(其他简单工具u)+定时任务即可
- 超过此数据规模，可以考虑引入流式处理的框架。
日志分析的需求点
- 可以直接参考友盟 | TalkingData或者其他第三方数据分析平台的数据点及呈现形式，然后从中识别出哪些是通过日志分析作为数据源来获得的。顺便可以总结出他们的其他数据分析需求（省的自己去想应该分析哪些数据）。电商平台的数据分析可以是另外一个话题。
实时数据分析
对应的，有些时候会依赖实时的数据统计做一些策略，所以实时数据分析一般在开始阶段会做成准实时的。识别清楚数据分析的复杂度和需求的复杂度，控制好定时任务执行的粒度和时间。
在线的故障排查和离线的故障统计
- 服务的稳定性可以通过故障统计来衡量，所以分析，故障排查和监控是三个逻辑独立又互相关联的话题，大的架构上来说肯定是应该分别独立出来的。
- 在线排查已经有很多成熟的架构，现在用的ELK就是很好的:)。建议用熟一套架构就好，因为在线排查需要经验和技巧结合，有很多技巧是取决于客观条件的，可能不太好变更。
- 在线排查也需要结合在日志中埋好点来做。另外可能定义好异常处理的机制（许多新的框架都会定义好异常处理的逻辑，并且会收集未处理的异常，这块也要作为架构选型的一个考虑点）
- 可以采用一些方式来主动把异常通过邮件、推送等形式来暴露出来。以便及时发现并且排查故障。第三方的工具也有很多。（比如我们在用的dataDog）
- 在线排查很重要的就是要在日志中记录关键信息，控制好日志的规模，以减少整个系统的日志负载。尤其对于大规模系统架构，日志一定要设计的优雅，有效。（他应该告诉你你需要完成的工作的最少的信息。）需要记的都要记录，不需要记录的就不记录。
- log4j或者类似的日志处理的基础设施，要研究清楚他们的能力。;)
- 离线的故障统计可以算是另一个层面的日志数据分析。原则上和处理方式上和日志数据分析一致，不再多说。目标则是为了度量系统的可用性方面的问题。可以结合其他系统度量指标一起来分析。一般维度就包括请求响应时间（客户端的），请求处理时间(服务器端的)，成功率。。。这个不用详细说了。
- 离线故障统计和处理优先级应该是挺高的。
监控
- 在线排查和监控有时候可以使用同样的工具和类同的流程，但是一定是两个层面的东西，都需要考虑。
- 监控一般可以由开发和运维商量起来做。同样也是识别好需求复杂度，指标的严重程度，避免监控信息过度或者不足。一开始就制定好原则，工作就会好开展很多。（一般一开始很容易全部都给报出来，出个小错也报警，就会很耽误团队的精力）（比如请求连续10次出现超时邮件报警，20次超时短信报警，确定好度量的指标和对应的预警机制。然后每小时给出一个统计数据，，诸如此类的）
另外，总体来说，工具很多，选择一个比较能覆盖上述维度的，减少在各个环节的切换也很重要。我们现在就用腾讯的企业邮箱，加上微信绑定提示，直接将许多预警的东西都放到里面了。这样更有利于大家建立统一的沟通机制，减少工作的复杂度。
版权声明
本文标题:6-日志分析和故障排查的若干意见
文章作者:盛领
发布时间:2017年01月05日 - 00:32:18
原始链接:http://blog.xiaoyuyu.net/post/2b36c5a8.html
许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。
如您有任何商业合作或者授权方面的协商，请给我留言：sunsetxiao@126.com
