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 的会议。）

然后我们意识到，我们必须超越集中式抓取进行思考，事实证明，集中式抓取对于大型环境来说是不可扩展的——即使是联邦式实现也是如此。因为它迫使运维人员跟上联邦服务器之间最佳的指标分布，这又给运维人员增加了另一项监控和平衡的任务。换句话说，它不易于实施和维护。

作为一项原则，良好的抓取策略既不应增加运维负担，也不应成为任何人获取指标的障碍。如果您的系统越大，监控就变得越复杂，那么从根本上来说，您就没有可扩展的解决方案。

这个看似 DevOps 困境的答案实际上非常简单，并且位于 Kubernetes 容器化结构的核心：您只需要包含（隔离）每个暴露指标的影响。抓取器应包含在它要抓取的服务或工作负载的 Pod 内。实现此方法的机制称为 Sidecar 部署。

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

Telegraf sidecar

每个 Telegraf 代理将其指标发送到云端或本地部署的 InfluxDB，而不会给 IT 运维带来任何负担，也不会形成对开发者和数据工程师的指标需求进行抵制的文化。

监视监视器

Sidecar 部署解决了扩展抓取的问题，但我们正确监控 Kubernetes 环境的旅程并未就此止步。仍然需要回答第二个问题——我们需要保证我们没有盲点，没有遗漏指标。因此，我们需要能够监视监视器。

答案再次在 Telegraf 中。它实际上非常适合作为监控代理，因为它不会认为任何事情是理所当然的。Telegraf 监控它自身的工作情况。它有一个输入插件用于其 内部指标，收集诸如以下数据：

  • gather_errors
  • metrics_dropped
  • metrics_gathered
  • metrics_written

下面的屏幕截图来自监控测量，检测到遗漏的指标。下一步是深入研究 Telegraf 自监视，以查找哪些指标被丢弃以及收集错误。

Telegraf monitored measurements

其他充分的理由

为自控添加功能也是监控解决方案提供的一项重要功能。监控指标始终是在基数和索引之间取得平衡。为描述和可视化分组添加的标签越多，创建的序列就越多。这是有代价的，因为拥有更多序列会消耗更多资源。Telegraf 具有一个非常有用的功能，可以通过在代理中设置一些防护措施，使表现良好的“指标”公民继续表现良好。

虽然在 Telegraf 中，可以轻松配置此功能以限制作为首选的标签数量。如果尝试在中央 Prometheus 服务器中进行此更改，则更改测量描述不会那么直接。例如，更改中央 Prometheus 服务器将需要重启，从而影响所有被监控的微服务的指标收集。另一方面，使用 Telegraf Sidecar 部署，重启单个 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 (containers)
  • Statefulsets

主要经验教训

扩展监控不是要添加更多手动流程和控制。扩展不能与更高的复杂性相关联，当然，必须拥抱赋予开发者能力——通过可观测性、可预测性和规范性手段——以确保监控正在完成其工作。

当然，Kubernetes 在不断发展，我们也在不断发展。如果您有任何想法，我们很乐意倾听！