Prometheus

Prometheus

简介

我们知道监控是保证系统运行必不可少的功能，特别是对于 Kubernetes 这种比较庞大的系统来说，监控报警更是不可或缺，我们需要时刻了解系统的各种运行指标，也需要时刻了解我们的 Pod 的各种指标，更需要在出现问题的时候有报警信息通知到我们。

在早期的版本中 Kubernetes 提供了 heapster、influxDB、grafana 的组合来监控系统，在现在的版本中已经移除掉了 heapster。现在更加流行的监控工具是 Prometheus，Prometheus 是 Google 内部监控报警系统的开源版本，是 Google SRE 思想在其内部不断完善的产物，它的存在是为了更快和高效的发现问题，快速的接入速度，简单灵活的配置都很好的解决了这一切，而且是已经毕业的 CNCF 项目。

特点

Prometheus 最初是 SoundCloud 构建的开源系统监控和报警工具，是一个独立的开源项目，于2016年加入了 CNCF 基金会，作为继 Kubernetes 之后的第二个托管项目。Prometheus 相比于其他传统监控工具主要有以下几个特点：

• 具有由 metric 名称和键/值对标识的时间序列数据的多维数据模型
• 有一个灵活的查询语言
• 不依赖分布式存储，只和本地磁盘有关
• 通过 HTTP 的服务拉取时间序列数据
• 也支持推送的方式来添加时间序列数据
• 还支持通过服务发现或静态配置发现目标
• 多种图形和仪表板支持

架构

Prometheus 由多个组件组成，但是其中有些组件是可选的：

• Prometheus Server：用于抓取指标、存储时间序列数据
• exporter：暴露指标让任务来抓
• pushgateway：push 的方式将指标数据推送到该网关
• alertmanager：处理报警的报警组件 adhoc：用于数据查询

大多数 Prometheus 组件都是用 Go 编写的，因此很容易构建和部署为静态的二进制文件。下图是 Prometheus 官方提供的架构及其一些相关的生态系统组件：

整体流程比较简单，Prometheus 直接接收或者通过中间的 Pushgateway 网关被动获取指标数据，在本地存储所有的获取的指标数据，并对这些数据进行一些规则整理，用来生成一些聚合数据或者报警信息，Grafana 或者其他工具用来可视化这些数据。

注意：prometheus的数据可以也可以存储在ceph里，但不能存储在nfs里。测试环境，你可以用nfs，prometheus是可以跑起来的。但生产环境一定不能用nfs，否则重建之后，以前的历史数据可其他能会被损坏！

监控集群节点

前面我们和大家学习了怎样用 Promethues 来监控 Kubernetes 集群中的应用，但是对于 Kubernetes 集群本身的监控也是非常重要的，我们需要时时刻刻了解集群的运行状态。

对于集群的监控一般我们需要考虑以下几个方面：

• Kubernetes 节点的监控：比如节点的 cpu、load、disk、memory 等指标
• 内部系统组件的状态：比如 kube-scheduler、kube-controller-manager、kubedns/coredns 等组件的详细运行状态
• 编排级的 metrics：比如 Deployment 的状态、资源请求、调度和 API 延迟等数据指标

Kubernetes 集群的监控方案目前主要有以下几种方案：

1. Heapster：Heapster 是一个集群范围的监控和数据聚合工具，以 Pod 的形式运行在集群中。 heapster 除了 Kubelet/cAdvisor 之外，我们还可以向 Heapster 添加其他指标源数据，比如 kube-state-metrics。需要注意的是 Heapster 已经被废弃了，后续版本中会使用 metrics-server 代替。
2. cAdvisor：cAdvisor 是 Google 开源的容器资源监控和性能分析工具，它是专门为容器而生，本身也支持 Docker 容器。
3. kube-state-metrics：kube-state-metrics 通过监听 API Server 生成有关资源对象的状态指标，比如 Deployment、Node、Pod。需要注意的是 kube-state-metrics 只是简单提供一个 metrics 数据，并不会存储这些指标数据，所以我们可以使用 Prometheus 来抓取这些数据然后存储。
4. metrics-server：metrics-server 也是一个集群范围内的资源数据聚合工具，是 Heapster 的替代品。同样的，metrics-server 也只是显示数据，并不提供数据存储服务。

不过 kube-state-metrics 和 metrics-server 之间还是有很大不同的，二者的主要区别如下：

• kube-state-metrics 主要关注的是业务相关的一些元数据，比如 Deployment、Pod、副本状态等。
• metrics-server 主要关注的是资源度量 API 的实现，比如 CPU、文件描述符、内存、请求延时等指标。

要监控节点其实我们已经有很多非常成熟的方案了，比如 Nagios、zabbix，甚至我们自己来收集数据也可以。

我们这里通过 Prometheus 来采集节点的监控指标数据，可以通过 node_exporter 来获取。

顾名思义，node_exporter 就是抓取用于采集服务器节点的各种运行指标，目前 node_exporter 支持几乎所有常见的监控点，比如 conntrack，cpu，diskstats，filesystem，loadavg，meminfo，netstat 等，详细的监控点列表可以参考其 Github 仓库。

我们可以通过 DaemonSet 控制器来部署该服务，这样每一个节点都会自动运行一个这样的 Pod，如果我们从集群中删除或者添加节点后，也会进行自动扩展。

prometheus联邦

prometheus本身是比较耗内存的，因为它的一个热数据本身都是在内存当中。

如果你内存占用比较多的话，最好的方式就是，你prometheus本地数据不要保留太多。假如说你要查询1年前的数据，那它肯定要把1年多的数据都要加载到本地进行计算，那肯定资源占用的多啊，内存消耗特别大的。

一般来说，你本地数据不要保留太多，历史的数据存到远端。你需要时，你可以在远程做个计算，然后返回回来，这个方式比较好。

后面可以用这个thanos来解决这个问题。