关于容器监控，数人云之前给大家分享了《解惑|你是否为容器监控操碎了心？》，就有有Prometheus的身影，那么它都有哪些优缺点？近日发布的2.0版本又有哪些改进？本文见分晓~
Prometheus解决了Devs如何监控高动态容器环境的问题，在本文中，Frederick Ryckbosch讲述了使用Prometheus的优点和缺点，以及它到底有多大的伸缩性。
Prometheus是一个基于时间序列的数值数据的监控解决方案，这是一个开源项目，由前Google员工在SoundCloud启动，他们希望监控一个高度动态的容器环境，因为对传统的监控工具不甚满意，所以开发出Prometheus，并在上面进行工作。
在本文中，我们将讨论Prometheus的重要设计决策及其影响，将重点讨论“ Digital Ocean”如何成功地将Prometheus扩展到100万台机器，以及在使用Coscale时如何利用Prometheus。
Prometheus是如何工作的
要使用Prometheus监控服务，服务需要公开一个Prometheus端点，这端点是一个HTTP借口，它公开了度量的列表和当前的值。
Prometheus提供了广泛的服务发现选项，以查找您的服务并从它们开始检索度量数据。Prometheus服务器轮询服务的指标接口并存储数据。
在Prometheus UI中，用户可以在PromQL语言中编写查询以提取度量信息。
例如：
topk(3, sum(rate(container_cpu_time[5m]) by (app, proc)))
将返回最上面的3个CPU消费服务。
告警可以在Alertmanager中配置，再次使用PromQL语言。Grafana 是一个流行的选项，为Prometheus的指标创建仪表盘。
Prometheus的设计决策
这里从Prometheus的度量终点开始，这些端点定义度量标准和值，并通过HTTP公开，它们为手机度量标准提供了一种标准化的方法，Prometheus度量遵循了度量2.0所指定的许多准则：度量标准有名称、描述、维度和值。唯一缺少的是度量单位。
许多服务度暴露了Prometheus端点，这使得收集它们非常容易，对没有本地Prometheus端点的其他服务，则需要转换器。这意味着对于这些服务，必须部署一个额外的Sidecar容器，以公开Prometheus格式的字表。
在这里讨论的第二个设计决定是拉力和推力，Prometheus调查服务的指标，这意味着如果您想要使用Prometheus监控的所有服务都应该公开Prometheus度量端点，Prometheus使用服务发现，它与Kubernetes很好的集成在一起，以找到所有的服务一旦它找到了所有服务，将通过轮询其他Prometheus度量端点收集所有这些服务的指标。
容器
Pull方法的优点是不需要安装代理，而且可以通过多个Prometheus实例来提取指标。
而缺点同样明显：
对于Prometheus的使用者来说，所有的公制端点都必须是可达的，这意味着一个更加复杂的安全网络配置。
在大型部署中，扩展成为一个问题，Prometheus建议采用一种基于推特的方法来收集短期的工作指标。
Prometheus的主要设计目标之一是操作简单性。这样，Prometheus就限制了监控系统的可能失效模式数量，遵循着一原则，Prometheus目前只局限于单个点，因为集群带来了额外的操作复杂性，使用单个节点不那么复杂，但是对可以由Prometheus监控的度量指标适量有着严格的限制。
Prometheus不解决的问题
Prometheus并不打算解决几个方面的问题：
首先是对日志的支持：这两个指标和日志都是为用户的应用程序提供完全可见性的必要部分，但是已经有大量的开源和闭源日志聚合器来管理日志。
Prometheus也不提供持久的长期存储、异常检测、自动水平缩放和用户管理，但从作者的客户基础上，看到在多数企业环境中都需要这些特性。
Prometheus不是一个Dashboarding解决方案，它提供了一个简单的UI来进行PromQL查询，但它依赖于移植物的操作，增加了一些额外的设置复杂度。
Prometheus与Digital Ocean
在2016年的PromCon演讲中，来自Digital Ocean的Matthew Campbell解释了它们如何将Prometheus扩展到100万台的，在演讲当中，他解释了他们是怎样从一个默认的Prometheus装置开始的，以及他们必须改变什么，才能让它变得更大。
他们以每天数据中心的一台Prometheus机开始，遇到了可伸缩性问题，并创建了更大的机器来运行Prometheus。一旦他们将机器按最大尺寸缩放，他们将系统保留时间减少到3天，并决定放弃某些指标。这种方法只能到目前为止，因此他们决定根据节点标签进一步提高他们的Prometheus，这种方法的困难在于，查询变得更加困难，他们最终实现了一个从多个碎片收集数据的Prometheus代理，他们无法用这种方法解决更大的问题是碎片重新分配和过度供应。
当从1万个服务器扩展到100万个虚拟机时，他们决定采取不同的方法，创建了一个“反向节点出口商”，它基本上是安装在节点上的代理，并将数据推到一个中心点，在后端方面，他们也做了重大的改变：保留了Prometheus API，但添加了一个Kafka集群，用于传入的指标和Cassandra的度量存储，他们还介绍了采样，这个项目被称为Vulcan，可用作开源。
Vulcan所采取的方法看起来很像CoScale所采取的方法，还使用代理和可伸缩、高可用的后端。
CoScal在哪里合适？
我们相信有一个标准化的度量格式有很大的价值，这使得从不同类型的服务中心收集指标变得很容易，CoScale提供了一个Prometheus插件，它收集了在Prometheus格式中暴露的指标，这使得您可以轻松地从已启动的服务中获得指标。
但是仍然有很多服务没有暴露出Prometheus端点。为这些服务部署一个转换器非常麻烦，CoScale有广泛的插件，支持多种服务的本地度量机制；录用日志、Api和其他线程的度量计数器。我们还提供了收集自定义指标的不同选项。
CoScale提供了一个可扩展的插件，包括一个代理和和一个可扩展的、高可用的后端作为SaaS和On-Premise，CoScale提供了Metrics，指标，和事件存储（短期和长期），直观的仪表盘，告警和异常检测。
Prometheus 2.0
Prometheus 1.0于2016年7月发布，就在前几天，Prometheus发布了2.0的版本，带来了巨大的性能改进，并变得更容易操作，下面让我们看看这个版本都有哪些方面的改进。
许多公司和组织都采用了Prometheus，这个项目很快就拥有了一大批的活跃粉丝（开发人员）以及技术社区。5月的时候就传出Prometheus 2.0版本的前瞻预测，据说会有一个很大的改进是，有新的存储层，这意味着极大地提高了Kubernetes和其他分布式系统的监控可伸缩性。
Prometheus有一个简单而健壮的操作模式，然而，基础设施领域也在逐步发展，如Kubernetes何Mesos这样的项目迅速地改变了应用部署和管理的方式，受监控的环境变得越来越动态化。
Prometheus存储子系统需要仔细配置预期负载，虽然在Prometheus 1.6中，自动调谐能力让其大为减轻，但用户仍然会遇到一些不可避免的硬限制。
存储
2017年，事情逐步发生改变，最初作为一种新的，更高效的时间序列数据库的实验，在实际的基准测试中得到了验证，在过去的6个月当中，Prometheus的开发团队一直在忙着稳定这个独立的时间序列数据库，并将其重新整合到Prometheus本身，其结果上，几乎所有的维度上都有了改进，从而显著地提高了Prometheus 2.0的性能，查询延迟更为一致，特别是在高串扰的情况下，在不同的实际生产场景中，度量的资源消耗也显著减少：
- 与Prometheus 1.8相比，CPU使用率降低了20%-40%
- 与Prometheus 1.8相比，磁盘空间使用减少到33%-50%
- 没有太多查询负载的磁盘I/O通常小于1%
在未来的几年里，它还可以处理现代计算环境日益增长的动态特性。
Staleness handling
此外，许多以小见大的变化使得Prometheus更加直观，最值得注意的是Staleness处理，它是最古老和最需要路线图的项目之一，随着新的改进，从这些目标中消失的监控目标或系列已经被明确跟踪，这减少了人工查询，增强了告警响应能力。
其他改进
Prometheus 2.0还内置了对整个数据库快照备份的支持。
同时，还将记录和告警规则从一个自定义格式迁移到无处不在的YAML格式，这使得集成配置管理和模块变得更加容易。
其他的变动改进请参看：https://prometheus.io/docs/prometheus/2.0/migration/
未来计划
会将新的存储子系统设计为可访问和可扩展的，这就需要将新特性直接集成到Prometheus中，以及可以在它之上构建的定制工具，简单而开放的存储格式和库也允许用户轻松构建自定义扩展，比如动态保留策略，这使得存储层能够满足广泛的需求，而无需将复杂性引入到Prometheus本身中，让它专注于它的核心目标。
