容器监控实践-Prometheus基础架构（prometheus监控服务）

概要：根据配置文件，处理接收到的告警，并发出告警。 默认情况下，用户可以部署多个集合并通过简单地收集相同的集合来实现基本功能。 通过将监控与数据分离，可以更好地实现弹性扩展。 参考文档 本文是关于容器监控实践的系列文章。 完整信息请参见：

系统架构图

以下是Prometheus 1.x版本的架构图。

当前Prometheus版本为2.7，架构图如下。

Prometheus 从导出器拉取数据或通过网关间接拉取数据（如果部署在 k8s 上，可以使用服务发现），默认情况下它会将所有捕获的数据存储在本地，并进行清理和处理。按照一定的规则组织数据，并将结果存储在新的时间序列中。 收集的数据有两个目的地。 ，一是令人震惊，二是可视化。 PromQL 和其他 API 直观地显示收集到的数据，并通过 Alertmanager 提供警报功能。

组件内容

Prometheus Server
从导出器获取并存储监控数据，并提供灵活的查询语言（PromQL）

获取：采样module

TSDB：存储模块默认的本地存储是tsdb。

HTTP服务器：提供http接口查询和面板。 默认端口为9090

Exporter/Job

收集目标对象（主机、容器等）的性能数据，并通过HTTP接口play提供给Prometheus Server一个角色。 支持数据库、硬件、消息中间件、存储系统、http服务器、JMX等，只要符合接口格式就可以采集。

短期-作业

临时任务场景无法使用pull方法拉取。 它采用push方式，必须与PushGateway配合使用。

PushGateway

可选组件。 主要用于短期工作。 此类工作仅存在很短一段时间，并且可能在普罗米修斯拉动它们之前就消失了。 为了实现这一目标，作业现在可以将指标直接推送到 Prometheus 服务器。 该方法主要用于服务级别指标。 对于机器级指标，您必须使用节点导出器。

客户端SDK

官方提供的客户端类库包括go、java、scala、python、ruby等多种第三方开发的类库，包括对nodejs、php、 Erlang 等等。

PromDash

使用 Rails 开发的仪表板，用于可视化指标数据，但已被放弃。

Alertmanager

当端收到Prometheus服务器发出的警报时，它会删除重复数据，并将其分组，并将其路由到接收方的接受方法以发出警报。 常见的接收方式包括电子邮件、pagerduty、OpsGenie 和 webhooks。

服务发现

服务发现，Prometheus支持多种服务发现机制：File、DNS、Consul、Kubernetes、OpenStack、EC2等。 基于服务发现的过程并不复杂。 Prometheus通过第三方提供的接口查询自己需要监控的目标列表，并轮换这些目标来检索监控数据。

一般工作流程如下。

Prometheus 服务器定期从配置的作业或导出器检索指标，或者接收从 Pushgateway 或其他 Prometheus 服务器上的中拉指标发送的指标。

专业版Metheus 服务器将收集到的指标存储在本地、执行定义的alert.rules、记录新的时间序列或将警报推送到Alertmanager。

Alertmanager 处理收到的警报并根据配置文件发出警报。

通过图形界面直观地收集数据。

关于 Push 和 Pull

Prometheus 使用 Pull 模型来收集数据。 通过HTTP协议采集指标。 只要您的应用系统能够提供HTTP接口，就可以连接到您的监控系统。 比私有或二进制协议更容易开发。 主要好处是：

开发新功能时，您还可以在计算机上查看监控情况。

如果目标实例挂起，您会立即知道。

您可以手动指定目标实例并在浏览器中查看其健康状况。

一般来说，拉模式比推模式好，而推模式在监控系统中不太重要。 。
如果想使用推送方式，可以使用Pushgateway方式，比如定时任务采集。

对于短周期的指标采集，比如定时任务，如果采用pull模式，可能会导致任务完成，Prometheus可能来不及采集。 此时，添加传输层可以让客户端将数据推送到Push。 网关将其缓存，Prometheus 从推送网关检索该指标。 （您将需要构建一个额外的推送网关并添加一个新作业来从网关收集数据。）

