监控利器Prometheus怎么用

共计 4807 个字符，预计需要花费 13 分钟才能阅读完成。

监控利器 Prometheus 怎么用，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

前言：

Kubernetes 作为当下最炙手可热的容器管理平台，在给应用部署运维带来便捷的同时，也给应用及性能监控带来了新的挑战。下面给大家分享一款十分火热的开源监控工具 Prometheus，让我们一起来看它是如何兼顾传统的应用监控、主机性能监控和

一、Prometheus 简介

什么是 Prometheus？

Prometheus 是一个开源的系统监控及告警工具，最初建设在 SoundCloud。从 2012 Prometheus 推出以来，许多公司都采用它搭建监控及告警系统。同时，项目拥有非常活跃的开发者和用户社区。

它现在是一个独立于任何公司的开源项目，为了强调这一点并明确项目的管理结构，在 2016 年 Prometheus 加入 CNCF 基金会成为继 Kubernetes 之后的第二个托管项目。

Prometheus 有什么特点？

多维的数据模型（基于时间序列的 k / v 键值对）。

灵活的查询及聚合语句（PromQL）。

不依赖分布式存储，节点自治。

基于 HTTP 的 pull 模式采集时间序列数据。

可以使用 pushgateway（prometheus 的可选中间件）实现 push 模式。

可以使用动态服务发现或静态配置采集的目标机器。

支持多种图形及仪表盘。

Prometheus 适用场景。

在选择 Prometheus 作为监控工具前，要明确它的适用范围，以及不适用的场景。

Prometheus 在记录纯数值时间序列方面表现非常好。它既适用于以服务器为中心的监控，也适用于高动态的面向服务架构的监控。

在微服务的监控上，Prometheus 对多维度数据采集及查询的支持也是特殊的优势。

Prometheus 更强调可靠性，即使在故障的情况下也能查看系统的统计信息。权衡利弊，以可能丢失少量数据为代价确保整个系统的可用性。因此，它不适用于对数据准确率要求 100% 的系统，比如实时计费系统（涉及到钱）。

二、Prometheus 构架图

上图是 Prometheus 的架构图，从图中可以看出 Prometheus 的架构设计理念，中心化的数据采集，分析。

1. Prometheus Server：Prometheus 的核心，根据配置完成数据采集，  服务发现以及数据存储。

2. Pushgateway：为应对部分 push 场景提供的插件，监控数据先推送到 pushgateway 上，然后再由 server 端采集 pull。（若 server 采集间隔期间，pushgateway 上的数据没有变化，server 将采集 2 次相同数据，仅时间戳不同）

3. Prometheus targets：探针（exporter）提供采集接口，或应用本身提供的支持 Prometheus 数据模型的采集接口。

4. Service discovery：支持根据配置 file_sd 监控本地配置文件的方式实现服务发现（需配合其他工具修改本地配置文件），同时支持配置监听 Kubernetes 的 API 来动态发现服务。

5. Alertmanager：Prometheus 告警插件，支持发送告警到邮件，Pagerduty，HipChat 等。

三、Prometheus 架构详解

接下来，让我们一起了解 rometheus 架构中各个组件是如何协同工作来完成监控任务。

Prometheus server and targets

利用 Prometheus 官方或第三方提供的探针，基本可以完成对所有常用中间件或第三方工具的监控。

之前讲到 Prometheus 是中心化的数据采集分析，那这里的探针（exporter）是做什么工作呢？

上图中硬件及系统监控探针 node exporter 通过 getMemInfo() 方法获取机器的内存信息，然后将机器总内存数据对应上指标 node_memory_MemTotal。

Jenkins 探针 Jenkins Exporter 通过访问 Jenkins 的 api 获取到 Jenkins 的 job 数量并对应指标 Jenkins_job_count_value。

探针的作用就是通过调用应用或系统接口的方式采集监控数据并对应成指标返回给 prometheus server。（探针不一定要和监控的应用部署在一台机器）

总的来说 Prometheus 数据采集流程就是，在 Prometheus server 中配置探针暴露的端口地址以及采集的间隔时间，Prometheus 按配置的时间间隔通过 http 的方式去访问探针，这时探针通过调用接口的方式获取监控数据并对应指标返回给 Prometheus server 进行存储。（若探针在 Prometheus 配置的采集间隔时间内没有完成采集数据，这部分数据就会丢失）

Prometheus alerting

Prometheus serve 又是如何根据采集到的监控数据配和 alertmanager 完成告警呢？

举一个常见的告警示例，在主机可用内存低于总内存的 20% 时发送告警。我们可以根据 Prometheus server 采集的主机性能指标配置这样一条规则 node_memory_Active/node_memory_MemTotal  0.2，Prometheus server 分析采集到的数据，当满足该条件时，发送告警信息到 alertmanager，alertmanager 根据本地配置处理告警信息并发送到第三方工具由相关的负责人接收。

Prometheus server 在这里主要负责根据告警规则分析数据并发送告警信息到 alertmanager，alertmanager 则是根据配置处理告警信息并发送。

