55最佳实践系列：Logging最佳实践

最新推荐文章于 2021-10-25 20:08:05 发布

iteye_5612

最新推荐文章于 2021-10-25 20:08:05 发布

阅读量159

点赞数

分类专栏：最佳实践系列文章标签： logging log 最佳实践

本文链接：https://blog.csdn.net/iteye_5612/article/details/82516553

版权

最佳实践系列专栏收录该内容

18 篇文章 0 订阅

订阅专栏

@郑昀汇总创建日期：2012/10

#意识

ASAP (As Soon As Possible)原则

当线上出现诡异问题，

当你意识到靠现有的日志无法定位问题时，

当现象难以在你的开发环境重现时，

请不要执著于枯坐肉眼看代码，因为：一）不一定是你代码逻辑问题，可能是脏数据造成的，是老业务数据造成的，是分布式环境造成的，是其他子系统造成的；二）线上业务处于不稳定中，条件不允许问题定位无限期。

此时， 请立即在问题相关的调用链条上，一次性：

在函数的入口和出口打印日志，同时打印输入、输出参数
catch(){……}里打印stacktrace，同时打印try块中关键变量的值（避免你发现某个异常是问题第一原因，却不知道是什么变量传入导致的）
与其他模块交互的接口入口处打印输入参数，

即， 解决线上问题归根结底要靠log、a lot of log output！

在logging的力度上切勿犹犹豫豫，我们的工程师习惯于吝啬地找两个函数打印日志、打包部署一把、没看出来、再找几个函数打印、再部署、等着现象重现再观察、……，一来二去时间流逝，闲庭信步，从客服知道的小事故变成了全国皆知的大事故。

所以，再强调一遍： 在你的调用链条上，逐层调用的函数入口和出口都打印详细日志，不怕多只怕少，然后部署，等待现象重现，毕其功于一役！

我们要记录什么？

1）完成某项操作所需的时间

通过它可以跟踪为什么系统响应变慢或者太快

处理完一个incoming request所耗费的时间，精确到毫秒
执行数据库查询的时间
从磁盘或者存储介质获取数据的时间
等等

2）异常和堆栈跟踪

3）Sessions

知道一个问题是由谁引起的非常重要，因此在日志中使用会话标识符就变得必不可少。它可以简单到是一个 IP 地址或者是一个更复杂的 UUID，只要能区分不同的请求者就足够。

4）版本号

#工具

推荐的Java Logging框架

1）log4j：我们的配置是，log4j.appender.CONSOLE.layout.ConversionPattern= [%-d{yyyy-MM-dd HH\:mm\:ss.SSS}] [%p] [%c] [%m]%n；%p是日志优先级，%c是类目名，%m是输出信息，%n是回车换行符。

2）logback：log4j创建人Ceki Gülcü后续推出了SLF4J+logback。SLF4J(Simple Logging Facade for Java)作为commons-logging的替代，为各种logging APIs提供了一个简单的统一接口，使得最终用户能够在部署的时候配置所希望的logging APIs的实现。logback胜在性能，据称“某些关键操作，比如判定是否记录一条日志语句的操作，其性能得到了显著的提高。这个操作在logback 中需要3纳秒，而在 log4j 中则需要30纳秒。 logback 创建记录器（logger）的速度也更快：13毫秒，而在 log4j 中需要23毫秒。更重要的是，它获取已存在的记录器只需94纳秒，而 log4j 需要2234纳秒，时间减少到了1/23。跟java.util.logging(JUL)相比性能提高也是显著的”。

#配置

不要随便从网上找一个log4j的配置文件，请确认你理解每一个配置项

我们既然输出日志，自然期望在面对“ 这个问题是否从过去几天开始出现？”这样的疑问时，不至于发现你的rollingPolicy错误设置导致只能看到最近几小时的日志，或者日志发生时间没有精确到毫秒。

后面会张贴主站生产环境里的log4j配置。

#理念

可用grep抽取的日志：独立的行！

我们总是希望能用grep处理日志文件。这意味着： 一个日志条目永远不应该跨多行，除非你是堆栈打印。

我们会用grep问日志什么问题呢？如：