Prometheus的监控数据更新和刷新机制是怎样的

Prometheus的监控数据更新机制主要涉及数据的采集和处理。以下是其主要特点：

1. 数据采集方式

Prometheus通过Pull模式主动从监控目标中收集数据。它定期轮询目标中的`/metrics`端点，从中获取时间序列数据。

支持两种数据采集方式：

主动方式（PULL）：使用Prometheus提供的官方SDK，利用SDK可以自定义并导出自己的业务指标（或者使用Exporter）。主动模式对Server端压力较大。

被动方式（PUSH）：适用于短时间执行的脚本任务或者不好直接Pull指标的服务（进程），Prometheus提供了PushGateWay网关给此类任务将服务指标主动推到网关，Prometheus再从网关里Pull指标。

2. 数据类型

Prometheus支持四种主要的metric类型，每种类型适用于不同的监控场景：

Counter（计数器）：只能递增的计数器，用于记录事件的累计次数，例如HTTP请求总数。计数器的值不会减少，除非系统重启或被明确重置，如`http_requests_total`表示累计的HTTP请求次数。

Gauge（仪表）：可以增减的指标，用于表示瞬时值，例如当前内存使用量或CPU利用率。仪表的值可以上下波动，适合用于监控资源使用情况，如`memory_usage_bytes`表示当前内存使用量。

Histogram（直方图）：用于测量事件的分布情况，例如请求延迟。直方图会将测量值分布在预先定义的桶（buckets）中，并记录每个桶内的事件数量，如`http_request_duration_seconds`表示HTTP请求的响应时间分布。

Summary（摘要）：类似于直方图，用于统计事件的分布情况和总数，同时提供分位数计算。与直方图不同，摘要是在客户端进行分位数计算，因此更加适合低延迟场景，如`rpc_duration_seconds`表示RPC调用的持续时间分布。

3. 数据过滤机制

Prometheus提供了keep或drop机制，如果设置了keep机制，则会保留所有匹配标签的数据；如果设置了drop机制，则会丢弃匹配标签的数据，从而完成数据过滤。

监控数据刷新机制

Prometheus的监控数据刷新机制主要涉及数据的存储和查询。以下是其主要特点：

1. 数据存储方式

Prometheus将最近的数据保存在内存中，这样查询最近的数据会变得非常快，然后通过一个compactor定时将数据打包到磁盘。数据在内存中最少保留2个小时（`storage.tsdb.min

block – duration`）。为了防止程序崩溃导致数据丢失，实现了WAL（write – ahead – log）机制，启动时会以写入日志（WAL）的方式来实现重播，从而恢复数据。

在Prometheus内部，chunk是用来存储压缩后的样本sample数据的最小单位。chunk的大小1KB，每个chunk可以存储最多120个样本，当chunk存满120个样本或超过了chunkRange的时间范围（默认情况为2h），就会写到新的chunk里。

Prometheus以每2个小时为一个时间窗口，即将2小时内产生的数据存储在一个block中，监控数据会以时间段的形式被拆分成不同的block。block会压缩、合并成历史数据块、随着压缩合并会减少block的个数。每个block都拥有全局唯一的UUID，每个block都有自己单独的目录，里面包含该时间窗口内所有的chunk、Index、tombstones、meta.json等内容。

2. 数据查询

Prometheus支持PromQL查询语言，可以完成非常复杂的查询和分析，对图表展示和告警非常有意义。可以在Prometheus的WebUI上通过PromQL，可视化查询指标，也可以很方便地接入第三方的可视化工具Grafana进行查询。

3. 数据刷新周期相关配置

例如在OceanBase的文档中提到`prometheus_sync_interval`，这是Prometheus监控数据的刷新周期，默认为1分钟。