越来越多的组织开始使用Prometheus监视其容器和微服务领域，但慢慢地都会遇到扩展挑战。
容器使监视复杂化
过去，有限的静态物理服务器和虚拟机，以及数量有限的指标使得监控很简单直接。今天，由于容器的使用以及组织向微服务架构的迁移，要跟踪的实体数量激增，使得监控越来越复杂。
现在，云环境中有很多容器，有时每台机器上有数百个容器，同时当与Kubernetes一起使用时，它们的寿命可能非常短。这使得跟踪它们变得更加困难。
随着环境的复杂性和分布的增加，你需要监视的实体数量也在增加。
此外，我们希望监视更多属性，能够对正在发生的事情有准确的了解，以便于进行故障排除。但这在短暂的环境（如：容器）中尤其困难，因为当你想了解问题的根本原因时，通常有问题的资源已经停用，这意味着监视解决方案必须提供一种方法：存储足够的历史记录以进行取证。
Prometheus
当需要进行云监视时，团队越来越多地转向Prometheus。Prometheus已成为开发人员用来在云原生环境中收集和处理指标的首选监视工具。它由一个大型社区支持，有来自700多家公司的6,300个贡献者，13,500个代码提交和7,200个拉取请求。
默认情况下，典型的云原生应用程序（例如Kubernetes，Ngnix，MongoDB，Kafka和golang）会公开Prometheus指标。
Prometheus扩展问题
随着环境的扩大和复杂化，跟踪飞速增长的时间序列数据，单个Prometheus实例将无法跟上。
最直接的选择是在整个企业中运行大量的Prometheus服务器，但这带来了一些挑战。例如，管理和收集整合数据，单点登录，基于角色的访问控制以及遵守SLA等。
为了解决这个问题，公司采用了一些方法。
一个简单的方法就是：为每个名称空间或每个集群部署一个单独的Prometheus服务器。显然，此方法具有创建大量数据孤岛的缺点。这使故障排除变得麻烦，因为大多数问题将涉及多个服务/团队/集群。在每个环境中不仅很难找到相同的指标，而且还必须将数据拼接在一起以试图了解故障发生的事情。
另一种常见的方法是使用诸如Cortex或Thanos之类的开源工具来联合多个Prometheus服务器。它们是功能强大的工具，使你可以集中查询服务器，收集数据，然后在单个仪表板中共享它们。但是，作为任何数据密集型分布式系统，它们都需要大量的资源来进行操作。
Prometheus扩展要考虑的6件事
对于那些以使用Prometheus开始，然后寻求扩展解决方案以提供整体支持的公司，最重要的是—不要丢失Prometheus上标准化上的所有工作-仪表板，警报， exporters 等。除此之外，还有其他扩展也需要你考虑：
Prometheus扩展要考虑的6件事：
如果你发现有符合这些条件的开源或商业工具，则应该能够以最小的代价将其集成到现有的Prometheus环境中，并解决公司遇到的可扩展性问题。
译文链接： https://thenewstack.io/6-things-to-consider-in-a-prometheus-monitoring-platform/