Alertmanager 又有哪些处理告警信息的方式呢？

分组：将监控目标相同的告警进行分组。如发生停电，收到的应该是单一信息，信息中包含所有受影响宕机的机器，而不是针对每台宕机的机器都发送一条告警信息。

抑制：抑制是指当告警发出后，停止发送由此告警引发的其他告警的机制。如机器网络不可达，就不再发送因网络问题造成的其他告警。

沉默：根据定义的规则过滤告警信息，匹配的告警信息不会发送。

Service discovery

Prometheus 支持多种服务发现的方式，这里主要介绍架构图中提到的 file_sd 的方式。之前提到 Prometheus server 的数据采集配置都是通过配置文件，那服务发现该怎么做？总不能每次要添加采集目标还要修改配置文件并重启服务吧。

这里使用 file_sd_configs 指定定义了采集目标的文件。Prometheus server 会动态检测该配置文件的变化来更新采集目标信息。现在只要能更新这个配置文件就能动态的修改采集目标的配置了。

这里采用 consul+consul template 的方式。在新增或减少探针（增减采集目标）时在 consul 更新 k /v，如新增一个探针，添加如下记录 Prometheus/linux/node/10.15.15.132=10.15.15.132:9100，然后配置 consul template 监控 consul 的 Prometheus/linux/node/ 目录下 k / v 的变化，根据 k / v 的值以及提前定义的 discovery.ctmpl 模板动态生成 Prometheus server 的配置文件 discovery.yml。

Web UI

至此，已经完成了数据采集和告警配置，是时候通过页面展示一波成果了。

Grafana 已经对 Prometheus 做了很好的支撑，在 Grafana 中添加 Prometheus 数据源，然后就可以使用 PromQL 查询语句结合 grafana 强大的图形化能力来配置我们的性能监控页面了。

联邦模式

中心化的数据采集存储，分析，而且还不支持集群模式。带来的性能问题显而易见。Prometheus 给出了一种联邦的部署方式，就是 Prometheus server 可以从其他的 Prometheus server 采集数据。

可能有人会问，这样最后的数据不是还是要全部汇集到 Prometheus 的 global 节点吗？

并不是这样的，我们可以在 shard 节点就完成分析处理，然后 global 节点直接采集分析处理过的数据进行展示。

比如在 shard 节点定义指标可用内存占比 job:memory_available:proportion 的结果为 (node_memory_MemFree + node_memory_Buffers + node_memory_Cached)/node_memory_MemTotal，这样在 shard 节点就可以完成聚合操作，然后 global 节点直接采集处理过的数据就可以了，而不用采集零散的如 node_memory_MemFree 这类指标。

四、Prometheus 监控 Kubernetes

Kubernetes 官方之前推荐了一种性能监控的解决方案，heapster+influxdb，heapster 根据定义的间隔时间从 Advisor 中获取的关于 pod 及 container 的性能数据并存储到时间序列数据库 influxdb。

也可以使用 grafana 配置 influxdb 的数据源并配置 dashboard 来做展现。而且 Kubernetes 中 pod 的自动伸缩的功能（Horizontal Pod Autoscaling）也是基于 heapster，默认支持根据 cpu 的指标做动态伸缩，也可以自定义扩展使用其他指标。

但是 Heapster 无法做 Kubernetes 下应用的监控。现在，Heapster 作为 Kubernetes 下的开源监控解决方案已经被其弃用（https://github.com/kubernetes/heapster），Prometheus 成为 Kubernetes 官方推荐的监控解决方案。

Prometheus 同样通过 Kubernetes 的 cAdvisor 接口（/api/v1/nodes/${1}/proxy/metrics/cadvisor）获取 pod 和 container 的性能监控数据，同时可以使用 Kubernetes 的 Kube-state-metrics 插件来获取集群上 Pod, DaemonSet, Deployment, Job, CronJob 等各种资源对象的状态，这反应了使用这些资源的应用的状态。

同时通过 Kubernetes api 获取 node，service，pod，endpoints，ingress 等服务的信息，然后通过匹配注解中的值来获取采集目标。

上面提到了 Prometheus 可以通过 Kubernetes 的 api 接口实现服务发现，并将匹配定义了 annotation 参数的 pod，service 等配置成采集目标。那现在要解决的问题就是探针到应用部署配置问题了。

这里我们使用了 Kubernetes 的 pod 部署的 sidecar 模式，单个应用 pod 部署 2 个容器，利用单个 pod 中仅共享网络的 namespace 的隔离特性，探针与应用一同运行，并可以使用 localhost 直接访问应用的端口，而在 pod 的注解中仅暴露探针的端口（prometheus.io/port:“9104”）即可。

Prometheus server 根据配置匹配定义注解 prometheus.io/scrape:“true”的 pod，并将 pod ip 和注解中定义的端口（prometheus.io/port:“9104”）和路径（prometheus.io/path:“/metrics”）拼接成采集目标 http://10.244.3.123:9104/metrics。通过这种方式就可以完成动态添加需要采集的应用。

关于监控利器 Prometheus 怎么用问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。