1.面临的问题程序运行的日志是必不可少的东西，可能是一些系统信息，比如gc的情况；可能是一些正常的Module处理信息，比如最新更新的配置；也可能是一些我们不想在程序运行过程中出现的错误信息。通过日志，我们可以知道我们的程序是否正常运行。当我们看到错误日志的时候，我们也需要通过日志来排查错误。我们知道日志是如此重要，我们也乐于记录日志。但是，在发现问题和解决问题的过程中，日志并没有想象中的那么高效。1.如果文件太分散，不同模块的日志会以文件的形式分开保存。即使日志写在一个统一的目录下，无论系统运行正常还是出现问题，都可能需要查看多条日志。2、内容过于复杂，与崇尚简洁的代码不一样。尤其是遇到问题的时候，日志越详细越好。我希望日志可以记录所有上下文信息和相关代码。但是，在查看日志的时候，经常要反复来回查看错误的相关日志信息，同时跳过很多不相关的信息，很多脑细胞还没有开始解决问题就死掉了。3、解决问题的被动性。很可能在程序开始运行的时候，我们会查看情况，看日志是否正常。但更多时候我们不想看那些冗长的日志。过了一会儿，突然有人告诉我们有问题，我们怀着沉重的心情，慌张地查看日志，开始排查。2、传统方案如何解决，规定统一的日志格式，对所有模块的日志进行适配和管理，并建立相应的日志分类和报表，运维发现问题时邮件通知。对于小公司来说，这样的解决方案需要大量的时间和技术成本，需要长时间的规划和不断的总结，才能真正提高日志的利用效率。而像我们这样的小公司，喜欢这样简单粗暴的方案：一小时搭建整个平台！日志收集、聚合、主动告警、界面美观，统统都有——Sentry。那么Sentry是如何帮助我们有效的利用日志来发现和解决程序问题的呢？1、Sentry的初始服务器安装教程官网很详细。如果不需要HA，只需要确保安装了依赖的redis和postgresql即可。支持多种语言和框架的客户端Sentry不仅有多种语言的客户端，还直接支持大量的日志框架，比如java的log4j和logback。这意味着我们之前的代码几乎不能修改，只需要做一点配置。官方saas如果你想快速领略Sentry的美妙之处，现在就可以试试官方saas（当然是免费的）：Sentry团队很友好，可以让你快速搭建一个属于自己的demo来试用。2.简单使用示例拿官方saas快速认识Sentry：注册账号后，会有提示帮你搭建自己的项目，选择你要使用的客户端平台或框架（这里以logback为例）):至此，我们只差一步就可以看到效果了：在你的项目配置中添加一个依赖和一个logbackappender，其他代码可以保持不变，logging还是熟悉的套路。配置完依赖和appender，运行一些写入日志的代码后，你会收到两个反馈：（1）面板上出现未解决的问题：（2）收到新问题的邮件：怎么样，是的，Sentry已经有一个直观的感觉。3、Sentry如何解决问题我们使用Sentry来解决日志利用率低的问题，那么Sentry是如何帮助我们解决的呢。答案在于几个重要的概念。当然，Sentry有详细的官方说明和文档。dsn(datasourcename):示例中是添加到appender的标签。这是Sentry的实际连接地址，Sentry使用它来知道将日志发送到哪里。Issues&events：从上图中，我们可以看到有3个issue标签和error标签。事实上，代码中发送了5个错误日志。这是Sentry很重要的一点：4.我们要看的不是单个日志，而是一类日志的一些聚合日志，尽可能反映整个错误情况，也就是一个issue，以及这些相关的日志在Sentry这边转化为与这个问题相关的事件。回想一下，我们在通过日志文件排查错误时，是不是耐心地用肉眼过滤掉一系列无关的日志，然后在大脑中聚合这些相关的日志，尽可能全面地理解一个错误。Sentry除了帮我们保存这些东西，还提供了更丰富的数据来丰富这些事件，点击一个issue，就会进入这个issue的详细信息：不仅可以看到我们主动添加的message和stacktrace，Sentry还帮助我们添加了一些额外的标签（我们还需要自己定义一些有用的标签），以尽可能多地展示问题发生前的情况。另一个亮点在右边，显示了这个问题的一些统计数据。(1)SamplingSentry不是做日志存储的，也不会记录所有的日志（毕竟是用关系型数据库做持久化存储）。每条发给哨兵的日志都是一个提供问题信息的事件，每个项目发给哨兵的事件都有一个上限。一旦超过这个上限，Sentry就会忽略重复的内容。Sentry是我们所有关于错误、问题的日志的分析子集。界面反映的事件信息也是哨兵聚合的样本。(2)聚合策略Sentry根据策略聚合日志事件，提供一个issue的事件。这样做是为了智能地帮助我们组合关联的日志信息，减少手动提取日志信息的工作量，并且在关注问题时首先关注这些聚合事件。然而，这种策略分组并不是那么智能。Sentry主要按照以下几个方面来聚合日志事件，优先级从高到低：StacktraceExceptionTemplateMessages需要注意的是，如果日志记录是随机的，聚合效果可能不太好。如你所愿。例如：两个不相关的事件但有相同的堆栈跟踪，那么哨兵会将它们分组在同一个问题下。(3)alertsdigest&limit默认情况下，Sentry的alerts会发送邮件（你也可以pushslack！）。当一个问题或一组问题产生时，项目的相关成员将收到电子邮件。但并非每次更新问题时都会生成警报。考虑到用户不希望被大量的告警邮件轰炸，太多等于没有，Sentry不仅会抑制重复告警，还会更新一段时间内的issue摘要到下一次告警，这样一来，用户邮箱上收到的信息就会被完全压缩，这样就不用担心邮件太多了。此外，每个用户都可以根据自己的喜好配置报警的时间间隔。5.总结Sentry还是有很多亮点的，比如敏感信息过滤，发布版本跟踪，关键词搜索，影响用户统计，权限管理等（有些可能需要我们通过代码提供内容）可以通过赋值和跟踪哨兵。Sentry的插件模块还可以集成大量的第三方工具如：slack、jira。对我们来说最大的方便就是利用日志进行错误发现和排查的效率变高了。1.及时提醒告警的时效性：无需自己集成额外的告警系统，一旦出现问题，项目组的每个成员都会收到邮件通知。2.问题相关信息的聚合不仅每个问题都有一个整体直观的描述，而且聚合的日志信息免去了人工从海量日志中寻找线索的麻烦，避免了大量无关信息的干扰。3、丰富的上下文Sentry不仅丰富和规范了上下文的内容，也让我们意识到了更多有效的内容，提高了日志的质量。六、***，完全靠哨兵？Sentry虽然提高了我们使用日志的效率，但是还是有几点需要注意。1.它不是日志替换。Sentry的目的就是让我们关注系统和程序的异常信息。目的是为了提高故障排除的效率。当日志事件数量达到限制时，甚至会丢弃一些内容。官方也提倡正确设置Sentry接收的日志级别，同时用户可以继续旧的日志备份（使用logback的同学只要保留之前的appender即可）。2.Sentry不是解决错误的优秀工具。它是一种具有一定策略的问题分析工具，以样本的形式展示一些原始的日志信息。虽然信息并不全面，但Sentry聚合的负面影响也可能在使用过程中出现，尤其是在日志记录质量不够的情况下。3.不能替代传统监控与传统监控系统相比，Sentry更依赖于发布的日志报告，而其他隐藏的逻辑问题或业务问题可能得不到反馈。【本文为栏目组织《奇安科技》原创文章，转载请微信公众号（bigsec）联系原作者】
