高效利用Sentry追踪日志发现问题

面临的问题

程序运行的日志是一个必不可少的东西，可能是一些系统信息，比如 gc 的情况；可能是一些正常的模块处理信息，比如最近更新的配置；还可能是一些在程序运行中，我们不希望出现的错误所带来的信息。通过日志，可以知道我们的程序是不是在正常地运行，看到错误日志，我们还需要利用日志排查错误。

我们知道日志如此重要，并乐于记录日志，然而在发现并解决问题的过程中，日志并没有想象中的高效率。

01文件过于分散

一般会将不同模块的日志以文件的形式分开保存。即使是将日志写在统一的目录下，不管是系统正常运行还是出现问题的时候都可能需要检查多个日志。

02内容过于繁杂

不太同于代码崇尚简洁，特别是遇到问题的时候，日志更是越详细越好，巴不得日志能记录下所有上下文信息和关联的代码。但是在查看日志的时候却往往不得不反复前后翻看错误的关联日志信息，同时还要略过大量无关信息，还没开始解决问题脑细胞就死了好多。

03解决问题的被动性

很可能在程序刚开始运行起来的时候，我们会检查一下情况，看看日志是否正常。但是更多的时候我们根本不会想去看那些冗长的日志。过了一段时间，突然有人告诉我们问题出现了，便又怀着沉重的心情慌张地检查日志开始排查错误。

如何解决

考虑传统的解决方案，规定好统一的日志格式，将所有模块的日志进行适配之后统一管理起来，并建立相应的日志分类与报表，在检查到问题的时候通过邮件的形式通知运维。这样的解决方案对于小公司来说，需要的时间和技术成本还是很大的，真正能提高日志利用的效率，还需要很长的规划与不断的总结。

而我们这样的小公司就中意这样的简单粗暴的方案： 1 个小时搭建整个平台！日志汇集、聚合、主动报警、漂亮的界面，都有了—— Sentry 。

那么 Sentry 到底如何帮助我们有效利用日志发现并解决程序问题的呢？

Sentry 初试

Server 的安装教程官网已经非常详细了，如果不要求 HA ，只需要额外确定依赖的 redis 和 postgresql 安装好了就行。