面临的问题
程序运行的日志是一个必不可少的东西，可能是一些系统信息，比如gc的情况；可能是一些正常的模块处理信息，比如最近更新的配置；还可能是一些在程序运行中，我们不希望出现的错误所带来的信息。通过日志，可以知道我们的程序是不是在正常地运行，看到错误日志，我们还需要利用日志排查错误。
我们知道日志如此重要，并乐于记录日志，然而在发现并解决问题的过程中，日志并没有想象中的高效率。
1. 文件过于分散
一般会将不同模块的日志以文件的形式分开保存。即使是将日志写在统一的目录下，不管是系统正常运行还是出现问题的时候都可能需要检查多个日志。
2. 内容过于繁杂
不太同于代码崇尚简洁，特别是遇到问题的时候，日志更是越详细越好，巴不得日志能记录下所有上下文信息和关联的代码。但是在查看日志的时候却往往不得不反复前后翻看错误的关联日志信息，同时还要略过大量无关信息，还没开始解决问题脑细胞就死了好多。
3. 解决问题的被动性
很可能在程序刚开始运行起来的时候，我们会检查一下情况，看看日志是否正常。但是更多的时候我们根本不会想去看那些冗长的日志。过了一段时间，突然有人告诉我们问题出现了，便又怀着沉重的心情慌张地检查日志开始排查错误。
如何解决
考虑传统的解决方案，规定好统一的日志格式，将所有模块的日志进行适配之后统一管理起来，并建立相应的日志分类与报表，在检查到问题的时候通过邮件的形式通知运维。这样的解决方案对于小公司来说，需要的时间和技术成本还是很大的，真正能提高日志利用的效率，还需要很长的规划与不断的总结。
而我们这样的小公司就中意这样的简单粗暴的方案：1个小时搭建整个平台、日志汇集，聚合，主动报警，漂亮的界面，都有了——Sentry。
那么Sentry到底如何帮助我们有效利用日志发现并解决程序问题的呢。
Sentry初试
Server的安装教程官网已经非常详细了，如果不要求HA，只需要额外确定依赖的redis和postgresql安装好了就行。
支持多种语言与框架的客户端
Sentry不但有多种语言的客户端，还直接支持大量的日志框架，比如java的log4j，logback。这就意味着我们之前的代码几乎可以不用做任何修改，而仅仅加一点配置即可。
官方saas
如果想要快速欣赏一下Sentry的芳容，可以现在就尝试一下官方的saas（当然它是免费的）：
Sentry团队很贴心地让你可以快速建立一个自己的demo尝试它的运用。
简单的使用示例
拿官方的saas快速认识Sentry：
注册好你的账户后，会有提示帮助你建立好自己的项目，并选择想要使用的客户端平台或框架（这里以logback为例）：
（usage那里需要打马赛克）
到这里为止，我们就差一步就可以看到效果了：添加一个依赖和一个logback的appender到你的项目配置里，其他的代码可以一点不变，记日志还是熟悉的配方。
配置好依赖和appender，运行一些写入日志的代码后，你就会收到两方面的反馈：
1. 面板上出现待解决的issues：
2. 收到新issues的邮件：
怎么样，对Sentry已经有了一个直观的感受了吧。
Sentry如何解决问题
我们使用Sentry就是为了解决日志利用的低效率问题，那么Sentry是怎么帮助我们解决的呢。答案就在几个重要的概念中，当然Sentry有详尽的官方使用说明和文档。
dsn（data source name）：
示例中是加在appender中的标签。这个就是Sentry的实际连接地址，Sentry通过这个来知道到底将日志发送到哪里。
issues&events：
从上面的图可以发现有3个error标记的issue标签，实际上代码里面发送了5条error的日志。这是Sentry很重要的一点：我们需要看的不是单单一条日志，而是一类日志。一些聚集的日志才能尽可能地反映整个错误的情况，即一个issue，而这些有关联的日志在Sentry这边就转化为这个issue的关联的events。回想一下我们通过日志文件来排查错误的时候，是不是就是自己耐心地运用肉眼过滤掉一系列无关的日志，然后大脑中聚合好这些有关联的日志，尽可能全面地了解一个错误呢。除了帮我们省掉这些事情，Sentry提供了更丰富的数据来充实这些events，点击一个issue，便会进入这个issue的详细信息：
