一、为什么用Sentry？
随着平台的规模越来越大，平台的日志散落在各个地方，无法统一管理。而且使用的有多种开发语言(H5,ANDROID,IOS,JAVA,Python)，想规范和统一日志也是比较困难的。日志文件过于分散，日志内容过于繁杂，发现和解决问题被动。为了提高错误发现和排查的效率，我们引入Sentry。
Sentry是一个集中式日志管理系统。它具备以下优点：
- 多项目，多用户,界面友好
- 报警的规则多样性：可以配置异常出发规则，例如发送邮件，钉钉
- 报警的及时性：不需要自己再去额外集成报警系统，一旦产生了 issue 便以邮件通知到项目组的每个成员。
- 问题关联信息的聚合：每个问题不仅有一个整体直观的描绘，聚合的日志信息省略了人工从海量日志中寻找线索，免除大量无关信息的干扰。
- 丰富的上下文：Sentry 不仅丰富还规范了上下文的内容，也让我们意识到更多的有效内容，提高日志的质量。
- 支持主流语言接口：从Sentry的文档首页截下来的一张图，可以看到它支持目前主流的编程语言。
- issues & events：在相同地方产生的异常会被归纳为一个「Issue」，每次在这个地方产生的异常叫做「Event」。所以在同一个地方触发两次异常，仍然只有一个Issue，但是可以在Event页面看到多个[Event]。
- 聚合策略：Sentry 按照策略将日志事件进行聚合，从而提供一个 issue的events 。这么做就是为了智能地帮助我们组合关联的日志信息，减少人工的日志信息的提取工作量，关注一个 issue 首先关注这些聚合的事件。但是这个策略分组并不会那么智能，Sentry 主要按照以下几个方面，优先级从高到低进行日志事件的聚合：Stacktrace、Exception、Template、Messages。
- alerts digest & limit：默认 Sentry 的 alerts 会发送邮件。当一个 issue 产生或者一组 issue 产生时，项目相关的成员都会受到邮件。但是并不是每次 issue 有更新就会产生 alert 。考虑到用户也不希望被一箩筐的报警邮件给轰炸，因为过多相当于没有， Sentry 除了对重复的报警进行抑制，还会追加一段时间内更新 issue 的摘要（digest）到下一个报警，这样，用户邮件上接收到的信息会充分压缩，不用苦恼于过多的邮件。另外，每个用户可以根据自己的喜好自行配置报警的时间间隔。
总之Sentry 还有有很多亮点，比如敏感信息过滤，release版本跟踪，关键字查找，受影响用户统计，权限管理等（部分可能需要我们通过代码提供内容）可以通过 Sentry 进行问题分配与跟踪。Sentry 的 plugin 模块还可以集成大量的第三方工具如：slack ，jira 。
对我们来说最大的便利就是利用日志进行错误发现和排查的效率变高了。但是，我们能不能完全依赖Senry呢？有几点值得探讨：
- 不是日志的替代品
Sentry 的目的是为了让我们专注于系统与程序的异常信息，目的是提高排查问题的效率，日志事件的量到达一个限制时甚至丢弃一些内容。官方也提倡正确设置 Sentry 接收的日志 level 的同时，用户也能继续旧的日志备份。
- 不是排查错误的万能工具
Sentry 是带有一定策略的问题分析工具，以样本的形式展示部分原始日志的信息。信息不全面的同时，使用过程中也可能出现 Sentry 聚合所带来的负面影响，特别是日志记录质量不够的情况下。
- 不是传统监控的替代品
与传统的监控系统相比，Sentry 更依赖于发出的日志报告，而另外一些隐藏的逻辑问题或者业务问题很可能是不会得到反馈的。
原文链接：https://blog.csdn.net/wshl1234567/article/details/100763464