推送最爱包括 ElasticSearch、InfluxDB、OpenTSDB 等。 我需要使用以下方式以编程方式推送指标 TCP、UDP 等 对于相关的监控应用程序，如果监控应用程序挂起或遇到瓶颈，仅使用 TCP 更容易影响应用程序本身。 使用UDP，您不必担心监控应用程序，但您更容易丢失数据。

拉动的主要代表是Pro有了metheus，您不再需要担心监控应用程序本身的状态。 此外，您可以使用 DNS-SRV 和 Consul 等服务发现功能自动添加监控。

当然，你也可以“拉”InfluxDB和收集器，或者ES和metricbeat。 您还可以“推送”Prometheus 和推送网关。

其他差异请参见下图。

存储机制

Prometheus有一种非常高效的时间序列数据存储方式。 仅每个采样数据。 占用约3.5字节空间，数百万个时序，30秒间隔，保留60天。 大约需要200G（引自官方PPT）。

Prometheus内部分为三个主要部分。 采集负责定期捕获已发布目标页面上的采样指标数据。 存储负责将采样数据写入磁盘。 PromQL是Prometheus提供的查询语言模块。

Prometheus 包含一个基于本地存储的时间序列数据库。 Prometheus设计采用本地存储来降低Prometheus部署和管理的复杂度，降低高可用性（HA）带来的复杂度。 默认情况下，用户可以部署多个Prometheus集，只需收集相同的目标即可实现基本的HA。 同时，Prometheus高效的数据处理能力本质上可以让单个Prometheus Server满足大多数用户的监控规模需求。

同时，为了适应数据持久化问题，Prometheus提供了remote_write和remote_read功能，支持向远程端保存数据和从远程端读取数据。 通过将监控与数据分离，Prometheus 更具可扩展性。

关于存储使用规划：https://www.jianshu.com/p/934...
了解更多：Prometheus存储存储机制详解

https://yunlzheng.gitbook.io/...

https://www.cnblogs.com/vovli...

https://www.linuxidc.com/Linu...

https://segmentfault.com/a/11...

https://www .infoq .cn/article/...

关于日志处理

不建议将日志监控合并到Prometheus中。 这不是他的专长。 我们推荐使用ELK或EFK进行日志处理。 资讯

竞品对比

参考：https://toutiao.io/posts/fsjq...

未来计划

服务器端指标元数据支持
指标类型和其他元数据仅由客户端库和显示格式使用，并且不会由 Prometheus 服务持久保存或消耗。 将来，我们希望利用这些元数据。 第一步是将这些数据聚合到 Prometheus 服务的内存中，并打开一些实验性 API 来为该服务提供服务。

对 OpenMetrics 的支持

OpenMetrics Group 开放了新的监控指标发布标准来支持该标准：https://openmetrics.io/

回顾随着时间的推移

允许将过去一段时间的数据发送到其他监控系统

HTTP服务支持TLS安全认证

当前的Prometheus、Alertmanager和一些官方的exporter暴露服务时不支持TLS认证，存在重大安全风险。 当前的实现基于反向代理，稍后将其合并到组件中。

对子查询的支持

当前Promq不支持诸如max_over_time() forrate( ))之类的子查询，将来会支持。

支持生态建设

Prometheus 有许多客户端库和导出器来标准化和生态建设。

配合K8S使用

之前的版本中，k8s默认和推荐的监控系统都是自己的一套：Heapster + cAdvisor + Influxdb + Grafana，从1.8开始被Heaspter取代。 度量 - 服务器。 部署仪表板后，您可以看到监控数据（来自 Heapster）。

k8s 专有的 HPA（水平 Pod 自动缩放器）默认从堆中提取数据进行自动缩放。

自1.8版本开始，K8S希望将核心监控指标收集成Metrics API的形式，自定义监控指标由prometheus实现。 Prometheus现已成为官方推荐的k8s监控实现方案。

参考文档：

https://www.ibm.com/developer...

https://prometheus.io/docs/in。 ..

https://www.kancloud.cn/cdh08...

https://yunlzheng.gitbook.io/...

本文是有关容器监控实践的系列文章的一部分。 完整内容请参见container-monitor-book