SRE-分布式系统的监控

1、术语定义

  • 监控(monitoring):收集、处理、汇总,并且显示关于某个系统的实时量化数据,例如请求的数量和类型,错误的数量和类型,以及处理用时,应用服务器的存活时间等。
  • 白盒监控(white-box monitoring):依靠系统内部暴露的一些性能指标进行监控。包括日志分析、Java虚拟机提供的监控接口,或者一个列出内部统计数据的HTTP接口进行监控。
  • 黑盒监控(black-box monitoring):通过测试某种外部用户可见的系统行为进行监控。
  • 监控后台(dashboard):提供某个服务核心指标一览服务的应用程序。该应用程序可能会提供过滤功能、选择功能,但是最主要的功能时用来显示系统最重要的指标。该程序同时可以显示相应团队的一些信息,包括目前工单的数量、高优先级的Bug列表、目前的on-call工程师和最近进行的生产发布等。
  • 警报(alert):目标对象是某个人法向某个系统地址的一个通知。目的地可以包括工单系统、Email系统,或者某个传呼机。相应的,这些警报被分类为:工单、Email警报,以及紧急警报(page—)。
  • 根源问题(root case):系统中的某种缺陷。这个缺陷如果被修复,就可以保证这种问题不会再以同样的方式发生。
  • 节点或者机器(node、machine):指的是物理机、虚拟机,或者容器内运行的某个实例。
  • 推送(push):关于某个服务正在运行的软件或者其配置文件的任何改动。

2、为什么要监控

  • 分析长期趋势:数据库目前的数据量,以及增长速度。又例如每日活跃用户的数量增长的速度。跨时间范围的比较,或者是观察实验组与控制组之间的区别。
  • 处理故障报警
  • 构建监控后台页面
  • 临时性的回溯分析(在线调试)

3、对监控系统设置合理的预期

  • 专职人员负责持续优化和改进监控系统
  • 监控系统规则遵循简单的原则
  • 不建议在监控系统中维护较为复杂的依赖关系

4、现象与原因

监控系统应该解决两个问题:什么东西出现故障,以及为什么出故障。
现象与原因的示例:

现象与原因的区分是构建信噪比高的监控系统时最重要的概念。

5、黑盒监控与白盒监控

黑盒监控与白盒监控最简单的区别是:黑盒监控是面向现象的,代表了目前正在发生(而非预测会发生的)的问题,即系统现在有故障。百合监控则大量依赖对系统内部信息的检测,如系统日志、抓取提供指标的HTTP节点等。白盒监控系统因此可以检测到即将发生的问题以及那些重试锁掩盖的问题等。

6、4个黄金指标

  • 延迟
  • 流量
  • 错误
  • 饱和度

7、关于长尾问题

采用直方图的形式,比如:延迟为 010ms之间的请求数量有多少,30100ms之间,100~300之间等。将直方图的边界定义为指数型增长是直观展现请求分布的最好方式。

8、度量指标时采用合适的精度

9、简化,知道不能再简化

设计监控系统时一定要追求简化:

  • 那些最能反映真实故障的规则应该越简单越好,可预测性强,非常可靠
  • 那些不常用的数据收集、汇总,以及警报配置应该定时删除
  • 收集到的信息,但是没有暴露给任何监控台,或者被任何警报规则使用的应该定时删除

10、监控系统的长期维护

在现代生产环境中,监控系统需要跟随不断演变的软件一起变化,软件经常重构,负载特性和性能目标也经常变化。

11、小结

健康的监控和警报系统应该是非常简单、易于理解的。紧急警报应该关注于现象,针对原因的一些启发性分析应该作为调试过程中的补充,而不应该进行报警。监控的技术栈层面越高,监控现象越容易,但是监控某些子系统(如数据库)的饱和度和性能参数可能要在该子系统内部直接进行。Email警报的价值通常极为有限,很容易变成噪声。我们应该倾向于构建一个良好的监控后台页面,直接显示所有的非紧急的异常情况。

长远来看,要建立一个成功的on-call轮值体系,以及构建一个稳定的产品需要选择那些正在发生和即将发生的问题来进行报警,设置一个可以实际达到的合理目标,保证监控系统可以支持快速的问题定位与检测。

  • 版权声明: 本博客所有文章除特别声明外,均采用 Apache License 2.0 许可协议。转载请注明出处!
  • © 2020 ChpiTer
  • Powered by Hexo Theme Ayer

请我喝杯咖啡吧~

支付宝
微信