本文介绍了Kubernetes的监控方法和解决方案，并侧重于日志记录场景。

作者: 刘中伟（墨猿），是阿里巴巴的技术专家。

1) 背景 – Background

监控和日志记录是大规模分布式系统的重要基础设施组件。监控帮助开发人员确认系统的运行状态，而日志记录有助于故障排除和诊断问题。

在Kubernetes中，尽管监控和日志记录是生态系统的一部分，但它们不是核心组件。因此，在大多数情况下，要应用这两个功能，需要云服务提供商进行适配。Kubernetes定义了访问标准和API规范，使得可以快速集成符合API规范的任何组件。

2）监控

监控的类型 de

Kubernetes提供了4种监控服务。

1) 资源监控

通常，CPU、内存、网络等常见资源指标会以数字或百分比的形式进行收集。这是最常见的监控服务，传统的监控系统如Zabbix Telegraph也提供此类服务。

2) 性能监控

性能监控是指应用程序性能管理（APM）监控，用于检查常见应用程序性能指标。通常有隐式调用的虚拟机层和字节码执行层的钩子机制，以及显式注入的应用程序层的钩子机制，用于获取高级度量。这些高级度量通常用于应用程序的优化和诊断。例如，通常的实现如Java虚拟机（JVM）用于Zend Engine，或PHP（超文本预处理器）使用常见的钩子机制来收集JVM中的垃圾回收（GC）次数，不同世代的内存分布以及网络连接数等度量。这些度量用于诊断和优化应用程序的性能。

3）安全监控

安全监控是指执行一系列安全监控策略，主要包括管理非法访问和扫描安全漏洞等内容。

4）事件监控

活动监控是Kubernetes的特殊监控服务。在上一篇文章中，Kubernetes的设计理念之一是通过状态机进行状态转换。具体而言，当状态机从一个正常状态转移到另一个正常状态时，会发生正常事件，而当状态机从一个正常状态转移到异常状态时，会发生警告事件。在此期间，警告事件通常很重要。活动监控的作用是将正常事件和警告事件缓存到数据中心，数据中心通过分析事件生成警报，并通过DingTalk消息、短信消息或电子邮件公开相关异常的处理方法。这种监控服务克服了传统监控的缺陷和不足之处。

Kubernetes监控的演变

在Kubernetes 1.10版本之前，分析师使用像Heapster这样的组件来收集指标。Heapster的设计思想实际上非常简单。

首先，为了收集数据，每个Kubernetes的顶层都提供了一个打包好的cAdvisor组件。当cAdvisor完成数据收集后，Kubernetes将数据进行打包，并作为相应的API公开。在初始阶段，提供了三个API。

• Summary API

 

• Kubelet API

 

Prometheus API

这些API都与cAdvisor的数据源兼容，除了数据格式不同。Heapster支持Summary API和Kubelet API。Heapster定期从每个节点获取数据并将其汇总到内存中，并将相应的服务公开给上层的消费者。在Kubernetes中，常见的消费者如仪表板和HPA（水平Pod自动缩放）控制器调用相应的服务以获取监控数据，并执行必要的自动缩放以显示监控数据。

为什么Kubernetes从Heapster切换到metrics-server呢？Heapster的一个主要原因是标准化了监控数据的API。那么，为什么Heapster要标准化监控数据的API呢？

• お客様の要求は刻々と変化しています。例えば、今日はHeapsterを使って基本的なデータを収集したいが、明日はアプリケーション内のオンラインユーザー数を公開するためのデータAPIを開発したいということがあるかもしれません。さらに、データAPIを独自のAPIシステムに追加して、監視データを表示し、HPAコントローラと同じ方法でデータを消費したいと思うかもしれません。このシナリオをHeapsterで実装することは可能でしょうか？答えはノーです。これは、Heapsterのスケーラビリティが低いことを示しています。

 

2つ目の理由は、Heapsterがデータをキャッシュするために多くのシンクを提供していることです。これらのシンクには、InfluxDB、Simple Log Service（SLS）、DingTalkなどがあり、主にデータの収集とキャッシュを担当しています。多くのお客様は、InfluxDBを使ってデータをキャッシュし、InfluxDBをGrafanaなどのモニタリングデータ可視化ソフトウェアに接続して、モニタリングデータを表示しています。

