Prometheus监控Kubernetes的3个配置挑战

可观察性,对于在Kubernetes集群中运行大量的工作负载至关重要。Prometheus是一个监视系统和时间序列数据库,已经被广泛证明其擅长于管理大规模,动态的Kubernetes环境。实际上,Prometheus被认为是在Kubernetes上运行应用程序的基础构建块,并已成为在Kubernetes环境中进行可见性和监视的事实上标准。

尽管Prometheus是开源的,但它并不免费提供监视Kubernetes工作负载所需的配置。

注意:

在本文中,我不会讨论Prometheus和多集群高可用性设置所面临的挑战。

相反,我专注于如何将Prometheus扩展到更多的应用程序并为每个应用程序创建仪表板,以便更多的人可以使用它。

如果你对高可用性设置感兴趣,可以参考诸如ThanosVictoriaMetrics之类的项目。

要开始使用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 SignalsRED方法,甚至USE方法,它们被广泛认为是最有用和最关键的指标。另一个示例是生成Grafana仪表板(例如,请参见GitHub网站上的uber / grafana-dash-genmetalmatze / slo-libsonnetprometheus-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/

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录