代码中的异常(exception), 是三个部分组成的. 不信你往下看.
0x00 举个例子
看如下错误的堆栈信息：
java.lang.RuntimeException: error occur
at test.mysql.ExceptionTest$DemoClass.callErrorMethod(ExceptionTest.java:19)
at test.mysql.ExceptionTest.testException(ExceptionTest.java:14)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at test.demo.DemoMain.method1(Demo.java:20)
如果想知道这个调用路径错误出现了多少次，最简单的办法就是搜索对应的字符串 test.mysql.ExceptionTest$DemoClass.callErrorMethod(ExceptionTest.java:19)，无论是最原始的去原始日志中执行 grep ， 或者去 ELK 中搜索。但这个结果真的精确吗？
仔细观察，下面这个堆栈信息的调用路径，和第一个有什么不同？
java.lang.RuntimeException: error occur
at test.mysql.ExceptionTest$DemoClass.callErrorMethod(ExceptionTest.java:19)
at test.mysql.ExceptionTest.testException(ExceptionTest.java:14)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at test.demo.DemoMain.method2(Demo.java:40)
是的，两个虽然长得类似，但调用路径确实不相同的，一个是从 test.demo.DemoMain.method1() 开始， 另一个是从 test.demo.DemoMain.method2() 而来。因此，这两个不是同一种错误。
0x01 异常拆解
仔细想，可以把一个错误的堆栈分成三个部分：
- exception：就是指具体的 exception 类。比如上述例子就是
java.lang.RuntimeException - exception message：指当时创建 exception 时填入的错误具体信息。上述例子中就是这句
error occur - exception fingerprint：异常的指纹，代表当前错误发生时程序的调用路径。上述例子中，两个异常的调用路径时不同的， 因此 exception fingerprint 也应该不同
那么如何计算 exception fingerprint？其实也很简单，直接 md5(stacktrace_without_message_string) 就足够了。上述例子中， 直接堆栈信息中出去 error occur 的字符串的 md5 值即可。
0x02 如何使用？
直接在日志中 grep 然后跨行计算 md5 肯定是很蛋疼的。可现在大家不都是 docker 化 + 统一收集应用日志（比如 ELK）吗？
以 Java 应用为例, 通过一个 appender, 将日志发送到集中的日志收集服务, 对其中 ERROR 级别的日志计算 exception finterprint. 开发人员直接通过 web 界面查询错误日志信息.
0x03 回头再看 exception
拆解 exception 后, 引申出抛出异常时的一些 best practice
3.1 同种类型的错误, 使用同一种类型的 exception.
很多语言都支持通过继承基础 exception 类的方式, "创造"出多种 exception 类型
3.2 写好 exception 中的 message
exception message 中务必携带有用的 context 信息, 用于后续排查错误. 很多这里做的不够好, 每次出现错误都需要去翻源码获取最基本的错误信息. 例如, Java 中如下一段代码在不同线程执行两次, 会出现端口被占用的错误.
try {
ServerSocket socket2 = new ServerSocket(9090);
socket2.accept();
Thread.sleep(10000000);
} catch (Exception ex) {
ex.printStackTrace();
}
但你看一眼错误信息: Address already in use, 仅此而已. 你倒是告诉我到底是哪个端口被占用了啊! 临时工写的代码十几年都没人修改过?
java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:382)
at java.net.ServerSocket.bind(ServerSocket.java:375)
at java.net.ServerSocket.<init>(ServerSocket.java:237)
at java.net.ServerSocket.<init>(ServerSocket.java:128)
at test.mysql.ExceptionTest$Server
3.3 多使用 �exception fingerprint 精确定位同一个错误
如果实现了 exception fingerprint 功能, 就可以在 ELK 中方便的使用 fingerprint 字符串搜索出同一种错误, 并且获得统计结果.
0x04 总结
计算 fingerprint 不仅限于 exception, 试想, MySQL 的 slow query 是不是也可以计算 fingerprint ?
-- EOF --
