日志代码（小白学习如何打日志）

代码(小白学习如何记录)

一、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，这样我们就可以在日志上查到该用户在我们系统中的发送状态(比如图中状态:81，我们认为是成功发送状态)

那么，问题来了。我们在哪里保存日志？事实上，手册中已经给出了答案:

仔细记日志。生产环境禁止输出调试日志；选择性地输出信息日志；如果

第一次上线时使用warn记录业务行为信息。一定要注意日志输出的问题，避免放服务器磁盘

爆了，记得及时删除这些观察日志。

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

真的有人看日志吗？看到这个日志你能做什么？能给故障排除带来好处吗？

1.1什么是dot？

日志记录是在程序执行期间打印出相关信息的最常见方式，用于快速定位和排除问题。我一开始是这么理解的，其实可以引申。

我现在做的系统，我们也是用日志来打点系统的执行环节。比如我现在想推送一条通知消息，通知消息其实是这样的:

这个过程大概是这样的:

首先，别人调用了我的RPC提供的接口(或者我调用了自己的接口)，发现是通知消息。所以我组装了相应的任务，并将其异步放入消息队列。

另一个系统从消息队列中取出任务，处理任务(如是否夜间封锁，强制发送等。)，然后调用HTTP接口把任务交给下游。

其实下游要做的事情很多，整个环节很长(比如要调用SDK库，Android和IOS做不同的处理)

而我们希望在推送结束后统计一些指标(曝光率、点击率、转化率)等等。这样一来，你就需要在一些关键位置做一个日志(专业点叫点)。

整个链接打开后，将这些点(日志)收集起来，放到实时流平台(storm/flink)进行清洗/过滤。如果实时需要，放在Redis，离线放在Hive。

二、手册规范

2.1使用外观模式的日志框架

【强制】日志系统中的API(Log4j，Logback)不应该直接在应用中使用，而应该使用日志框架。

SLF4J的API使用facade模式的日志框架，有利于维护和统一各类日志处理方法。

我之前写过一篇关于门面模式的笔记:三分钟学会门面模式！

其实说白了就是希望抽象出一层API，不需要大量改动就可以切换具体的日志框架。

我们可以根据学习JDBC的时间来理解这一点:

无论我访问MySQL、Oracle还是SQL Server，我的界面都是一样的，在切换数据库时不需要改变我的Java API。

看看公司的项目，用的是SLF4J+Logback。

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

在调用RPC、双方包或动态生成类的相关方法时，必须使用[Force] Throwable来捕捉异常。

要拦截的类。

之前排问题的时候，有个问题无论如何排不出来。调试时，它从未进入catch模块。然后我的学长说，“你为什么不试试Throwable？

try {} catch (Throwable e) { }

我很不解，说:“为什么要改成Throwable？难道不能用异常捕捉所有的异常吗？Exception是Throwable的子类，但是exception已经包含了所有的Java异常。”

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

错误(通常，我们会忽略这一点...正常情况下，错误程序不会运行)

例外

The Throwable class is the superclass of all errors and exceptions in the Java language

手册中也解释了上述规则:

描述:通过反射机制调用方法。如果找不到该方法，则引发NoSuchMethodException。会扔什么？

NoSuchMethodError在哪里？当两个包相互冲突时，仲裁机制可能会导致引入意外的版本，这可能会使类的方法签名不匹配。

当字节码修改框架(如ASM)动态创建或修改类时，匹配或修改相应的方法签名。这些情况，即

使代码编译时正确，但代码运行时抛出NoSuchMethodError。

调用RPC、双方包或动态生成类的相关方法时，可能会直接抛出错误，但无法捕获catch异常。

Tags： 标签1 标签2

文章版权声明：除非注明，否则均为供水知识-GONGSHUI.CC原创文章，转载或复制请以超链接形式并注明出处。