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