为什么咱们须要利用监控

大家是否有过这样的体验：

产品新性能上线几周后，客户提工单反馈问题。研发同学经排查确认是 bug，且会产生脏数据。最终，修复 bug + 上线花了大半天，而编写修复脚本 + 修复数据消耗了一周。

如果发现 bug 的机会越早，那么修复老本就越低。

通过对利用中的谬误或异样进行监控和主动反馈，有助于咱们尽早发现荫蔽的问题，晋升产品质量和研发效率。

日志零碎不等同利用监控零碎

可能有同学会说：程序的谬误和异样在咱们的日志零碎外面都有呀，为什么还须要专门的利用监控零碎？

的确，日志中事无巨细地记录了大量的运行过程和异样信息。不过，这些信息可能也存在反复、有效、不足分割的弊病。而且，日志次要是在研发同学排查问题时应用，很少被用于被动监控和告警，日常存在着大量的错误信息始终未被关注和解决。

Sentry：一款受欢迎的利用监控产品

Sentry 是一款开源的利用监控产品，应用 Python、JavaScript、HTML、CSS 打造。在 GitHub 上有 29k Stars，是利用监控畛域 Stars 数排行最高的开源我的项目，其官网声称有 1 百万名开发者和 7 万个组织在应用 Sentry。除了提供开源产品外，其幕后的公司也提供付费的 SaaS 服务：sentry.io。2021 年该公司发表取得了 6000 万美元的 D 轮融资，该轮融资使 Sentry 的总资金达到 1.27 亿美元，融资后估值为 10 亿美元。的确是一款值得关注的产品。

Sentry 有以下重要特点：

• 产品体验好，功能完善

• 接入工作量少

  官网和开源社区提供了各种支流开发语言和框架的 SDK，便于开发者接入，大多几十行代码内即可实现。

• Sentry 专一于 Error、Exception、Crash

  能够查看到具体的错误信息和调用栈，能疾速定位问题代码。

• 提供丰盛的上下文信息

  SDK 会主动上报根底信息，也反对上报自定义的信息，便于排查问题。

• 主动合并反复问题

  反复的报错被主动合并且累计次数，防止开发者在大量反复冗余的信息寻找 bug 的蛛丝马迹。

• 被动邮件告警

  不必再等“客户告警”后才开始排查问题。

自部署 Sentry 的毛病

• 部署依赖繁多

  利用官网的提供的 Github 仓库，基于 Docker 和 Docker Compose 的确能够一键部署、开箱即用。不过，当看到 30 个容器列在背后时，还是会感觉迟疑。

• 需自行保障高可用

  如上，Sentry 应用了泛滥组件，比方：ZooKeeper、Nginx、Redis、Memcached、Kafka、PostgreSql、ClickHouse 等，要自行运维这些组件并保障高可用，并不是容易的事件。

防止 Sentry 引发雪崩

引入新的技术或者工具，或多或少都会减少零碎的复杂度和运行危险。

咱们之前出过一次重大问题：某个日均三千万接口申请量的服务产生故障，大量的错误信息涌向 Sentry 服务器，导致 Sentry 响应重大提早，其 Redis 队列内存容量靠近占满，而 Nginx 也全都响应 504 Gateway Timeout。恰好该故障的服务因为申请 Sentry 服务端未设置超时工夫，导致 HTTP 申请同步阻塞，反倒拖垮了服务自身。

为了躲避此类问题，有以下做法：

• 保障 Sentry 服务端高可用

  这点最重要，但理论咱们并未做好。目前咱们自部署的 Sentry 是一个单点，并没有集群或冗余。如果要实现高可用，那么付出的金钱老本会较高，甚至可能超过了应用 Sentry SaaS 付费服务的老本。因为 Sentry 官网并未提供中国区的服务，HTTP 申请到国外的速度并不现实，应用官网 SaaS 服务也不见得是太好的抉择。

• 设置 timeout

  应用 Sentry SDK 时，肯定要设置向 Sentry 服务器发送申请的超时工夫，倡议 3 秒以下。

• 设置 sample_rate

  应用 Sentry SDK 时，能够设置 采样率，0.00 示意回绝发送任何事件，1.00 示意发送全副事件。倡议后期设置较小的值，而后视利用的 PV 大小进行调整。应用采样率可能会带来这样的负面影响：零星的谬误可能未上报，导致始终未被发现。

