目录
可观察性，对于在Kubernetes集群中运行大量的工作负载至关重要。Prometheus是一个监视系统和时间序列数据库，已经被广泛证明其擅长于管理大规模，动态的Kubernetes环境。实际上，Prometheus被认为是在Kubernetes上运行应用程序的基础构建块，并已成为在Kubernetes环境中进行可见性和监视的事实上标准。
尽管Prometheus是开源的，但它并不免费提供监视Kubernetes工作负载所需的配置。
注意：在本文中，我不会讨论Prometheus和多集群高可用性设置所面临的挑战。相反，我专注于如何将Prometheus扩展到更多的应用程序并为每个应用程序创建仪表板，以便更多的人可以使用它。如果你对高可用性设置感兴趣，可以参考诸如Thanos或VictoriaMetrics之类的项目。
要开始使用Prometheus，你可以配置 scraping 以从服务中提取指标，使用Grafana构建仪表板，并为生产环境中超出阈值的重要指标定义警报（请参见下图）。
一旦你选择了Prometheus，第一个挑战就是为整个应用程序和环境扩展和管理Prometheus。
挑战1：手动配置应用程序
现代软件的工作负载通常由成百上千个微服务组成，它们既是同一应用程序的多个实例，又是彼此通信的不同的较小应用程序，它们都是由Kubernetes精心组织的。这些工作负载不是在单个集群或单个环境中运行，而是分布在多个集群和环境（例如开发，测试和生产）中。
例如，截至2019年底，Uber的工作量已增长到4,000多个微服务。要管理和操作此类复杂的应用程序，你需要高级可观察性，这需要针对每个应用程序进行抓取，仪表板和警报的专用配置。你不仅要必须创建这些配置，而且还必须将它们应用到每种环境。而且，每次发生更改时常常以手动方式完成。
问题：这全都意味着，要管理Prometheus和Grafana生态系统中的配置，需要付出的巨大人工。
解决方案：利用GitOps保持控制
你可以采用“ GitOps”方法，而不是临时应用配置，其中Git存储库保存所有配置以及文档和代码，并且operator 组件自动将其应用于要管理的系统-例如Prometheus，Grafana ，甚至Kubernetes集群。
不直接对Prometheus配置或Grafana仪表盘进行任何更改，而是必须将所有更改首先提交给Git存储库，然后将其同步到Prometheus，Grafana或其他工具。
GitOps方法的众多好处之一就是能够对所有配置进行版本控制，以识别何时以及为何发生每项更改。对于有问题的更改，你可以轻松地将其回滚。使用这种方法，你还可以使用 pull requests 的概念来提升配置。
下图显示了一个Git存储库和operator 来管理所有配置文件。operator 必须拥有将配置底层系统的逻辑和权限。
手动应用的配置与GitOps方法的对比
挑战2：手动创建配置文件和仪表盘
第一步，设置受版本控制，并保存所有配置到GitOps是第一步。但是仍然有很多手动配置需要处理。
学习Prometheus中的PromQL查询不是一件容易的事。除了PromQL，你还需要Grafana仪表板配置（以JSON格式编写）以全面了解你的应用程序。你还需要Prometheus中的警报规则（用Yaml格式编写）来设置故障警报。
问题：你需要一支由不同配置语言组成的工程师团队，来编写和维护所有手动配置。
解决方案：代码生成器
代码生成器可以解救！你可以使用代码生成器来减轻手动工作，而不必手动为Prometheus、警报管理器，以及为Grafana仪表板编写配置。
一个很好的例子是根据SRE概念生成的Prometheus警报和记录规则，例如 Golden Signals 或RED方法，甚至USE方法，它们被广泛认为是最有用和最关键的指标。另一个示例是生成Grafana仪表板（例如，请参见GitHub网站上的uber / grafana-dash-gen，metalmatze / slo-libsonnet和prometheus-operator / kube-prometheus，以及Grafana Labs网站上的Scripted Dashboards）。
使用代码生成器可以加快配置工作。生成的文件存储在Git存储库中，以获取我之前讨论的所有好处。
下图将手动配置与代码生成的配置进行了比较，并显示了后一种方法如何完成繁重的工作并减少用户出错。
手动编写配置与使用代码生成器
挑战3：配置同步
一旦开始使用代码生成器，最终将获得大量自动生成的配置文件。存储在Git存储库中的那些配置彼此独立。没有控制机制保证它们基于相同的输入文件。实际上，这甚至是不可能的，因为代码生成器可能依赖于不同种类的输入。
例如：更改代码生成器1的输入参数所输出的结果，与代码生成器2或3的输出不同步。这就导致了，生成的文件之间没有同步机制。
只有少数解决方案可以解决此问题，例如prometheus-operator / kube-prometheus。
问题：需要人工操作才能将每种输入进行的更改，创建成为新一代版本的配置文件。
解决方案：使用抽象方法来实现重用，并保持生成的文件同步
软件工程中的抽象方法实现了重用，可以帮助克服配置文件不同步的挑战。引入具备SRE( Site Reliability Engineering ，网站可靠性工程 )概念的中间语言可以帮助提供技术基础。
下图显示了如何引入诸如jsonnet或其他中间语言，使你可以定义通用概念并为Prometheus和Grafana等不同平台生成特定的配置文件。使用这种高级编程语言，你可以抽象实现细节。但你使用的语言必须提供Prometheus监视域中普遍存在的所有概念。
一个成熟的SRE概念是基于服务级别目标（SLO）的概念，该概念允许你为每个微服务定义目标。使用机器和人类可读的代码（如Yaml文件）中，可以为多个工具生成配置，并使所有配置符合定义的服务级别目标。这降低了复杂性，使你可以更轻松地应对Prometheus环境的操作和扩展。
将没有抽象的方法与基于SRE概念的抽象的新方法进行比较
译文链接：https://thenewstack.io/3-key-configuration-challenges-for-kubernetes-monitoring-with-prometheus/
