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