无盲点或运营负担的Kubernetes监控扩展

作者：Daniella Pontes / 产品，用例，开发者
2019年11月21日

本文由Daniella Pontes和Chris Goller撰写。

在构建和迁移应用程序到云原生环境时，Kubernetes在DevOps世界占据了中心舞台。实际上，Kubernetes是实现目标的手段——用于扩展容器化微服务架构的运营。管理运行在容器上的碎片化应用程序的各个微服务的部署、扩展、升级和更新不是一项简单任务，当然已经超出了手动过程。因此，自动化是唯一可行的途径。Kubernetes承担了编排容器化工作负载的角色。

InfluxDB Cloud 2.0 Kubernetes监控

在InfluxData，我们在构建InfluxDB Cloud 2.0时采用了微服务和Kubernetes。但我们也知道，使自动化可靠的是监控。因此，在SRE（为了满足保持资源和微服务健康的需求）暴露的指标和开发者暴露的指标（由于他们倾向于对代码进行仪器化，以提供尽可能多的信息以供潜在的故障诊断）之间，我们Kubernetes环境中暴露的端点数量是不断增长的。由于Kubernetes原子结构Pod的短暂性，指标端点的确切数量和功能端点本身都处于不断变化的状态。所以第一个问题是：通过这些暴露的端点在Kubernetes中抓取指标的可扩展性如何？答案是：这取决于抓取的实现。

从我们处理来自大型云部署中多个团队生成的指标的自身经验中，我们知道存在一个“标签过多”的转折点，结果你会得到一个盲点，丢失指标。抓取器无法处理在轮询间隔内暴露的越来越多指标的提取。增加轮询间隔意味着减少获取指标频率，这降低了故障排除关键信息的可用性。所以延长轮询间隔并不是真正的解决方案。（有关我们掌握Kubernetes监控的旅程的更多详细信息，请参阅Chris Goller在2019年10月旧金山InfluxDays的会议。）

然后我们意识到，我们必须超越集中式抓取，它已被证明在大型环境中不可扩展——甚至在使用联邦实现的情况下。因为它要求操作保持联邦服务器之间最优的指标分布，这给Ops带来了更多的监控和平衡活动。换句话说，它不容易实施和维护。

作为原则，一个好的爬取策略不应该增加操作负担，也不应该为需要它的人设置障碍。如果你的系统越大，监控就越复杂，那么从根本上讲，你没有一个可扩展的解决方案。

这个看似的DevOps困境的答案是相当简单的，它位于Kubernetes容器化结构的中心：你只需要隔离（隔离）每个暴露的指标的 影响。爬取器应该包含在将要爬取的服务或工作负载的Pod中。实现这种方法的机制称为边车部署。

在InfluxDB Cloud 2.0中，我们有一个Telegraf，它是一个轻量级的、基于插件的指标收集代理，作为每个Pod中的边车部署，因此所有由应用程序、服务或微服务暴露的指标都由该代理处理，不会影响其他工作负载的爬取。

每个Telegraf代理将它的指标发送到云中的InfluxDB或本地，不会给IT运营带来任何负担，也不会对开发者或数据工程师对指标的需求产生逆推。

监视监视者

边车部署解决了爬取扩展的问题，但我们的Kubernetes环境监控之旅并没有就此停止。还有一个问题需要回答——我们需要保证没有盲点，没有缺失的指标。因此，我们需要能够监视监视者。

答案是Telegraf。它实际上非常适合作为监控代理，因为它从不假设任何事情。Telegraf监控它完成工作的好坏。它有一个针对其内部指标的输入插件，收集诸如

• gather_errors
• metrics_dropped
• metrics_gathered
• metrics_written

下面的截图是从监控测量中检测到缺失指标。下一步就是深入Telegraf的自我监控，找出哪些指标丢失了，以及收集错误。

其他好理由

添加自控能力也是监控解决方案提供的一个重要功能。监控指标总是在基数和索引之间取得平衡。为了描述和可视化分组添加更多的标签，就会创建更多的系列。这会带来成本，因为拥有更多的系列将对其资源造成影响。Telegraf有一个非常有用的功能，通过在代理中设置一些护栏，来确保表现良好的“指标”公民保持良好行为。

在Telegraf中，这可以很容易地配置为限制作为首选的标签数量。更改测量描述在尝试在中心Prometheus服务器中做出这种更改的情况下不会那么简单。例如，更改中心Prometheus服务器需要重新启动，影响所有被监控的微服务器的指标收集。另一方面，使用Telegraf边车部署，单个Pod的单个服务和Telegraf的重新启动，不会对其他人造成任何中断。

配置Telegraf可以在运行时完成——无需重新编译——并且完全在开发者的控制之下，减轻了运营的额外负担。

[[processors.tag_limit]]

  limit = 3

  ## List of tags to preferentially preserve

  keep = ["handler", "method", "status"]

Telegraf拥有200多个开源插件，支持全栈监控（基础设施、网络和应用程序），支持拉取、推送和指标流，并提供C#、Go、Java、JavaScript/Node.js、Python等客户端库以实现直接仪表化。Telegraf还监控kubelet API，用于监控/summary端点暴露的指标，以及Kubernetes Inventory监控系统资源状态，包括

• daemonsets
• deployments
• nodes
• persistentvolumes
• persistentvolumeclaims
• pods（容器）
• Statefulsets

关键经验教训

监控扩展并非增加更多手动流程和控制。扩展不能与更高的复杂性结合，当然，必须赋予开发者权力——通过可观察性、可预测性和指导性手段——以确保监控能够完成其任务。

当然，Kubernetes在不断发展，我们也在不断进步。如果您有任何想法，我们非常愿意听取您的意见！