简介

监控工具

通用监控

• Zabbix

  • ：于 2001 年发布，是一个主流的监控工具。
  • 优点：
    • 一站式监控平台，提供了常用的监控告警功能：采集各种对象的监控指标、在 Web 网页上显示监控图表、设置告警规则。
  • 缺点：
    • 技术较旧，功能、性能不如 Prometheus 。

• Prometheus

  • ：于 2015 年发布，是云原生时代最流行的一站式监控平台。

• Grafana

  • ：于 2014 年发布。
  • 优点：
    • 擅长显示监控图表，提供了多样、美观的 Web 图表。
    • 还可设置告警规则。
  • 缺点：
    • 本身不能采集监控数据，需要从 MySQL、InfluxDB、Prometheus 等数据源读取监控数据。

前端监控

• Sentry (opens new window)

  • 功能：当用户访问 Web 网页时，如果出现报错，则自动发送堆栈信息到 Sentry 服务器。
  • 优点：
    • 方便开发人员排查问题。

• PostHog (opens new window)

  • 功能：当用户访问 Web 网页时，对浏览器录屏（比如鼠标移动的轨迹），并发送到 PostHog 服务器，
  • 优点：
    • 当 Web 网页报错时，方便开发人员查看用户执行了什么操作，复现问题。
    • 方便运营人员统计用户的使用习惯。

链路追踪

• 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 库。

监控策略

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

告警策略

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

• 发送警报的策略：

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

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

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

• 平时查看警报的需求：

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

• 处理警报的策略：

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