Prometheus 到底 NB 在哪里？- 天天5分钟玩转 Docker 容器技术（84）

本节讨论 Prometheus 的核心，多维数据模型。咱们先来看一个例子。

好比要监控容器 webapp1 的内存使用状况，最传统和典型的方法是定义一个指标 container_memory_usage_bytes_webapp1 来记录 webapp1 的内存使用数据。假如每1分钟取一次样，那么在数据库里就会有相似下面的记录。

好，如今需求发生了点变化，咱们须要知道全部 webapp 容器的内存使用状况。若是仍是采用前面的方法，就不得不增长新的指标 container_memory_usage_bytes_webapp2、container_memory_usage_bytes_webapp3…

像 Graphite 这类更高级的监控方案采用了更为优雅的层次化数据模型。为了知足上面的需求，Graphite 会定义指标 container.memory_usage_bytes.webapp1、container.memory_usage_bytes.webapp2、container.memory_usage_bytes.webapp3…

而后就能够用 container.memory_usage_bytes.webapp* 获取全部的 webapp 的内存使用数据。

此外，Graphite 还支持 sum() 等函数对指标进行计算和处理，好比 sum(container.memory_usage_bytes.webapp*) 能够获得全部 webapp 容器占用的总内存量。

目前为止问题处理得都很好。但客户老是会提出更多的需求：如今不只要按容器名字统计内存使用量，还要按镜像来统计；或者想对比一下某一组容器在生产环境和测试环境中对内存使用的不一样状况。

固然你能够说：只要定义更多的指标就能知足这些需求。好比 container.memory_usage_bytes.image1.webapp1、container.memory_usage_bytes.webapp1.prod等。

但问题在于咱们没办法提早预知客户要用这些数据回答怎样的问题，因此咱们没办法提早定义好全部的指标。

下面来看看 Prometheus 的解决方案。

Prometheus 只须要定义一个全局的指标 container_memory_usage_bytes，而后经过添加不一样的维度数据来知足不一样的业务需求。

好比对于前面 webapp1 的三条取样数据，转换成 Prometheus 多维数据将变成：

后面三列 container_name、image、env 就是数据的三个维度。想象一下，若是不一样 env（prod、test、dev），不一样 image（mycom/webapp:1.二、mycom/webapp:1.3）的容器，它们的内存使用数据中标注了这三个维度信息，那么将能知足不少业务需求，好比：

1. 计算 webapp2 的平均内存使用状况：avg(container_memory_usage_bytes{container_name=“webapp2”})

2. 计算运行 mycom/webapp:1.3 镜像的全部容器内存使用总量：sum(container_memory_usage_bytes{image=“mycom/webapp:1.3”})

3. 统计不一样运行环境中 webapp 容器内存使用总量：sum(container_memory_usage_bytes{container_name=~“webapp”}) by (env)

这里只列了几个例子，不过已经可以说明 Prometheus 数据模型的优点了：

1. 经过维度对数据进行说明，附加更多的业务信息，进而知足不一样业务的需求。同时维度是能够动态添加的，好比再给数据加上一个 user 维度，就能够按用户来统计容器内存使用量了。

2. Prometheus 丰富的查询语言可以灵活、充分地挖掘数据的价值。前面示例中的 avg、sum、by 只是查询语言中很小的一部分功能，已经为咱们展示了 Prometheus 对多维数据进行分片、聚合的强大能力。

如今咱们已经知道 Prometheus 的强大之处了，再 NB 的东西也得落地，下一节就开始实践。

书籍：
1.《天天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

2.《天天5分钟玩转OpenStack》
https://item.jd.com/12086376.html