然而，在社区中，我们发现这些堆栈通常没有得到维护而被搁置。结果导致大量的错误问题一直困扰着整个Heapster项目，也留给了社区，但没有人来修复它们。这给社区项目的活动和稳定性带来了很大的挑战。

鉴于这两个原因，Kubernetes废弃了Heapster，并随后创建了经过优化的度量收集组件metrics-server。

前述的图表显示了Heapster的内部架构。如图所示，Heapster分为几个部分。第一个部分是核心部分。上面的部分是通过标准的HTTP或HTTPS公开的API。中间的源部分相当于用于公开收集的数据的不同API。中间的处理部分用于数据转换和聚合。最后的部分是汇聚部分，负责数据缓存。这是Heapster初始阶段的应用架构。随着时间推移，Kubernetes将标准化监控API，Heapster将逐渐转向metrics-server。

现在，metrics-server 0.3.1的结构非常简单，如上图所示。它包括核心层、数据源层、简单的API层和附加的API注册层。在附加的API注册层中，您可以向Kubernetes的API服务器注册相应的数据API。将来，为了使用metrics-server，您将不再需要访问API层，而是可以通过API服务器访问API注册层。在这种情况下，实际的数据消费者可能会识别特定实现的API，而不是识别metrics-server，这个实现就是metrics-server。这是Heapster和metrics-server之间最大的区别。

Kubernetes数据监控的API规范。

Kubernetes为监控服务准备了三个API标准。具体而言，它标准化并分离了监控数据的消费功能，并将该功能整合到社区中。社区将这些API分为三类。

类型1：资源度量

这个API是在metrics.k8s.io上提供的，它的主要实现是metrics-server。这个API提供了节点级别、Pod级别、命名空间级别和类级别的共享资源指标。通过metrics.k8s.io API可以获取这种类型的指标。

2型）定制指标

对应的API是custom.metrics.k8s.io，主要实现是Prometheus。它提供了资源指标和自定义指标。这些指标实际上与先前的资源指标有重叠。自定义指标是用户定义的，例如，在应用程序中公开的在线用户数量或由下一个MySQL数据库调用的慢查询等。这些指标由客户在应用程序层定义，由Prometheus客户端公开，并由Prometheus收集。

通过这种类型的API收集的数据将以与通过custom.metrics.k8s.io API收集的数据相同的方式进行使用。也就是说，通过这种方法访问Prometheus，可以通过custom.metrics.k8s.io API来实现水平方向的Pod自动扩展并消费数据。

类型3）外部指标

外部度量API是非常特殊的。正如大家所知，Kubernetes已成为云原生API的实现标准。在大多数情况下，云上只使用云服务。例如，某个应用程序在前端使用消息队列，在后端使用远程BLOB存储（RBS）数据库。有时，还会消耗一些云产品的度量数据。这些度量数据包括消息队列中的消息数量、访问层的服务器负载均衡器（SLB）的连接数、SLB上层的200请求数量等。

那么，要如何使用这些指标呢？为了使用这些指标，Kubernetes还实施了一个名为external.metrics.k8s.io的规范。这个规范主要由云服务提供商实施。供应商使用该API来获取云资源的指标。在阿里巴巴云上，我们还提供了阿里巴巴云适配器，用于实施External.metrics.k8s.io API。

Prometheus – 开源社区的监控标准

让我们在这里介绍一下Prometheus，这是一种在开源社区中常见的监控解决方案。为什么Prometheus成为了开源社区的监控标准呢？

• まず、Prometheusは、Cloud Native Computing Foundation（CNCF）のプロジェクトです。現在、Prometheusをモニタリング標準として採用するオープンソースプロジェクトが増えています。実際、Spark、TensorFlow、Flinkなどの一般的なプログラムには、それぞれ標準のPrometheusコレクションAPIが用意されています。

 

• 次に、データベースやミドルウェアなどの一般的なプログラムには、対応するPrometheusの収集クライアントがあり、etcd、ZooKeeper、MySQL、PostgreSQLなどのプログラムには、対応するPrometheusのAPIがあります。Prometheus APIがない場合は、コミュニティが対応するエクスポーターを提供してAPIを実装します。

 

次に、Prometheusの全体的なアーキテクチャを見てみましょう。

上述的图表展示了Prometheus的数据收集链接，可以分为三种数据收集模型。

