# 简介

# 监控工具

  • Zabbix :于 2001 年发布。
  • Nagios :于 2002 年发布。
  • Graphite :于 2008 年发布。
  • Datadog :于 2009 年发布。
  • Promethues :于 2015 年发布。
  • Open-Falcon :于 2015 年由小米公司开源,采用 Golang 开发。
  • Grafana :于 2014 年发布。不能采集监控数据,只负责显示监控图表,通常与 MySQL、InfluxDB、Promethues 等监控数据源组合使用。

# 监控策略

  • 采用自动化的监控工具取代人工巡检,可以更直观地查看系统状态、记录日志,更及时地发现异常。
  • 有的监控指标可能平时不会关注,如果开销不大,则应该也记录下来,有备无患。
  • 从多个层面进行监控:
    • 服务器状态:比如 CPU 使用率、IO 速率、Socket 数量。
    • 进程外部状态:比如进程数、CPU 使用率。
    • 进程内部状态:比如异常数、日志中是否报错。
    • 中间件状态:即 MySQL、Redis 等中间件的内部状态。流行的中间件一般能自己提供这些监控信息。
    • 业务状态:比如用户数、请求数、响应速度。
  • 显示监控指标的几种图表:
    • 文本
    • 曲线图:适合每秒都在变化的指标。
    • 条状图:适合几分钟才变化一次的指标。
    • 饼状图:适合总量固定的多个指标,表示百分比关系。
  • 将不同的监控指标用不同的颜色标明:
    • 绿色:代表良好状态,或者取值越大越好的指标。
    • 灰色:代表不需要关注。
    • 蓝色:代表正常状态,但是取值越小越好的指标。
    • 黄色:代表轻微异常,可以忽视。
    • 橙色:代表明显异常,需要处理,但并不紧急。
    • 红色:代表危险状态,需要立即处理。

# 告警策略

  • 当监控系统发现某个指标的值不符合预期时,应该标识为异常状态,并发送警报(Alert)。

  • 发送警报的策略:

    • 允许暂停发送警报,便于调试。
    • 在 m 时长内 n 次满足告警条件,才发送警报,从而减少误报。
    • 发送一个警报之后,如果一直满足告警条件,则需要间隔一段时间才能重复发送,从而避免告警风暴。
    • 尽量对警报去重,比如同一应用的不同实例共用一个警报、同一对象的严重警报会覆盖不严重警报。
    • 当告警解除时,应该再发送一个消息通知用户。
  • 应该为警报划分几种严重等级,例如:

    等级 含义 处理措施 通知人
    FATAL 很严重 应该立即处理,紧急 发送邮件+短信给相关负责人,甚至更高级的负责人
    ERROR 错误 需要处理,但并不紧急 发送邮件给相关负责人
    WARN 警告 不一定要处理 发送邮件给相关负责人
    INFO 提示 可以忽略,相当于日志 默认不会发送给用户
  • 平时查看警报的需求:

    • 先查看当前存在的警报
      • 先查看包含多个警报的简介列表,再点击单个警报查看其详情
    • 再查看出现过的所有警报,并标明它们是否已处理
  • 处理警报的策略:

    • 警报出现之后应该尽早解决,不要忽视警报而一直保留它,否则就失去了告警的意义。
    • 对于经常重复出现的告警,可以尝试用脚本自动化解决,比如当进程异常退出时自动重启。
    • 使用一个告警平台,统一接收不同来源的警报(比如 HTTP 、SMTP 方式的警报),然后按自定义的告警策略转发出去。
    • 每条警报应该记录这些信息:简短标题、具体描述、开始时间、结束时间、负责人、处理人、处理方法。

# 链路追踪

  • 分布式系统通常包含大量组件,出现故障时难以定位问题,需要排查各个组件的日志报错、监控图表。链路追踪(Tracing)技术是一种定位问题的方案。

    • 2010 年,Google 发布论文,介绍了内部的一个分布式链路追踪系统 Dapper 。受此启发,之后出现了多种链路追踪工具。
  • 用户向业务系统发出一个请求时,首先会有一个服务处理该请求,并可能调用其它服务 API ,以此类推。调用到的所有服务 API 称为一个调用链路。

    • 一个调用链路称为一个追踪(trace),分配一个全局唯一的 traceId 。
    • trace 中调用的每个服务 API 称为一个跨度(span),分配一个在当前 trace 唯一的 spanId 。
      • 每个服务 API 被调用时,需要记录一份 span 监控数据。比如当前的 traceId、执行的函数名、执行结果、起止时间等,便于追踪。
      • 上游服务调用下游服务时,称为后者的 parent span 。通常在 HTTP 调用请求的 Header 中加入 traceId、parentId 等信息,便于追踪。
  • OpenTracing

    • :一个 API 规范,用于实现链路追踪,与平台无关、与语言无关。
    • Zipkin、SkyWalking 都支持 OpenTracing 。
    • 2022 年,CNCF 宣布将 OpenTracing 项目归档,建议用户迁移到新项目 OpenTelemetry 。
  • OpenTelemetry

    • 2019 年,从两个开源项目合并而来:
      • OpenTracing :制定了实现链路追踪的 API 规范。
      • OpenCensus :用于实现链路追踪、指标度量,并提供了多种语言的 SDK 库。