系统监控

一、为什么监控，监控什么内容？

• 对系统的运行状态了如指掌，有问题及时发现，而不让用户先发现我们系统不能使用。
• 在应用程序中，通常会记录日志以便事后分析，在很多情况下是产生了问题之后，再去查看日志，是一种事后的静态分析。在很多时候，我们可能需要知道我们服务的运行情况，例如：
  • 每秒钟的请求数是多少（TPS）？
  • 平均每个请求处理的时间？
  • 请求处理的最长耗时？
  • 请求处理正确响应率？
  • 等待处理的请求队列长度？
  • 查看整个系统的的CPU使用率、内存占用、jvm运行情况；以及系统运行出错率等

二、监控的目的

• 长期趋势分析：比如资源用量预测
• 对照分析：比如两个版本系统运行资源使用情况差异
• 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员
• 故障分析与定位：通过对不同监控以及历史数据分析，能快速找到并解决根源问题
• 数据可视化：通过可视化仪表盘能直接获取系统运行情况、资源使用情况、以及服务运行状态等直观信息。

三、监控分类

四、Prometheus架构

由前 Google 员工，受 Google 内部 Borgman 的启发，2012年开始的开源项目，2018年进入毕业状态。
Prometheus：先见之明。

• 以指标名称和键值对唯一标识基于时间序列的多维数据模型
• 支持多维灵活查询的 PromQL
• 与存储系统解耦
• 基于 HTTP 协议的 Pull 模式进行时间序列指标采集
• 中间件网关支持 Push 模式
• 基于静态配置和服务发现的目标发现机制
• 灵活图形化展示

五、Prometheus 数据模型

image.png

• 指标名与标签（Metrics Name 和 Labels）
  每个业务指标有指标名和键值对标签唯一标识
• 采样点（Samples）
  每个指标收集到的采样数据有两部分组成：Timestamp、Value
• 指标表达方式
  • OpenTSDB的标识方式：
    { = , ...}
  • 示例：
    api_http_request_total{method="POST", handler="/messages"}

六、Prometheus 中的指标类型

• 
  
  
  
  
  
  
  

七、监控数据的采集

• Push or Pull

• 在 Kubernetes 集群中的监控系统
  每个节点 kubelet 会收集当前节点 host 上的所有信息，包括 CPU、内存、磁盘等。
  Prometheus 会 pull 这些信息，给每个节点打上标签来区分不同的节点。

七、数据的存储（TSDB）

八、数据的查询和消费 PromQL

九、常见问题