• 1つ目は、プッシュ・モデルです。このモデルでは、Pushgatewayを通じてデータを収集してキャッシュし、PrometheusがPushgatewayからデータを引き出します。この収集方法は、主にタスクが短時間しか続かないシナリオでの問題点を解決します。具体的には、Prometheusで最も一般的な収集方法として知られているプルモデルでは、データ宣言サイクルがデータ収集サイクルよりも短い場合、一部のデータが収集できないことがあります。例えば、収集サイクルが30秒であるのに対し、タスクの実行時間が15秒しかない場合、一部のデータが収集されない可能性があります。この問題に対処するには、最もシンプルなソリューションは、Pushgatewayにデータを送信してメトリクスをプッシュし、その後Pushgatewayからデータをプルすることです。この方法では、過渡的なタスクはジョブを失うことなく完全に実行されます。

 

• 2つ目は、標準的なプルモデルです。このモデルでは、データは対応するタスクから直接引き出されます。

 

3つ目はPrometheus on the Prometheusモデルです。このモデルでは、データはあるPrometheusインスタンスから別のPrometheusインスタンスに同期されます。

以上是 Prometheus 的三种数据收集方法。对于数据源，Prometheus 不仅支持标准的静态配置，还可以通过服务发现来抓取数据源。具体来说，Prometheus 使用特定的服务发现机制来动态发现收集目标。在 Kubernetes 中很常见，通过这种动态发现机制，只需设置一些注解，就可以自动配置收集任务以收集数据，非常方便。

此外，Prometheus具备Alertmanager外部组件，可以通过电子邮件或短信发送警报。同时，Prometheus还提供了用于显示和消耗数据的上层API客户端、Web UI和Grafana。

总结起来，Prometheus具有以下特点。

• シンプルで強力なアクセス規格：データを収集するために、開発者はAPI標準としてのPrometheusクライアントを実装するだけです。

 

• 多様なデータ収集・キャッシュ方法：Prometheusでは、Pushing、Pulling、Prometheus on Prometheusの各モードでデータを収集し、キャッシュすることができます。

 

• Kubernetesとの互換性。

 

• 豊富なプラグインメカニズムとエコシステム。

 

Prometheusオペレーター：Prometheus オペレータは、おそらく我々が見てきた中で最も複雑なオペレータです。しかし、Prometheus オペレータは、Prometheus のスケーラビリティを利用できるオペレータでもあります。KubernetesでPrometheusを使用している場合は、Prometheus演算子を使用してKubernetesのデプロイとメンテナンスを行うことをお勧めします。

Kube-eventer是Kubernetes的事件缓存工具。

最后，我们来看一下Kubernetes的事件缓存工具——Kube-eventer。Kube-eventer组件是阿里巴巴云容器服务的开源组件。在Kubernetes中，Kube-eventer会缓存组件的事件，包括Pod、节点、核心组件、自定义资源定义（CRD）等。通过API服务器的观察机制，Kube-eventer会将事件缓存到SLS、DingTalk、Kafka、InfluxDB等应用程序，并对其进行一段时间内的审计、监控和警报。目前，我们正在GitHub上开源这个项目。如果您有兴趣，请访问GitHub并查看这个项目。

前面所示的图表展示了DingTalk上的警告快照。正如图中所示，针对Kube-system命名空间生成了警告事件，原因是“由于退避机制，Pod无法重新启动”。同时，还显示了具体发生故障的时间。根据这些信息，我们将进行检查。

3）记录

记录木材出口的方案

接下来，让我们看一下Kubernetes的日志记录服务。在Kubernetes中，主要提供了四种场景下的日志记录。

1）主机内核日志
– 主机内核日志对开发人员诊断常见问题非常有帮助。首先，常见问题之一是网络堆栈异常。当出现这种异常时，控制器表相关的消息可能会显示在iptables标记中。
– 第二个常见问题是驱动程序异常。在一些网络解决方案和涉及GPU的场景中经常会遇到这些异常。
– 第三个常见问题是文件系统异常。实际上，在Docker刚开始阶段时，这些异常经常出现在叠加文件系统（OverlayFS）和高级多层统一文件系统（AUFS）中。当时，开发人员没有手段来监视和诊断这些问题。而现在，这些异常可以直接在主机内核日志中发现。
– 第四个常见问题是一些节点异常。例如，内核崩溃和内核内存不足（OOM）问题也会反映在主机内核日志中。

