返回首页
当前位置: 主页 > 精通Office > 其他教程 >

基于Sentry搭建错误日志监控系统

时间:2017-09-18 23:20来源:知行网www.zhixing123.cn 编辑:麦田守望者

错误日志监控也可称为业务逻辑监控, 旨在对业务系统运行过程中产生的错误日志进行收集归纳和监控告警。似乎有那么点曾相识?没错… 就是上一篇文章提到的“APM应用性能监控”。但它又与APM不同,APM系统主要注重应用层的行为分析,收集的更多是运营方向的数据。而sentry所做的是收集应用底层代码的崩溃信息,便于码侬们排查代码异常。简单来说它就是一个面向技术码侬的排障工具。

1. 场景描述

随着运维自动化流程的推进, 各类运维工具和系统也像雨后春笋般涌现. 目前我们自主开发的运维系统的数量已经接近两位数. 这些系统部署在多台机器上, 通常还配套一批后台运行的脚本. web端如果出现异常, 开发人员可以及时得到反馈进行修复. 而脚本因为没有交互, 可能会出现发生重大故障时才定位到问题的情况.

2. 既有方案

  1. 后端和脚本用python内置的日志模块记录程序中间状态, 同时也将两者的输出重定向到指定文件, 以获取未捕获的异常信息.
  2. 同台服务器上多个系统的日志集中存放到同个目录
  3. 使用rsync定时从多台服务器中拉取日志文件
  4. 对日志文件进行关键字匹配, 并将过滤结果通过邮件发送给运维开发人员

最终整合的通知邮件如图

运维自动化

3. 存在的问题

上面的操作部分解决了脚本运行状态监控盲区的问题, 但还存在如下问题

  1. 无法第一时间感知错误
    脚本日志的拉取不是实时的, web端用户的反馈也往往存在滞后. 出现问题到解决问题的周期太长, 容易导致工作陷入被动.
  2. 错误信息的获取相对低效
    用户反馈和邮件告警包含的错误信息非常有限, 最终都不得不在大量的日志中上下翻看关联的信息. 可能还需要在测试环境下给代码埋点多获取一些中间变量数据, 给定位问题带来很多麻烦.
  3. 日志的处理方式不够灵活
    通常来说, 除了程序运行出错, 我们还关心其他异常情况, 比如数据污染, 非法请求, 第三方API调用异常等. 如果将此类等同错误记录下来, 很容易造成告警滥发, 而如果不处理此类异常, 久而久之可能导致严重的问题. 我们希望同样的日志内容可以根据场景不同灵活处理
  4. 监控覆盖面有限
    完整的监控应该涵盖脚本, 后端以及前端三个部分. 特别是我们新的运维系统实现了前后端分离之后, 很多前端的问题无法被统一记录下来.

鉴于此, 我们了解了一些日志收集和监控方案, 选择了sentry.

4. sentry初探

4.1 概览

sentry是一个现代化的错误日志记录和聚合平台。支持几乎所有主流开发语言和平台, 并提供了现代化UI, 如图

sentry

与ELK, splunk不同, sentry专注于应用程序产生的错误日志的聚合和监控. 官方提供了多个语言的SDK.

SDK

多达30种集成方式

让开发者第一时间获悉错误信息, 并方便的整合进自己和团队的工作流中.

4.2 使用前后对比

为了直观的展示sentry的强大, 这里模拟一个常见的场景, 如有雷同, 纯属巧合.

4.2.1 场景一

接入sentry前

  • 用户A: 发布功能用不了
  • 开发者A: 哪个页面? 截个图
  • 用户A: (发截图)
  • 开发者A发现bug可以重现, 登录服务器查看错误日志, 确认程序逻辑无问题, 查看数据库数据, 发现有脏数据. 联系开发者B检查负责更新数据的python脚本C.py.
  • 开发者B登录服务器查看错误日志, 发现一个逻辑错误导致脚本罢工, 已持续了一个小时. 影响了数千条数据

接入后

  • 开发者A,B同时收到邮件告警, 一分钟前脚本C.py异常退出.
  • 开发者B进入sentry后台查看错误信息, 定位问题并将其修复, 再清理受影响的数十条数据.
  • 在此过程中没有用户受到影响, 无需开发者A介入
------分隔线----------------------------
标签(Tag):Sentry 错误日志监控系统
------分隔线----------------------------
推荐内容
猜你感兴趣