Prometheus — 架构
文章目录
-
- Prometheus架构
- Pushgateway
- 服务发现
- 存储
- Alertmanager
Prometheus架构
从这个架构图，可以看出 Prometheus 的主要模块包含， Server, Exporters, Pushgateway, PromQL, Alertmanager, WebUI 等。
它大致使用逻辑是这样：
- Prometheus server 定期从静态配置的 targets 或者服务发现的 targets 拉取数据。
- 当新拉取的数据大于配置内存缓存区的时候，Prometheus 会将数据持久化到磁盘（如果使用 remote storage 将持久化到云端）。
- Prometheus 可以配置 rules，然后定时查询数据，当条件触发的时候，会将 alert 推送到配置的 Alertmanager。
Alertmanager 收到警告的时候，可以根据配置，聚合，去重，降噪，最后发送警告。 - 可以使用 API， Prometheus Console 或者 Grafana 查询和聚合数据。
Pushgateway
和采用Push方式采集监控数据不同，Prometheus采用 Pull方式采集监控数据。
这两种监控数据采集方式各有优缺点：采用Push方式时，Agent主动上报数据，采用 Pull方式时，监控中心（Master）拉取 Agent的数据。其主要区别在于 Agent和Master的主动、被动关系。
为了兼容 Push方式，Prometheus 提供了 Pushgateway组件。Pushgateway组件接收客户端发送过来的数据，按照 Job 和 Instance 两个层级进行组织，支持数据的追加和删除，并且为防止数据丢失，还支持本地存储。
Push方式和Pull方式对比和说明：
1.实时性：Push方式的实时性相对较好，可以将采集数据立即上报到监控中心。Pull 方式通常进行周期性采集，采集时间为30s 或者更长时间。所以，如果对监控系统的实时性要求非常高，则建议采用Push方式。
2.状态保存：Push 方式通常在采集完成后立即上报，本地不会保存采集数据，Agent 本身是没有状态的，而Master需要维护各种Agent状态。Pull 方式正好相反，Agent 本身需要有一定的数据存储能力，Master 只负责简单的数据拉取，而且Master本身可以做到无状态。
3.控制能力：采用Push方式时，控制方为Agent,Agent上报的数据决定了上报的周期和内容。采用Pull方式时，Master更加主动，控制采集的内容和频率。
4.配置的复杂性：采用Push方式时，通常每个 Agent都需要配置Master的地址。采用Pull方式时，通常通过批量配置或者自动发现来获取所有采集点，相对简单，并且可以做到和 Agent充分解耦，Agent可以不用感知Master的存在。
服务发现
服务发现的方式有两种：静态文件配置和动态发现。
静态文件配置：静态文件配置是一种传统的服务发现方式，一般适用于有固定的监控环境、IP地址和统一的服务接口的场景，需要在配置中指定采集的目标。
动态发现：目前支持以下系统获取监控对象：
- 容器管理系统
- 各种云平台
- 服务发限组件
以kubernetes集成为例讲解监控对象自动发现的流程。
1、需要在 Prometheus 里配置 Kubernetes API 的地址和认证凭据，这样Prometheus就可以连接到Kubernetes的API来获取信息。
2、Prometheus 的服务发现组件会一直监听Kubernetes 集群的变化，当有新主机或加入集群的时候，会获取新主机的主机名和主机IP，如果是新创建的容器，则可以获取新创建 Pod的名称、命名空间和标签等。相应地，如果删除机器或者容器，则相关事件也会被Prometheus感知，从而更新采集对象列表。
存储
prometheus支持本地存储和远程存储。
本地存储：本地存储使用的是TSDB。其优点如下：
- 一段时间一个文件，可以有效避免时序流失的问题，还可以任意组织多个块的数据到一个文件中；
- 每个文件块最大支持512MB，可避免SSD写放大；
- 在删除数据的时候更简单，直接删除分区即可；
- 在查询历史数据时，由于已经按照时间排序，所以可以将内存数据和此磁盘数据合并，通过懒加载的方式载入数据，而不需要将所有磁盘数据加载内存，避免发生OOM。
远程存储：为了提高对大量历史数据持久化存储的能力，Prometheus 在1.6版本后支持远程存储，Adapter需要实现Prometheus的read接口和write接口，并且将read和write转化为每种数据库各自的协议。在用户查询数据时，Prometheus会通过配置的查询接口发送 HTTP请求，查询开始时间、结束时间及指标属性等，Adapter会返回相应的时序数据；相应地，在用户写入数据时，HTTP请求Adapter的消息体会包含时序数组（样本数据）。
Alertmanager
Prometheus 本身对不会对告警进行处理，需要借助另一个组件 AlertManager。
Prometheus会配置AlertManager的地址，这样Prometheus发出的告警记录便可以被发送到AlertManager进行处理。
AlertManager 和 Prometheus同样是由 Go 语言开发的，主要功能包括：告警分组、告警抑制和告警静默。
-
告警分组指将多条告警合并到一起发送。
-
告警抑制指当告警已经发出时，停止发送由此告警触发的其他错误告警。
-
告警静默指在一个时间段内不发出重复的告警。
AlertManager主要分为两个部分：路由（router）和接收器（receiver）。
告警消息先经过路由树，然后被分配到对应的接收器中。路由树是由预先设定的路由规则生成的。