LeoHsiao's Notes

# 简介

# 监控工具

  • Zabbix ：于 2001 年发布，可采集监控指标、显示监控图表，但技术较旧。
  • Nagios ：于 2002 年发布。
  • Graphite ：于 2008 年发布。
  • Datadog ：于 2009 年发布。
  • Prometheus ：于 2015 年发布，主要用于采集监控指标。
  • Open-Falcon ：于 2015 年由小米公司开源，采用 Golang 语言开发。
  • Grafana ：于 2014 年发布。不能采集监控数据，只负责显示监控图表，通常与 MySQL、InfluxDB、Prometheus 等监控数据源组合使用。

# 监控策略

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

# 告警策略

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

  • 发送警报的策略：

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

  • 应该为警报划分几种严重等级，例如：

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

  • 平时查看警报的需求：

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

  • 处理警报的策略：

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

# 链路追踪

  • 2010 年，Google 发布论文，介绍了内部的一个分布式链路追踪系统 Dapper 。受此启发，之后出现了多种链路追踪（Tracing）工具。

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

  • 用户向业务系统发出一个请求时，首先会有一个服务处理该请求，并可能调用其它服务 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 库。