Kubernetes集群的监控报警策略最佳实践

本文为Kubernetes监控系列的第二篇文章，系列目录如下：

1. Kubernetes监控开源工具基本介绍以及如何使用Sysdig进行监控

2. Kubernetes集群的监控报警策略最佳实践（本篇）

3. Kubernetes中的服务发现与故障排除（敬请期待）

4. Docker与Kubernetes在WayBlazer的使用案例（敬请期待）

本文将介绍关于如何在Kubernetes集群中配置基础设施层的警报。本文是关于在生产中使用Kubernetes系列的一部分。 第一部分介绍了Kubernetes和监控工具的基础知识；这部分涵盖了Kubernetes报警的最佳实践，第三部分将介绍Kubernetes服务发现与故障排除，最后一部分是监控Kubernetes的实际使用案例。

监控是每个优质基础设施的基础，是达到可靠性层次的基础。监控有助于减少对突发事件的响应时间，实现对系统问题的检测、故障排除和调试。在基础设施高度动态的云时代，监控也是容量规划的基础。

有效的警报是监控策略的基石。当你转向容器和Kubernetes编排环境，你的警报策略也需要演进。正是因为以下几个核心原因，其中许多我们在" 如何监视Kubernetes"中进行了讲述：

• 可见性：容器是一个黑盒。传统工具只能针对公共监控端点进行检查。如果想深入监控相关服务，则需要采取不一样的方法。

  
  

• 新的基础架构层：现在服务和主机之间有一个新的层：容器和容器编排服务。这些是你需要监控的新内部服务，你的监控系统需要了解这些服务。

  
  

• 动态重调度：容器没有像之前那样的服务节点，所以传统的监控不能有效地工作。没有获取服务度量标准的静态端点，没有运行服务实例的静态数量（设想一个金丝雀发布或自动伸缩设置）。在某节点中一个进程被kill是正常的，因为它有很大的机会被重新调度到基础设施的其他节点。

  
  

• 元数据和标签：随着服务跨多个容器，为所有这些服务添加系统级别的监控以及服务特定的度量标准，再加上Kubernetes带来的所有新服务，如何让所有这些信息对我们有所帮助？有时你希望看到分布在不同节点容器中的服务的网络请求度量，有时你希望看到特定节点中所有容器的相同度量，而不关心它们属于哪个服务。这就需要一个多维度量系统，需要从不同的角度来看待这些指标。如果通过Kubernetes中存在的不同标签自动标记度量标准，并且监控系统能够了解Kubernetes元数据，那么只需要在每种情况下按照需要聚合和分割度量标准就可以实现多维度度量。

考虑到这些问题，让我们创建一组对Kubernetes环境至关重要的报警策略。我们的Kubernetes报警策略教程将涵盖：

• 应用程序层度量标准的报警

• Kubernetes上运行的服务的报警

• Kubernetes基础设施的报警

• 在主机/节点层上的报警

最后我们还将通过检测系统调用问题来了解如何通过报警加速故障排除。

应用程序层度量标准的报警

工作指标（working metrics）可以确认应用程序是否按预期执行，这些度量标准通常来自用户或消费者对服务的期望操作，或者是由应用程序通过statsd或JMX在内部生成。如果监控系统本身提供网络数据，就可以使用它来创建基于响应时间的报警策略。

以下示例是一个公共REST API端点监控警报，监控prod命令空间中的名为javaapp的deployment，在10分钟内如果延迟超过1秒则报警。