2）运行时日志
在Docker的日志中，包含了常见的运行时日志。这些日志通常用于故障排除，例如处理无法成功删除Pod的问题。

3）核心组件的日志
Kubernetes的核心组件包括外部中间件（如etcd）以及内部组件，如API服务器、kube-scheduler、controller-manager和kubelet等。通过这些组件的日志，我们可以了解Kubernetes集群控制平面中资源的使用情况以及当前执行状态是否出现异常。

另外，在某些核心中间件中，例如网络中间件的入口，可以查看整个访问层的流量。使用入口日志，可以进行详细的访问层应用程序分析。

4）从已安装的应用程序日志中，可以确认服务层的状况。例如，可以通过应用程序日志确认服务层是否有500个请求、是否发生了恐慌、是否发生了异常访问或非法访问等情况。

日志收集

现在，我们将详细说明日志收集。一般来说，为了从各种地方收集日志，Kubernetes 提供了三种主要的日志收集方法。

• 1つ目の方法は、ホストファイルからログを収集する方法です。一般的に、ボリュームなどのコンテナのコンポーネントは、ログファイルをホストに書き込みます。そして、ホストのログローテーションポリシーに基づいて、ログファイルがローテーションされます。最後に、ホスト上のエージェントがログを収集します。

 

• 2つ目は、コンテナ内からログファイルを収集する方法です。しかし、これらのファイルを処理する一般的な方法は何でしょうか？一般的には、サイドカー・ストリーミング・コンテナがログファイルを標準出力に書き込み、それが対応するログファイルに書き込まれます。その後、ログファイルはローカルにローテーションされます。最後に、外部のエージェントがログを収集します。

 

3つ目の方法は、ログをstdoutに直接書き込む方法です。これは、一般的なロギングポリシーです。リモートエンドは、エージェントを使用するか、いくつかのサーバーレスAPIなどの標準APIを呼び出して、ログを直接収集します。

在社区中，我们推荐使用一种叫做Fluentd的收集解决方案。Fluentd会在每个节点上选出一个代理，并将数据汇总到Fluentd服务器上。这个服务器会将数据缓存到诸如Elasticsearch的相应组件中，并由Kibana来展示数据。或者，服务器也可以将数据缓存到InfluxDB中，并由Grafana来展示数据。这是社区中推荐的方法。

4）总结

最后，让我们来看一下关于阿里云的监控和日志记录的最佳实践，作为今天课程的总结。正如我们在课程开始时所提到的，监控和日志记录并不是Kubernetes的核心组件。Kubernetes定义了大部分监控和日志记录功能的API标准，并由上层云供应商单独适配这些功能。

阿里巴巴云容器服务的监控系统

首先，让我们来看一下阿里巴巴云容器服务的监控系统。这张图展示了监控系统的整体架构。

以下这四个产品与监控和日志记录服务密切相关。

SLS是一种日志服务。如前所述，日志会根据其在Kubernetes内的收集位置以不同的方式进行收集。例如，核心组件的日志、访问层的日志和应用程序的日志分别采用不同的方式进行收集。同样，在阿里云容器服务中，审计日志可以从API服务器收集，访问层的日志可以从服务网格或入口控制器收集，应用程序的日志可以从应用程序层收集。

然而，這個數據鏈路不符合我們的要求。我們需要能夠顯示和分析上層數據的功能，而不僅僅是緩存數據。SLS可以完美滿足這些需求。舉個例子，在監察記錄中，我們可以檢查今天的操作次數，變更次數，攻擊次數，以及系統異常的發生情況等等。所有這些結果都可以在監察儀表板上查看。

ARMS是一款用于监控应用程序性能的产品。您可以使用ARMS（应用程序实时监控服务）等产品进行性能监测。目前，ARMS已支持Java和PHP语言，并可用于应用程序的诊断和调优。

“AHAS（Application High Availability Service）是一个特殊的产品。AHAS是一个具有自动发现架构功能的系统。正如您所知，Kubernetes的组件通常按照微服务架构部署。在微服务架构中，组件和组件副本的数量会增加。因此，拓扑管理变得复杂。”