• 及时熔断
  如果当 Sentry 服务器不堪重负时，应该防止利用持续申请 Sentry 了。比方：能够手动将采样率设置为 0.00。

• 应用异步形式（async）发送申请

  如果 SDK 反对异步发送申请，那就应用，防止同步阻塞。

• 隔离生产环境的 Sentry

  运维共事隔离部署了两套 Sentry，一套是体验环境，供开发环境 / 测试环境 / 预公布环境的利用接入应用；另外一套是正式环境，供生产环境 / 私有化环境的利用接入应用。如果要试验 Sentry 的性能或调整 Sentry 的配置，那咱们会先在体验环境的 Sentry 中进行，确认没有问题后，才会调整生产环境的 Sentry，借此保障生产环境 Sentry 的稳定性。

• 通过队列来缓冲申请至 Sentry 的并发压力

  假如利用的申请量和并发量都微小，当呈现重大故障时每个申请解决都产生谬误，那么即便在 SDK 中设置了较低的采样率（比方：0.01），可能申请到 Sentry 的并发量仍旧超过其无限承载。为了防止这个问题，咱们在流量最大的服务中做了如下尝试：咱们减少了一个队列，将服务的谬误事件先入列，启动了大量的生产过程去生产该队列缓缓上报谬误至 Sentry 服务端。并且应用程序中做了解决，即便该队列容量占满也不会影响失常业务（只是抛弃谬误事件）。实践证明，这种直达缓冲的形式十分无效，不过也减少了接入 Sentry 工作量，大家可自行取舍。

Sentry 应用小技巧

• 上报 Environment

  在不同环境通过 SDK 配置不同的标识，比方：Development、Test、Release、Production、Privatisation，这样不便的辨认和过滤问题。

• 自定义 Tags

  SDK 会主动帮忙上报一些根底的 Tag，同时咱们也能增加一些自定义的 Tag（比方：租户、我的项目等业务信息），利于排查问题。

  Tag 可用于过滤：

  Tag 可用于统计：

• 主动标记已解决

  有些 bug 已修复并上线，然而研发同学个别都不记得在 Sentry 手动标记已解决；还存在第三方服务异样等不须要解决的问题，也不太会去手动标记。应用“Auto Resolve”性能，当多久内未再呈现该问题后，零碎会主动帮忙标记为已解决，很不便。

• 合并问题

  绝大多数反复问题，Sentry 都能自动识别并合并。不过偶然还是存在例外，比方：错误信息中存在一些随机的内容，那么 Sentry 可能会认为是不同类型的谬误，进而未合并，导致反复的问题始终邮件告警，很是烦人。通过设置“Fingerprint Rules”，强制指定同类谬误的“指纹”，这样就能让这些谬误进行合并了。

• 辨认并解决真正的问题，防止“狼来了”

  别动不动就抛异样或者记 error。举个例子：“您上传的文件格式不正确，请按要求上传正确格局的文件。”，其实这是一个失常的业务提醒，如果将它作为谬误上报到 Sentry，那并没有什么意义，最终也不会进行解决。如果这样的“乐音”越积越多，那么会升高研发同学对真正问题的敏感度。邮件天天收到一堆假的“狼来了”，当“狼”真来了时，咱们可能未采取行动，导致引发事变。当你听到假的“狼来了”时，正确的做法是让它闭嘴，而不是捂住本人的耳朵。比方：批改代码，不要抛异样，或者将 error 改为 warning。总之，别让它上报至 Sentry，别让它烦扰咱们辨认真正的问题。

Sentry 还提供了“性能剖析”、“面包屑”、“辨认可疑提交”等泛滥有用的性能，值得大家去摸索和应用。

咱们部门半年来应用 Sentry 的状况

• 已接入 9 个利用或服务
• 累计辨认出数十个荫蔽问题（去重后）
• 已有 3 个服务达成零问题
• 2 次辨认到了第三方服务商的异样，并及时反馈给对方解决
• 2 次及时发现了公布故障并紧急解决

总结

对利用进行监控能够被动发现荫蔽的问题，晋升产品质量。Sentry 是一款受欢迎的利用监控开源产品，领有丰盛且有用的个性，咱们抉择应用它的同时，也采取了很多措施，防止因为引入它导致产生负面影响。咱们在应用过程中积攒了一点心得，最初也取得了不错的应用成果，分享给大家，祝大家 bug 少少，效率高高。