乐趣区

小白学习如何打日志

前言

只有光头才能变强。

文本已收录至我的 GitHub 仓库,欢迎 Star:https://github.com/ZhongFuCheng3y/3y

记得之前写过一篇:《阿里巴巴 Java 开发手册》读后感,之前自学时由于没怎么接触过打“日志”,所以《手册》中的“日志规约”我就先放一边去了。

而之前写了一篇:在公司做的项目和自己在学校做的有什么区别?中就有提到:公司的项目不会有 e.printStackTrace(); 这种代码的存在。因为这打印出来的错误信息 没有日期、等级 等等,分析起来不方便。

在工作中去服务器上查日志又是一个非常非常常见的操作,所以当初我又写了一篇 工作中常用到的 Linux 命令,里边就谈到了查日志时常用的 Linux 命令。

想着,既然接触日志也有一段时间了,不妨在回看《手册》,看看有什么要注意的地方,于是就有了这篇笔记。

一、Java 打日志的基础

以前自己自学的时候,排查问题只会写下面的代码:

try {// doSomething} catch (Exception e) {e.printStackTrace();
}
----------
// 查看某个数据的值时:System.out.println(xxxx);

去到公司就发现上面的代码全不见了,剩下的是:

LOGGER.info("begin to run Java3y:{}", id);
----
LOGGER.error("excepiton occurs when run Java3y {}, exception{}", id, e.toString());

如果使用 e.printStackTrace(); 的话,打印在控制的信息分析不方便:

而我们将信息分 等级和时间 记录在服务器的磁盘上,有问题了就可以根据对应的信息去查找相关的日志(这样排查起来是十分方便的):

我们再来看一下一般的日志长什么样的:

例如:现在有人来反馈某某某用户好像收不到短信,给出 发送时间和用户 ID,我们就可以在日志上找出该用户在我们系统的发送状态(例如图上的:state:81,我们就认为是发送成功状态)

那么,问题来了,我们 在哪打日志?《手册》上其实已经给出了答案:

谨慎地记录日志。生产环境禁止输出 debug 日志;有选择地输出 info 日志;如果使

用 warn 来记录刚上线时的业务行为信息,一定要注意日志输出量的问题,避免把服务器磁盘

撑爆,并记得及时删除这些观察日志。

大量地输出无效日志,不利于系统性能提升,也不利于快速定位错误点。记录日志时请思考:这些

日志真的有人看吗?看到这条日志你能做什么?能不能给问题排查带来好处?

1.1 什么叫做 打点?

打日志最常见的就是用来打印出 程序执行时的相关信息,用于快速定位问题和排查问题。我一开始也是这么理解的,但是其实还可以延伸一下。

我现在搞的那个系统,我们还使用日志在系统的执行链路上 打点。比如说,我现在要推送一条通知消息,通知消息其实就是下面这种:

这个过程大概是如此的:

  • 首先别人调用我的 RPC 提供的接口(或者我自己调用自己的接口),发现这是一个通知消息。于是我组装成对应的 Task,异步放到消息队列中
  • 另一个系统从消息队列中取出 Task,对这个 Task 进行业务的处理(比如说是否夜间屏蔽,是否强制发送等等),然后调用 HTTP 接口把这个 Task 交给下游
  • 下游做的事其实也很多,整块链路很长(比如要调用 SDK 的库,Android 和 IOS 又做不同的处理)

而我们又希望在推送完了之后能统计出一些 指标 (曝光量,点击率,转化率)等等。于是乎,就需要在一些关键的位置上打一个日志(专业点叫做 打点

在整块链路都打通了以后,将这些 点位 (日志)收集起来,放到实时流式处理平台(storm/flink) 上清洗 / 过滤。如果是实时需要用到的放到 Redis,离线的放在 Hive。

二、手册规范

2.1 使用门面模式的日志框架

【强制】应用中不可直接使用日志系统(Log4j、Logback)中的 API,而应依赖使用日志框架

SLF4J 中的 API,使用 门面模式的日志框架 ,有利于维护和各个类的 日志处理方式统一

门面模式我之前也写过一篇笔记:三分钟学会门面模式!

其实说白了就是希望 抽象出一层 API,能够在切换具体日志框架的时候不需要大面积更改

这个我们可以按学 JDBC 的时候去理解:

无论我是接入 MySQL、Oracle 还是 SQL Server,但我的接口永远都是那一套,切换数据库时不需要更改我的 Java API

看了一下公司的项目,采用的是SLF4J+Logback

2.2 调用 RPC 接口使用 Throwable 类拦截

【强制】在调用 RPC、二方包、或动态生成类的相关方法时,捕捉异常必须使用 Throwable

类来进行拦截。

之前在排查问题的时候,有个问题死活排不出来,DeBug 的时候一直没进 catch 模块。后来我学长就说:“要不你改成 Throwable 试试?

try {} catch (Throwable e) {}

我就很疑问,说:“为啥要改成 Throwable 呢?我们用 Exception 不就可以捕获所有的异常了么,Exception 是 Throwable 的一个子类,但 Exception 已经是包含所有的 Java 异常了呀”

众所周知,Throwable 有两个子类:

  • Error(一般我们都会把这个忽略掉 … 一般情况下出现了 Error 程序都运行不起来)
  • Exception
The  Throwable class is the superclass of all errors and exceptions in the Java language

在《手册》上也有对上面的规则进行说明:

说明:通过反射机制来调用方法,如果找不到方法,抛出 NoSuchMethodException。什么情况会抛出

NoSuchMethodError 呢?二方包在类冲突时,仲裁机制可能导致引入非预期的版本使类的方法签名不匹

配,或者在字节码修改框架(比如:ASM)动态创建或修改类时,修改了相应的方法签名。这些情况,即

使代码编译期是正确的,但在代码运行期时,会抛出 NoSuchMethodError

大概的意思就是说:调用 RPC、二方包、或动态生成类的相关方法时,可能直接抛出的是 Error,而 catch Exception 是无法捕获得到的。

想看例子的同学可以看看这篇文章:

  • https://zhuanlan.zhihu.com/p/57950399

最后

参考资料(阿里巴巴开发手册下载地址):

  • https://github.com/alibaba/p3c

查阅资料时发现的好文:

  • https://www.cnblogs.com/chenhongliang/p/5312517.html
  • https://www.cnblogs.com/crazyacking/p/5456347.html

乐于输出 干货 的 Java 技术公众号:Java3y。公众号内 有 200 多篇原创 技术文章、海量视频资源、精美脑图,关注即可获取!

觉得我的文章写得不错,点

退出移动版