Kubernetes 集群和应用监控方案的设计与实践（上）

（本文阅读时间：4分钟）

严振范

微软最有价值专家，一个逗B，目前正在学习微服务相关的知识，可以多交流哟~

当你的应用部署到 Kubenetes 后，你很难看到容器内部发生了什么，一旦容器死掉，里面的数据可能就永远无法恢复，甚至无法查看日志以定位问题所在，何况一个应用可能存在很多个实例，用户的一个请求不指定被哪个容器处理了，这使得在 Kubernetes 中对应用进行故障排除较为复杂。在应用之外，由于 Kubernetes 作为基础设施，掌管这整个集群的生死，Kubernetes 的任何故障，必定影响到应用服务的运行，因此监控 Kubernetes 运行状况也至关重要。

当你的应用上了云原生，那你就不得不关注各个服务器的运行状态，基础设施和中间件的运行状态，Kubernetes 中每个组件和资源对象的运行状态，每个应用的运行状态。当然，这个运行状态是一个模糊的概念，取决于我们的关注点，每个被监控的对象要表达的 "运行状态" 是不一样的。为了可以监控我们关注的对象，对象需要做出一些配合，提供合适的运行状态的表达信息，以供我们收集和分析，这可以称为可观测性。

在云原生中，一般对可观测性分为三大作用域：

你可以在 Kubernetes 文档中了解如何监控、调试，以及了解如何对日志进行处理。

在本文中，所提到的监控，只包括 Metrics 。

Metrics、Tracing、Logging 不是完全独立的，在上图中，Metrics 也会可能包含 Logging 和 Tracing 的信息。

要采集的监控数据，来源于被监控对象，而在 Kubernetes 集群中，我们可以将要监控的对象分为三大部分：

在基础环境中，一个完整的监控应包括采集数据、存储数据、分析存储数据、展示数据、告警等多个部分，而每个部分都有相关的工具或技术解决云原生中环境的多样需求和复杂性问题。

既然要做监控，那么就需要监控工具。监控工具可以获取所有重要的指标和日志(Metrics也可以包含一些日志)，并将它们存储在一个安全、集中的位置，以便可以随时访问它们来制定方案解决问题。由于在云原生中，应用在 Kubernetes 集群中部署，因此，监控 Kubernetes 可以让你深入了解集群的运行状况和性能指标、资源计数以及集群内部情况的顶级概览。发生错误时，监控工具会提醒你（告警功能），以便你快速推出修复程序。

Prometheus 是一个 CNCF 项目，可以原生监控 Kubernetes、节点和 Prometheus 本身，目前 Kubernetes 官方文档主要推荐使用 Prometheus 本身，它为 Kubernetes 容器编排平台提供开箱即用的监控能力。因此在本文中，对监控方案的设计是围绕 Prometheus 展开的。

下面是 Prometheus 的一些组件介绍：

Prometheus 在 Kubernetes 中的监控方案结构如下：

【图源：http://devopscube.com/setup-prometheus-monitoring-on-kubernetes/】

要监控的对象种类很多，我们把相同类型的对象称为一个实体，而每个实体运行时的对象产生的数据有各种各样的，为了归纳收集这些数据， Prometheus 将实体中的各种属性值分为 Counter (计数器)、Gauge (仪表盘)、Histogram(累积直方图)、Summary（摘要）四种类型，实体中的每个属性，称为指标，例如 容器已累计使用 CPU 量，使用指标名称 container_cpu_usage_seconds_total 记录。

每个指标一般格式为：

每个对象都在无时无刻产生数据，为了区分当前指标值属于哪个对象，可以给指标除了指

对象生成类似这种结构的文本后，可以暴露 metrics 端点，让 Prometheus 自动采集，或通过 Pushgateway 推送到 Prometheus 中。

接下来，我们将在 Kubernetes 中搭建一个完整的 Prometheus 监控体系。

微软最有价值专家（MVP）

微软最有价值专家是微软公司授予第三方技术专业人士的一个全球奖项。29年来，世界各地的技术社区领导者，因其在线上和线下的技术社区中分享专业知识和经验而获得此奖项。

MVP是经过严格挑选的专家团队，他们代表着技术最精湛且最具智慧的人，是对社区投入极大的热情并乐于助人的专家。MVP致力于通过演讲、论坛问答、创建网站、撰写博客、分享视频、开源项目、组织会议等方式来帮助他人，并最大程度地帮助微软技术社区用户使用 Microsoft 技术。

更多详情请登录官方网站：
http://mvp.microsoft.com/zh-cn