中小规模互联网平台的系统监控体系

| |
本文是最近对监控体系认识的总结。系统监控是通过技术手段发现服务异常，并持续优化业务可用性与用户体验的行为。它有监控体系和模型、监控平台、人员与组织等方面组成。本文试图对各方面的思路、设计和实践进行梳理。
但是由于时间关系，很多认识还不是很深入、细致,希望在后续章节中不断补充。

0x1 什么是监控

定义

通过技术手段发现服务异常，并持续优化业务可用性与用户体验的行为。

目标

  1. 及时发现问题
  2. 能够快速对问题进行定位

衡量标准

  1. 全面，建立立体的监控体系，并持续优化
    • 横行覆盖：各个产品以及产品间的流程
    • 纵向覆盖：从用户体验到基础设施各层面
  2. 准确，尽力避免误报，不断降低漏报。
  3. 及时，提升监控的性能，降低监控数据流的延迟。

0x2 体系模型

由于分布式系统的复杂性，要达成及时发现问题，以及快速定位问题的目标，监控系统一般被设计成多层面、多维度的立体监控模式。同时构建与之匹配的监控与告警工具、人员组织和流程支持。

维度

横行维度

在横行上，监控体系可以按业务域/业务/业务活动/支持系统 逐级划分。根据每个领域的特点，分别定义需要监控的项目。在此过程中，还要综合考虑SLA要求/系统现状/人力资源/成本等要素。

纵向维度

按照从用户请求到系统处理的过程依赖关系，可以划分为以下的监控分层结构。上级的分层依赖下级，监控的可以按层次逐级梳理和定义。

标准指标

确定需要收集的指标类型十分重要，这些指标和应用程序相关。选择的指标可以简化故障发生时排除故障的流程，并且还可以在服务和基础设施上保持很高的稳定性。

RED方法遵循Google在Four Golden Signals中提及的原则，聚焦于检测最终用户在使用web服务时关心的东西。

在RED方法中，我们通过监控三项关键指标来管理架构中的每个微服务：

  • （Request）Rate – 你的服务所服务的每秒的请求数
  • （Request）Errors – 每秒失败的请求数
  • （Request）Duration – 每个请求所花费的时间，用时间间隔表示

RED方法希望由Rate、Errors、Duration三项指标涵盖最典型的Web服务问题。同时这些指标还能够反映出请求的错误。通过这三项指标，我们就能监测到通常情况下会影响客户体验的问题。

如果想要获得更细节的信息，还需要用到Saturation指标。Saturation指标用在USE（Utilization Saturation and Errors）方法中，它指的是一种带有额外作业的资源，而该资源不能够提供服务，因此必须添加到队列中以备后续处理。

为什么需要标准指标？
相同的监控指标，可以让监控都变得一样。这既减少了团队针对特定的服务进行培训的数量，还减少了在高压事件响应场景或者所谓“认知负载”这些针对特定服务的特殊情况发生时，呼叫者需要记录的内容。同时，简化了监控逻辑，降低了监控自动化的实现成本。

0x3 监控平台

统一监控平台由七大角色构成：监控源、数据采集、数据存储、数据分析、数据展现、预警中心、CMDB(企业软硬件资产管理)。

  1. 监控源：即按照上述“横行” 和 “纵向” 划分的监控项目
  2. 数据采集：数据源如此多样，因此数据采集的设施也是非常重要。分为采集指标和采集方式两个方面。
    • 监控指标方面，如前所述，以适合规模化推广的RED标准监控指标为主，辅以定制化指标，来实现特殊场景、问题快速定位等需求。
    • 从采集方式来说，通常可以分为接口采集、客户端agent采集、通过网络协议主动抓取（http、snmp等）
  3. 数据存储：采集到的数据一般都会存储到文件系统（如HDFS）、索引系统（如elasticsearch）、时序库（如influxdb）、消息队列（如kafka，做消息临时存储或者缓冲）、数据库（如mysql）
  4. 数据分析：针对采集到的数据，进行数据的处理。
    处理分两类：实时处理和批处理。技术包括Map/Reduce计算、全日志检索、流式计算、指标计算等，重点是根据不同的场景需求选择不同的计算方式。
  5. 数据展现：将处理的结果进行图表展现，帮助监控和分析人员，“直观”的展示监控目标的状态。此外在多屏时代，跨设备的支持必不可少。
  6. 预警：如果在数据处理过程发现了问题，则需要进行异常的分析、风险的预估以及事件的触发或告警。
  7. CMDB(企业软硬件资产管理): 软硬件资产的元数据

0x4 人力资源与组织

在复杂的监控场景面前，机器还无法代替人类—起码现阶段是这样—完成全部的事情。因此，有效的人力资源、组织方式和制度保障是非常重要的。
但是，由于公司在业务、系统复杂度、成本预算等方面，存在巨大差异，因此人力组织方面存在很大差异，应该具体分析规划。

以下是一种适合中型规模的互联网平台的监控组织模式。

  • 运维监控团队（对整体负责）
    职责：
    负责提升平台整体的可用性和用户体系

    1. 设计、搭建和运营监控系统和监控体系
    2. 面向各产品团队，提供通用化监控平台、全局监控策略，并提供人工监控台，辅助完成常规报警处置手段（重启等）
    3. 推动和协助建设监控体系，并持续优化
    4. 定期度量平台整体、各产品线的可用性与用户体验数据，并反馈

  • 产品线敏捷团队（对产品线负责）
    职责：
    负责业务域的可用性和用户体验

    1. 参与规划，并主动接入和实施平台整体监控体系
    2. 根据业务域的特点，梳理业务活动，以及业务活动的关键依赖（服务/资源/链路等）
    3. 根据1，2定义监控、告警和处置策略，坚决执行并持续优化

某公司的监控规划模版：