Sentry基本原理

Sentry基本介绍

Sentry 是一个实时事件日志记录和汇集的平台。其专注于错误监控以及提取一切事后处理所需信息而不依赖于麻烦的用户反馈。它分为客户端和服务端，客户端(目前客户端有Python, PHP,C#, Ruby等多种语言)就嵌入在你的应用程序中间，程序出现异常就向服务端发送消息，服务端将消息记录到数据库中并提供一个web页方便查看。

Sentry由python编写，源码开放，性能卓越，易于扩展，目前著名的用户有Disqus, Path, mozilla, Pinterest等。

简而言之就是对我们的应用错误信息记性整理和汇总，并且可以邮件通知。让我们可以及时监控系统的出错情况。

Sentry的原理

那么Sentry是如何实现实时日志监控报警的呢？首先，Sentry是一个C/S架构，我们需要在自己应用中集成Sentry的SDK才能在应用发生错误是将错误信息发送给Sentry服务端。根据语言和框架的不同，我们可以选择自动或自定义设置特殊的错误类型报告给Sentry服务端。

系统架构

Sentry基本原理

Sentry的服务端分为web、cron、worker这几块，我们的应用只是把错误信息上报给sentry的web端。web处理后放入消息队列或Redis内存队列，worker从队列中消费数据进行处理。
主要处理这些数据的逻辑和队列的压力都在sentry服务端那边。所以实质上对我们系统性能的影响不大。

聚合策略

Sentry 按照策略将日志事件进行聚合，从而提供一个 issue的events 。这么做就是为了智能地帮助我们组合关联的日志信息，减少人工的日志信息的提取工作量，关注一个 issue 首先关注这些聚合的事件。但是这个策略分组并不会那么智能，Sentry 主要按照以下几个方面，优先级从高到低进行日志事件的聚合：

Stacktrace
Exception
Template
Messages

要注意的是，如果日志记录比较随意，聚合的效果可能不尽如人意。例如：两个无关的事件但是 stacktrace 相同，那么 Sentry 会将它们分到同一个 issue 下。

错误数据上送原理

sentry会借助logback将我们定义需要上送的日志进行【sentry消息上报】，其上报的过程通过源码：
Sentry基本原理
可以看出，他会将要上报的信息通过线程池进行异步上报，最小程度影响接入客户端的性能。弊端就是该事件未必能按发生的顺序被sentry服务接收。

如果上送的日志信息过多，sentry一个缓冲，如果有配置缓冲目录，会进行一定的缓冲，默认的缓冲大小10。
但是缓冲目录是本地目录，先写入本地磁盘，然后再慢慢推。所以对IO的消耗也是不可忽略的，所以一般也不建议开启。

Sentry是个辅助工具，无法替代日志、监控

Sentry 的目的是为了让我们专注于系统与程序的异常信息，目的是提高排查问题的效率，日志事件的量到达一个限制时甚至丢弃一些内容。官方也提倡正确设置 Sentry 接收的日志 level 的同时，用户也能继续旧的日志备份（用 logback 的同学仅仅是保留自己以前的 appender 就好）。

Sentry 是带有一定策略的问题分析工具，以样本的形式展示部分原始日志的信息。信息不全面的同时，使用过程中也可能出现 Sentry 聚合所带来的负面影响，特别是日志记录质量不够的情况下。

与传统的监控系统相比，Sentry 更依赖于发出的日志报告，而另外一些隐藏的逻辑问题或者业务问题很可能是不会得到反馈的。