Managed Prometheus Service
Prometheus
随着云原生、云计算、微服务的快速发展，Prometheus 这个在监控领域拔得头筹的 CNCF 项目逐渐被大家所熟知。以前，我们使用 nagios、cacti、zabbix 等开源监控软件来解决我们在生产环境中遇到的监控问题。随着容器和微服务的盛行，大家开始逐渐支持 Prometheus 的监控标准。由于一开始他是借鉴了 google 内部的监控系统的理念设计而来，在项目初期可以说是赚足了眼球，由于 Prometheus 的接入极其简单，又伴随这 CNCF 这个基金会的光环，Prometheus 的生态不断壮大。
Push or Pull
监控数据的采集应该是 推 还是 拉, 是值得讨论的一个问题。我们之前所见到的大多数监控系统的监控数据都是采用的推的模式来上报数据。比如著名的 zabbix 和近两年国内开源的 openfalcon 和 lodastack 监控系统，那么 推 的模式有什么优点呢
- 可以比较轻松的应对各种复杂的网络环境
- 不需要有指标类型
- 系统实现相对简单
- 比较容易理解
对于像 Promethues 这样的 拉 的模式有什么好处呢
- 不用关心数据的采集周期
- 非常容易集成到第三方服务中
有人可能会说用 push gateway 也可以让 Promethues 支持 push 的模式，的确是这样的，俗话说的好，没有什么问题是加一层解决不了的，如果有，那就再加一层。
监控指标需不需要有类型
很早在做监控系统的时候，大多数监控系统在最开始的采集阶段是不会定义指标类型的。但是随着各种监控系统的发展，指标类型开始逐渐被大家使用和接受。讨论这个问题的同时我们可能不得不考虑另外一个问题，监控系统需不需要存储原始数据的问题。
普罗米修斯在采集的时候定义指标类型主要是做初步的计算，上报计算好的数据，原始数据量太大，这样能大大减少数据量，且在监控这样的场景下存储原始数据，普罗米修斯认为意义不大，其他需要展示的数据都可以通过目前加工的数据计算得来。
这样带来的问题也很明显，在用户侧（数据上报端）进行数据的计算和短时存储，当数据量比较大或者 labels set 比较多（用户使用不规范）的情况下，会带来很大的性能消耗。
k8s with Promethues
容器的盛行也捎带了 Promethues 一把，这样说一点也不过分。
可以说 k8s 中的各个组件现在都已经支持了 Promethues，拉起一个 Promethues，配置好 k8s 的服务发现，就可以自动采集 k8s 和 跑在 k8s 之上应用的监控数据了。程序内部的关键监控指标往往只有开发者最清楚，Promethues 提供了一种极其简单的暴露这些指标的方法。支不支持 Promethues 的监控数据采集，也许已经成为一个开源软件是否优秀的衡量标准之一。
Managed Prometheus
k8s 的死忠越来越多，Prometheus 的用户也越来越多。
但是在大量实例、海量指标的监控场景下，Prometheus 仍然存在一些性能问题。最初的 Prometheus 是单机版，而且底层的数据存储写的有点粗糙，经过不断迭代，v2 的 tsdb 有了大的性能提升，社区也开源了一些集群方案， 比如最火的 thanos，thanos 确实解决了 Prometheus 的扩展性问题，但是其架构相对复杂一些，各种组件之间的调用和查询让使用者有点难以理解，让用户自己去部署一套类似于 thanos 这样的服务，大大提高了使用门槛和维护难度，其实用户只想部署一个高性能的 Prometheus 而已。
基于 thanos，我们做了一些改进，抛弃了原有架构的一些组件，简化整个架构，减少了服务之前的互相查询，同时保持了 Prometheus 的可扩展性。对于用户来说，他们就像在使用单机版的 Prometheus 一样简单。目前这个服务的开发已经接近尾声。
