一、为什么监控，监控什么内容？
- 对系统的运行状态了如指掌，有问题及时发现，而不让用户先发现我们系统不能使用。
- 在应用程序中，通常会记录日志以便事后分析，在很多情况下是产生了问题之后，再去查看日志，是一种事后的静态分析。在很多时候，我们可能需要知道我们服务的运行情况，例如：
- 每秒钟的请求数是多少（TPS）？
- 平均每个请求处理的时间？
- 请求处理的最长耗时？
- 请求处理正确响应率？
- 等待处理的请求队列长度？
- 查看整个系统的的CPU使用率、内存占用、jvm运行情况；以及系统运行出错率等
二、监控的目的
- 长期趋势分析：比如资源用量预测
- 对照分析：比如两个版本系统运行资源使用情况差异
- 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员
- 故障分析与定位：通过对不同监控以及历史数据分析，能快速找到并解决根源问题
- 数据可视化：通过可视化仪表盘能直接获取系统运行情况、资源使用情况、以及服务运行状态等直观信息。
三、监控分类
四、Prometheus架构
由前 Google 员工，受 Google 内部 Borgman 的启发，2012年开始的开源项目，2018年进入毕业状态。
Prometheus：先见之明。
- 以指标名称和键值对唯一标识基于时间序列的多维数据模型
- 支持多维灵活查询的 PromQL
- 与存储系统解耦
- 基于 HTTP 协议的 Pull 模式进行时间序列指标采集
- 中间件网关支持 Push 模式
- 基于静态配置和服务发现的目标发现机制
- 灵活图形化展示
五、Prometheus 数据模型
image.png
-
指标名与标签（Metrics Name 和 Labels）
每个业务指标有指标名和键值对标签唯一标识 -
采样点（Samples）
每个指标收集到的采样数据有两部分组成：Timestamp、Value -
指标表达方式
- OpenTSDB的标识方式：
<metric name>{<label name> = <label value>, ...} - 示例：
api_http_request_total{method="POST", handler="/messages"}
- OpenTSDB的标识方式：
六、Prometheus 中的指标类型
七、监控数据的采集
Push or Pull
在 Kubernetes 集群中的监控系统
每个节点 kubelet 会收集当前节点 host 上的所有信息，包括 CPU、内存、磁盘等。
Prometheus 会 pull 这些信息，给每个节点打上标签来区分不同的节点。
七、数据的存储（TSDB）
八、数据的查询和消费 PromQL
九、常见问题