实际上，如果可见性不足，对于在Kubernetes中应用程序的流量流向进行监视或故障排除将会很困难。AHAS旨在通过监视网络堆栈来展示Kubernetes中应用程序的整体拓扑结构。基于拓扑结构，AHAS监视资源、网络带宽和流量，并诊断异常事件。此外，AHAS可以根据发现的架构拓扑实现其他监控解决方案。

云监控器
云监控器实施了基本的云监视功能。它收集标准资源指标并显示监控数据。此外，它还可以显示节点、Pod等组件的指标，并能触发警报。

阿里巴巴云通过加强功能。

在这个部分，我们将介绍阿里巴巴云开发的开源功能增强。首先，正如前面提到的，metrics-server已经得到了大幅提升效率的改进。然而，从客户的角度来看，这种优化是通过削减部分功能来实现的，因此产生了很多不便之处。例如，许多客户希望将监控数据缓存到SLS或InfluxDB等同步服务器中。但是，这个功能在社区版中不再可用。为了解决这个问题，阿里巴巴云保留了经常进行维护的共用同步服务器。这是第一个增强点。

第二点是提高整体兼容性。如你所知道的，与Kubernetes集成的生态系统并不同步发展。例如，仪表板的发布与Kubernetes的主要版本不一致。具体而言，当Kubernetes 1.12发布时，仪表板并不会同步升级到版本1.12，而是以自己的节奏发布。结果，很多依赖Heapster的组件会在Heapster升级到metrics-server后出现故障。为了解决这个问题，阿里巴巴云使metrics-server与Heapster具有完全的兼容性。从当前的Kubernetes 1.7版本到Kubernetes 1.14，阿里巴巴云的metrics-server将适应所有监控组件的数据消耗量。

此外，我们还增强了Kube-eventer和节点问题检测器（NPD）。对于Kube-eventer组件的增强，我们之前已经进行了说明。至于NPD，我们添加了许多监测和检测指标，包括内核挂起、节点问题、源网络地址转换（SNAT）的检测，以及入站和出站流量的监视等。此外，NPD还包括其他检查项目，如FD等，它们在阿里云平台上也得到了大大的加强。通过这些功能增强，开发者可以直接引入NPD的检查项目，根据节点诊断生成警报，并通过Kube-eventer将警报缓存到Kafka或DingTalk中。

此外，Prometheus系统的高级层也得到了加强。在存储层面上，开发者现在可以连接到阿里云的HiTSDB或InfluxDB。在收集层面上，我们提供了优化的节点导出器组件以及几种基于场景的监控导出器，如Spark、TensorFlow和Argo。另外，阿里云还提供了许多额外功能，包括监控单个GPU和共享GPU等与GPU相关的功能。

搭配ARMS团队，我们启动了Prometheus的托管版本。开发者们现在可以直接访问Prometheus的监控和收集功能，只需使用即时可用的HELM聊天工具，而无需部署Prometheus服务器。

阿里巴巴云容器服务的日志系统

阿里巴巴云对于日志系统进行了哪些改进呢？首先，它对各种类型的日志采集方法进行了完全的支持。Pod、核心组件、Docker引擎、内核以及部分中间件的日志都会被收集到阿里云日志服务（SLS）中。然后，这些日志会被从SLS缓存并存档到对象存储服务（OSS），同时也会设置缓存预算以供MaxCompute使用。

此外，通过OpenSearch、E-Map和Flink，可以搜索日志并实时消费上层数据。要显示日志，可以连接到开源的Grafana或者DataV等服务。通过这种方式，可以实现完整的数据收集和消费的协作。

得出结论

在本篇文章中，首先介紹了監視服務的相關內容，包括在四種容器情境下的共同監視方法，以及Kubernetes中監視的進展和API的標準化，並介紹了針對共同數據來源的兩種監視解決方案。隨後，對四種日誌情境和名為Fluentd的收集解決方案進行了解說，最後提出了在阿里巴巴雲上的日誌和監測最佳實踐。

这个博客是从英文版翻译过来的。原始版本可在此处查看。我们部分使用了机器翻译。如果有翻译错误，请指正，谢谢。

阿里巴巴云拥有两个数据中心在日本，并且是亚太区第一的云基础设施供应商，在全球拥有超过60个可用区域（2019年加特纳数据）。欲了解更多阿里巴巴云的详细信息，请访问阿里巴巴云日本官方网页。