第 3 章 Kubernetes下监控和日志

在本章中，我们将讨论在 Kubernetes 中监控和日志记录的最佳做法。我们将深入探讨不同监视模式、要收集的重要指标以及从这些原始指标构建仪表板的详细信息。然后，我们总结一下为 Kubernetes 群集实现监视的示例。

指标与日志

您首先需要了解日志收集与指标收集之间的区别。它们是互补的，但作用不同。

• 指标

  一段时间内测量的一系列数字

• 日志

  用于系统的探索性分析

您需要同时使用指标和日志记录的一个示例是应用程序性能不佳的情况。我们对于这个问题的第一个指示可能是对托管应用程序的 Pod 上的高延迟发出警告，但是这个指标可能不能很好地指示这个问题。然后，我们可以查看日志，对应用程序发出的错误的进行调查。

监控技术

黑盒监控侧重于从应用程序外部进行监视，并且是传统用用于监视 CPU、内存、存储等组件的系统。黑盒监视仍可用于基础设施级别的监视，但它缺乏对应用程序如何运行的洞察和上下文环境。例如，要测试群集是否正常运行，我们可以调度一个pod，如果成功，我们知道集群中的调度器和服务发现在是正常运行的，所以我们可以假定群集组件是健康的。

白盒监控侧重于应用程序状态上下文中的详细信息，例如 HTTP 请求总数、500出现的错误次数、请求延迟等。通过白盒监控，我们可以开始了解系统状态的"为什么"。它允许我们问，“为什么磁盘填满了？而不仅仅是“磁盘满了”。

监控模式

你可能会看着监控，然后说，“这有多难？我们一直在监控我们的系统。是的，您今天的一些典型监控模式也适用于您监控 Kubernetes 的方式。区别在于，像 Kubernetes 这样的平台更具动态性和瞬态性，您需要改变对如何监视这些环境的看法。例如，监视虚拟机 （VM） 时，您希望该 VM 全天候启动，并保留其所有状态。在 Kubernetes 中，pod可能非常动态且寿命短，因此您需要进行监控，以便处理这种动态和瞬态性质。

在监视分布式系统时，需要关注几种不同的监控模式。

由布伦丹·格雷格推广的USE方法侧重于以下方法：

• U=利用率
• S= 饱和度
• E=错误

此方法侧重于基础设施监视，因为使用它进行应用程序级监视是有限制的。USE 方法是这样描述的：“对于每个资源，检查利用率、饱和度和错误率。这种方法可以使您快速识别系统的资源约束和错误率”。例如，要检查群集中节点的网络健康状况，您需要监视利用率、饱和度和错误率，以便能够轻松识别网络堆栈中的任何网络瓶颈或错误。USE 方法是一个更大的工具箱中的工具，并不是您用来监视系统的唯一方法。

另一种监控方法，称为RED方法，是由汤姆·威尔克推广的。RED 方法侧重于以下内容：

• R=速率
• E=错误
• D= 持续时间

这一理念来自谷歌的四个黄金信号：

• 延迟（服务请求所需的时间）
• 流量（对系统的需求量）
• 错误（失败的请求率）
• 饱和度（服务的利用率）

例如，您可以使用此方法监视在 Kubernetes 中运行的前端服务，以计算以下内容：

• 我的前端服务处理了多少请求？
• 服务的用户收到多少 500 个错误？
• 服务是否被请求过度使用？

从前面的示例中可以看到，此方法更侧重于用户的体验及他们对服务的体验。

USE 和 RED 方法是相辅相成的，因为 USE 方法侧重于基础设施组件，而 RED 方法侧重于监视应用程序的最终用户体验。

Kubernetes 指标概述

现在，我们了解了不同的监视技术和模式，接下来让我们来看看在 Kubernetes 群集中应该监视哪些组件。 Kubernetes 群集由控制平面组件和工作节点组件组成。控制平面组件由 API Server、etcd、scheduler 和 controller-manager 组成，工作节点由 kubelet、容器运行时、kube-proxy、kube-dns 和 pod 组成。您需要监视所有这些组件，以确保群集和应用程序正常运行。

Kubernetes 以多种方式公开这些指标，因此，让我们看一下可用于手机群集指标的不同组件。

cAdvisor

Container Advisor（cAdvisor）是一个开源项目，用于收集节点上运行的容器的资源和指标。cAdvisor 内置于 Kubernetes kubelet中，它运行在群集中的每个节点上。它通过 Linux 控制组 （cgroup） 树收集内存和 CPU 指标。如果您不熟悉 cgroups，那么它是一个 Linux 内核特性，它允许隔离 CPU、磁盘 I/O 或网络I/O 的资源。cAdvisor 还将通过内置于 Linux 内核的 statfs 收集磁盘指标。这些是您实际上不需要担心的实现细节，但是您应该了解这些指标是如何公开的，以及您可以收集的信息类型。您应该将 cAdvisor 视为所有容器指标的真实来源。

Metrics Server

Kubernetes metrics server 和 Metrics Server API 替代了已弃用的 Heapster。Heapster 在如何实现数据接收器时存在一些架构上的缺陷，这导致了在核心 Heapster 代码库中存在许多要解决的问题。这个问题通过在 Kubernetes 中实现资源和自定义指标 API 作为聚合 API 得到解决。这允许在不更改 API 的情况下切换实现。

在Metrics Server API 和 Metrics Server 中有两个方面需要理解。

首先，资源指标 API 的规范实现是度量服务器。Metrics Server收集资源指标，如 CPU 和内存。它从 kubelet 的 API 收集这些指标，然后将它们存储在内存中。 Kubernetes 在调度器、水平 Pod 自动缩放器 （HPA） 和垂直 Pod 自动缩放器 （VPA） 中使用这些资源指标。

其次，自定义指标 API 允许监视系统收集任意指标。这允许监视解决方案构建自定义适配器，从而允许扩展到核心资源指标之外。例如，Prometheus 构建了第一个自定义指标适配器，它允许您基于自定义指标使用 HPA。这可根据您的用例提供更好的伸缩性，因为现在您可以基于 Kubernetes 外部的指标引入队列大小和缩放等指标。

现在已经有了标准化的指标 API，这为扩展普通老式 CPU 和内存指标提供了许多可能性。

kube-state-metrics

kube-state-metrics 是一个 Kubernetes 附件组件，用于监视存储在 Kubernetes 中的对象。在使用 cAdvisor 和 metrics server 提供有关资源使用情况的详细指标时，kube-state-metrics 主要用于确定部署到群集的 Kubernetes 对象的条件。

以下是 kube-state-metrics 可以为您回答的一些问题：

• Pods
  • 群集中部署了多少个pods？
  • 有多少 pods 处于挂起状态？
  • 是否有足够的资源来满足 pod 请求？
• Deployments
  • 运行状态和期望状态各有多少 Pod？
  • 有多少副本可用？
  • 更新了哪些部署？
• Nodes
  • 我的工作节点的状态是什么？
  • 我的群集中分配哪些 CPU 核心？
  • 是否存在不可调度的节点？
• Jobs
  • 什么时候开始工作？
  • 什么时候完成的？
  • 有多少个作业失败？

在撰写本文时，kube-state-metrics跟踪了 22 种对象类型。它们总是在扩展，您可以在Github 存储库中找到文档。

我要监视哪些指标？

简单的答案是"一切”，但如果你试图监控太多，就会产生太多的噪音，过滤掉你需要有洞察力的真实信号。当我们考虑在 Kubernetes 进行监视时，我们希望采用一种分层方法，其中考虑到以下几点：

• 物理或虚拟节点
• 群集组件
• 群集扩展
• 最终用户应用程序

通过这种分层的监控方法，您可以更轻松地识别监控系统中的正确信号。它允许您使用更有针对性的方法处理问题。例如，如果 Pod 进入挂起状态，则可以从节点的资源利用率开始，如果一切正常，可以针对群集级组件。

以下是您希望在系统中定位的指标：

• Nodes
  • CPU 利用率
  • 内存利用率
  • 网络利用率
  • 磁盘利用率
• Cluster components
  • etcd 延迟
• Cluster add-ons
  • 群集自动缩放器
  • Ingress 控制器
• Application
  • 容器内存利用率和饱和度
  • 容器 CPU 利用率
  • 容器网络利用率和错误率
  • 特定于应用程序框架的指标

监控工具

有许多监控工具可以与 Kubernetes 集成，而且每天都有更多监控工具到达，构建在它们的特性集上，可以更好地与 Kubernetes 集成。以下是与 Kubernetes 集成的一些常用工具：

• Prometheus

  Prometheus 是一个开源系统监控和告警工具包，最初由 SoundCloud开发。自 2012 年成立以来，许多公司和组织都采用了 Prometheus，该项目拥有非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，并且独立于任何公司进行维护。为了强调这一点，并阐明项目的治理结构，Prometheus 于 2016 年加入云原生计算基金会 （CNCF），作为继 Kubernetes 之后的第二个托管项目。

• INFLUXDB

  INFLUXDB 是一个时间序列数据库，旨在处理高写入和查询负载。它是 TICK（Telegraf、InfluxDB、Chronograf和Kapacitor）堆栈的组成部分。InfluxDB 旨在用作任何涉及大量时间戳数据的用例的备份存储，包括 DevOps 监视、应用程序指标、IoT 传感器数据和实时分析。

• Datadog

  Datadog 为云级应用程序提供监控服务，通过基于 SaaS 的数据分析平台监视服务器、数据库、工具和服务。

• Sysdig

  Sysdig Monitor 是一种商业工具，可为容器原生应用提供 Docker 监控和 Kubernetes 监控。Sysdig 还允许您使用直接 Kubernetes 集成来收集、关联和查询Prometheus指标。

• 云提供商工具

  GCP Stackdriver

  Stackdriver Kubernetes 引擎监控旨在监控 Google Kubernetes 引擎 （GKE） 集群。它同时管理监视和日志服务，并提供一个为 GKE 群集定制的仪表板接口。Stackdriver 监视提供云应用程序的性能、正常时间和整体运行状况的可见性。它收集来自 Google 云平台 （GCP）、亚马逊 Web 服务 （AWS）、托管的正常运行时间探测和应用程序检测的指标、事件和元数据。

  Microsoft Azure Monitor for containers

  Microsoft Azure Monitor for containers是一个用于监视部署到Azure 容器实例或托管在 Azure Kubernetes 服务上的托管 Kubernetes 群集的容器工作负载的性能的特性。监视容器至关重要，尤其是在大规模运行具有多个应用程序的生产群集时。Azure Monitor for containers 通过从 Kubernetes 中通过指标 API 提供的控制器、节点和容器收集内存和处理器指标来提供性能可见性。还会收集容器日志。在启用 Kubernetes 群集的监视后，将通过 Linux 的日志分析代理的容器化版本自动为您收集指标和日志。

  AWS Container Insights

  如果您在 Amazon 弹性容器服务 （ECS）、Amazon 弹性 Kubernetes 服务或 Amazon EC2 上的其他 Kubernetes 平台上使用，则可以使用 CloudWatch Container Insights 收集、聚合和汇总来自容器化应用程序和微服务的指标和日志。这些指标包括 CPU、内存、磁盘和网络等资源的利用率。Container Insights 还提供诊断信息（如容器重新启动失败）以帮助您隔离问题并快速解决问题。

在查看实现用于监视指标的工具时，一个重要方面是查看如何存储指标。提供具有键/值对的时间序列数据库的工具将为您提供更高程度的属性指标。

提示

始终评估您已有的监视工具，因为使用新的监视工具具有学习曲线和由于该工具的操作实施而产生的成本。许多监控工具现在都集成在 Kubernetes 中，因此请评估您目前拥有哪些工具，以及它们是否满足您的要求。

使用Prometheus监控Kubernetes

在本节中，我们将重点介绍 Prometheus 的监控指标，它与 Kubernetes 标签、服务发现和元数据提供了良好的集成。我们在整个章节中实现的高级概念也将应用于其他监控系统。

Prometheus 是一个由CNCF托管的开源项目。它最初是由SoundCloud开发的，它的很多概念都基于谷歌的内部监控系统 BorgMon。它使用密钥对实现了一个多维数据模型，其的工作方式与 Kubernetes 标记系统的工作方式非常类似。Prometheus 以人类可读的格式公开度量标准，如下例所示：

1# HELP node_cpu_seconds_total Seconds the CPU is spent in each mode.
2# TYPE node_cpu_seconds_total counter
3node_cpu_seconds_total{cpu="0",mode="idle"} 5144.64
4node_cpu_seconds_total{cpu="0",mode="iowait"} 117.98

为了收集指标，Prometheus 使用pull模型，在该模型中，Prometheus 服务器通过一个指标端点来收集和获取指标 。像 Kubernetes 这样的系统已经以 Prometheus 格式公开了它们的指标，这使得收集指标变得简单。Kubernetes 生态系统中许多其他项目（NGINX、Traefik、Istio、LinkerD等）也以 Prometheus 格式公开其指标。Prometheus 还可以使用导出器，它允许您从服务中获取发出的指标，并将其转换为 Prometheus 格式的指标。

普罗米修斯有一个非常简化的拱形，如图 3-1 所示。

图 3-1 Prometheus架构

提示

您可以在群集内或群集外部安装 Prometheus。最好从"实用程序群集"监视群集，以避免也影响监控系统的生产问题。像Thanos这样的工具为 Prometheus 提供了高可用性，并允许您将指标导出到外部存储系统中。

深入探讨Prometheus 架构超出了本书的范围，您应该参考另一本关于这个主题的专门书籍。Prometheus：Up & Running（O’Reilly）是一本很好的深入书籍，让你开始。

所以，让我们潜入，让Prometheus建立在我们的 Kubernetes 集群之上。有许多不同的方法可以做到这一点，部署将取决于您的具体实现。在本章中，我们将安装Prometheus Operator：

• Prometheus Server

  获取并存储从系统收集到的指标。

• Prometheus Operator

  使 Prometheus 配置Kubernetes本地，并管理和操作 Prometheus 和 Alertmanager 集群。允许您通过本机 Kubernetes 资源定义创建、销毁和配置Prometheus 资源。

• Node Exporter

  从群集中的 Kubernetes 节点导出主机指标。

• kube-state-metrics

  收集 Kubernetes 特定的指标。

• Alertmanager

  允许您配置告警并将其转发到外部系统。

• Grafana

  为 Prometheus 提供可视化的仪表板功能。

1helm install --name prom stable/prometheus-operator

安装Operator后，应看到部署到群集的以下pods：

 1$ kubectl get pods -n monitoring
 2NAME                                   READY   STATUS    RESTARTS   AGE
 3alertmanager-main-0                    2/2     Running   0          5h39m
 4alertmanager-main-1                    2/2     Running   0          5h39m
 5alertmanager-main-2                    2/2     Running   0          5h38m
 6grafana-5d8f767-ct2ws                  1/1     Running   0          5h39m
 7kube-state-metrics-7fb8b47448-k6j6g    4/4     Running   0          5h39m
 8node-exporter-5zk6k                    2/2     Running   0          5h39m
 9node-exporter-874ss                    2/2     Running   0          5h39m
10node-exporter-9mtgd                    2/2     Running   0          5h39m
11node-exporter-w6xwt                    2/2     Running   0          5h39m
12prometheus-adapter-66fc7797fd-ddgk5    1/1     Running   0          5h39m
13prometheus-k8s-0                       3/3     Running   1          5h39m
14prometheus-k8s-1                       3/3     Running   1          5h39m
15prometheus-operator-7cb68545c6-gm84j   1/1     Running   0          5h39m

让我们来看看 Prometheus Server，看看您如何运行一些查询来检索 Kubernetes 的指标：

1kubectl port-forward svc/prom-prometheus-operator-prometheus 9090

这将创建一个隧道到端口 9090 上的本地主机。现在，我们可以打开一个Web浏览器，并连接到Prometueus 服务器http://127.0.0.1:9090

图3-2 描述了您将的屏幕，如果您成功的将 Prometheus 部署到群集。

现在，我们已经部署了 Prometheus，让我们通过Prometheus PromQL 查询语言探讨一些 Kubernetes 指标。有一个PromQL基础知识指南可用。

在本章前面，我们讨论了使用 USE 方法，所以让我们收集一些关于 CPU 利用率和饱和度的节点指标。

图 3-2 Prometheus仪表板

在表达式输入中，输入以下查询：

1avg(rate(node_cpu_seconds_total[5m]))

这将返回整个群集的平均 CPU 利用率。

如果我们想要获得每个节点的 CPU 利用率，我们可以编写如下所示的查询：

1avg(rate(node_cpu_seconds_total[5m])) by (node_name)

这将返回群集中每个节点的平均 CPU 利用率。

现在，您具备在 Prometheus 中运行查询的一些经验，让我们来看看 Grafana 如何帮助构建仪表板可视化，以实现我们想要跟踪的这些常见的 USE 方法指标。您安装的 Prometheus Operator 的最大的优点在于，它自带了一些预先构建的 Grafana 仪表板，您可以使用这些仪表板。

现在，您需要创建一个到 Grafana pod的端口转发隧道，以便可以从本地计算机访问它：

1kubectl port-forward svc/prom-grafana 3000:3000

现在，将 Web 浏览器指向http://localhost:3000并使用以下凭据登录：

• 用户名：admin
• 密码：admin

在 Grafana 仪表板下，您会发现一个名为"Kubernetes/USE Method/Cluster"的仪表板。这个仪表板为您提供了 Kubernetes 群集的利用率和饱和度的良好概述，这是 USE 方法的核心。图 3-3显示了仪表板的示例。

图 3-3 Grafana仪表板

请继续，花一些时间来探索可以在 Grafana 中可视化的不同仪表板和指标。

提示

避免创建过多的仪表板（也称为"图表墙”），因为工程师在故障排除时很难对此进行推理。您可能认为在仪表板中包含更多信息意味着更好的监视，但在大多数情况下，它会导致查看仪表板的用户更加混乱。将仪表板设计重点放在结果和解决时间上。

日志概述

到目前为止，我们已经讨论了很多关于指标和 Kubernetes 的内容，但是为了全面了解您的环境，您还需要收集和集中Kubernetes群集及部署到群集的应用程序的日志。

使用日志，可能很容易地说"让我们只记录所有内容"，但这可能会导致两个问题：

• 有太多的噪音，不能快速找到问题。
• 日志可能会消耗大量资源，并带来很高的成本。

对于究竟应该记录什么并没有明确的答案，因为调试日志已经成为一种不可避免的麻烦。随着时间的推移，您将开始更好地了解您的环境，并了解可以从日志系统调出哪些噪音。此外，为了解决存储的日志量不断增加的问题，您需要实现保留和存档策略。从最终用户体验来看，拥有 30 到 45 天的历史日志是一个很好的选择。这允许对较长时间内出现的问题进行排查，但也减少了存储日志所需的资源量。如果出于合规性原因需要长期存储，则需要将日志存档到更具成本效益的资源中。

在 Kubernetes 群集中，需要记录多个组件。以下是应从中收集指标的组件列表：

• 节点日志
• Kubernetes 控制平面日志
  • API Server
  • Controller manager
  • Scheduler
• Kubernetes审计日志
• 应用程序容器日志

使用节点日志，您希望收集发生在基本节点服务的事件。例如，您需要从在工作节点上运行的 Docker 守护进程收集日志。一个健康的 Docker 守护进程对于在工作节点上运行容器至关重要。收集这些日志将帮助您诊断使用 Docker 守护进程可能遇到的任何问题，并为您提供有关守护进程的任何基本问题的信息。您还需要从基础节点登录其他一些基本服务。

Kubernetes 控制平面由多个组件组成，您需要从这些组件中收集日志，以便更深入地了解其中的潜在问题。Kubernetes 控制平面是群集健康的核心，您需要将它存储在主机上的日志在 /var/log/kube-APIserver.log、/var/log/kube-scheduler.log和*/var/log/kube-controller-manager.log*中。controlloer manager 负责创建由最终用户定义的对象。例如，作为用户，例如，您创建一个 Kubernetes 服务，该服务的类型为 LoadBalancer，并且该服务处于挂起状态。Kubernetes 事件可能不会提供诊断问题的所有详细信息。如果在集中式系统中收集日志，它将为您提供有关底层问题的更多细节，并更快地的方法来调查该问题。

您可以将 Kubernetes 审核日志视为安全监控，因为它们使您能够深入了解谁在系统中做了什么。这些日志可能非常嘈杂，因此您需要根据您的环境进行调整它们。在许多情况下，这些日志在首次初始化时可能会导致日志记录系统出现巨大的峰值，因此请确保遵循有关审核日志监视的 Kubernetes 文档指南。

通过应用程序容器日志，您可以深入了解应用程序正在发出的实际日志。您可以通过多种方式将这些日志转发到中央存储库。第一种推荐方法是将所有应用程序日志发送到 STDOUT，因为这为您提供了统一的应用程序日志记录方式，并且监视守护进程集可以直接从 Docker 守护进程收集日志。另一种方法是使用sidecar模式，并在 Kubernetes pod中的应用程序容器旁边运行日志转发容器。如果应用程序将日志记录到文件系统，则可能需要使用此模式。

注意

有许多选项和配置可用于管理 Kubernetes 审核日志。这些审核日志可能非常嘈杂，并且记录所有操作的成本可能很高。应考虑查看审核日志记录文档，以便可以针对您的环境微调这些日志。

日志记录工具

与收集指标一样，有许多工具可以手机 Kubernetes 和群集中运行的应用程序的日志。您可能已经拥有了这方面的工具，但请注意该工具如何实现日志记录的。该工具应具有作为 Kubernetes 守护程序运行的功能，并且对于不向 STDOUT 发送日志的应用程序，还应具有作为sidecar运行的解决方案。利用现有工具可能非常有利，因为您已经拥有了该工具的大量操作知识。

Kubernetes 集成的一些较流行的工具包括：

• Elastic Stack
• Datadog
• Sumo Logic
• Sysdig
• 云提供商服务（GCP Stackdriver、Azure Monitor for containers和 Amazon CloudWatch）

当寻找集中日志的工具时，托管解决方案可以提供大量价值，因为它们可以减轻很多操作成本。托管自己的日志记录解决方案在第N天看起来很棒，但随着环境的增长，维护该解决方案可能非常耗时。

使用 EFKStack 进行日志记录

在本书中，我们使用Elasticsearch、Fluentd 和 Kibana （EFK） stack来设置群集的监视。实现 EFK stack可能是一种很好的入门方式，但是在某些情况下，您可能会问自己，“真的值得管理自己的日志记录平台吗？通常情况下，这样做是不值得的，因为自托管日志记录解决方案在第一天就很棒，但在第 365 天，它们变得过于复杂。随着环境的扩展，自承载日志记录解决方案在操作上变得更加复杂。没有一个正确答案，因此请评估业务需求是否需要您托管自己的解决方案。还有许多基于 EFK stack的托管解决方案，因此，如果您选择不托管它，您始终可以轻松移动它。

您将为EFKStack部署以下内容：

• Elasticsearch Operator
• Fluentd （将日志从我们的 Kubernetes 环境转发到 Elasticsearch）
• Kibana（用于搜索、查看和与存储在 Elasticsearch 中的日志进行交互的可视化工具）

将清单部署到 Kubernetes 群集：

1kubectl create namespace logging
2kubectl apply -f https://raw.githubusercontent.com/dstrebel/kbp/master/elasticsearch-operator.yaml -n logging

部署Elasticsearch operator以聚合所有转发的日志：

1kubectl apply -f https://raw.githubusercontent.com/dstrebel/kbp/master/efk.yaml -n logging

这将部署 Fluentd 和 Kibana，这将使我们能够将日志转发到弹性搜索并使用 Kibana 可视化日志。

您应该会看到部署到群集的以下pods：

 1kubectl get pods -n logging
 2efk-kibana-854786485-knhl5               1/1     Running   0          4m
 3elasticsearch-operator-5647dc6cb-tc2st   1/1     Running   0          5m
 4elasticsearch-operator-sysctl-ktvk9      1/1     Running   0          5m
 5elasticsearch-operator-sysctl-lf2zs      1/1     Running   0          5m
 6elasticsearch-operator-sysctl-r8qhb      1/1     Running   0          5m
 7es-client-efk-cluster-9f4cc859-sdrsl     1/1     Running   0          4m
 8es-data-efk-cluster-default-0            1/1     Running   0          4m
 9es-master-efk-cluster-default-0          1/1     Running   0          4m
10fluent-bit-4kxdl                         1/1     Running   0          4m
11fluent-bit-tmqjb                         1/1     Running   0          4m
12fluent-bit-w6fs5                         1/1     Running   0          4m

在所有 pod都"Running"后，让我们继续通过端口转发连接到 Kibana 到我们的本地主机：

1export POD_NAME=$(kubectl get pods --namespace logging -l "app=kibana,release=efk" -o jsonpath="{.items[0].metadata.name}")
2kubectl port-forward $POD_NAME 5601:5601

现在，将 Web 浏览器指向http://localhost:5601打开 Kibana 仪表板。

要与从 Kubernetes 群集转发的日志进行交互，您首先需要创建一个索引。

首次启动 Kibana 时，您需要导航到"Management"选项卡，并为 Kubernetes 日志创建索引模式。系统将指导您完成所需的步骤。

创建索引后，可以使用 Lucene 查询语法搜索日志，如下所示：

1log:(WARN|INFO|ERROR|FATAL)

这将返回包含WARN、INFO、ERROR或FATAL字段的所有日志。你可以看到 图3-4 中的示例。

图 3-4 kibana仪表板

在 Kibana 中，您可以对日志执行临时查询，还可以构建仪表板来提供环境概述。

继续，你可以在kibana可视化花一些时间来探索不同的日志。

告警

告警是一把双刃剑，你需要在告警与应该监视的内容之间取得平衡。过度告警会导致告警疲劳，重要事件将在所有噪音中丢失。例如，每当pod发生故障时，都会生成告警。你可能会问，“为什么我不想监视pod故障？嗯，Kubernetes 的优点是它提供了自动检查容器运行状况并自动重新启动容器的功能。您确实希望将告警重点放在影响服务级别目标 （SSO） 的事件上。SO 是您与服务最终用户一致的特定可衡量特征，如可用性、吞吐量、频率和响应时间。设置 SON 会为最终用户设定期望值，并明确系统应如何工作。如果没有 SLO，用户可以形成他们的意见，这可能是对服务的不切实际的期望。在像 Kubernetes 这样的系统中发出告警需要一种全新的方法，从我们通常习惯和需要关注最终用户如何体验服务。例如，如果前端服务的 SLO 是 20 毫秒的响应时间，并且您看到比平均值更高的延迟，则您希望收到有关该问题的告警。

您需要决定哪些告警是好的，需要干预。在典型的监控中，您可能习惯于对 CPU 使用率高、内存使用率或进程未响应发出警报。这些可能看起来不错警报，但可能并不表示某人需要立即采取行动并需要通知待命工程师的问题。对待命工程师的警报应该是一个需要立即引起人类注意并影响应用程序的 UX 的问题。如果您曾经遇到过"该问题自行解决"的情况，则表明警报不需要联系待命工程师。

处理不需要立即操作的警报的一种方法是专注于自动修复原因。例如，当磁盘填满时，您可以自动删除日志以释放磁盘上的空间。此外，在应用部署中利用 Kubernetesliveness probes存活性探测可以帮助在应用程序中未响应的进程中自动修复问题。

生成警报时，您还需要考虑警报阈值;如果设置的阈值太短，则警报可能会收到大量误报。通常建议设置至少五分钟的阈值，以帮助消除误报。提出标准阈值有助于定义标准，避免对许多不同的阈值进行微观管理。例如，您可能希望遵循 5 分钟、10 分钟、30 分钟、1 小时等的特定模式。

在生成警报通知时，您希望确保在通知中提供相关信息，例如，提供指向"行动手册"的链接，该手册提供故障排除或其他有关解决问题的有用信息。您还应在通知中包括有关数据中心、区域、应用所有者和受影响系统的信息。提供所有这些信息将使工程师能够快速确定围绕该问题的理论。

您还需要构建通知通道来路由已触发的警报。在考虑"触发警报时我应该通知谁"时，应确保通知不只是发送到通讯组列表或团队电子邮件。如果将警报发送到较大的组，则往往会发生的情况是，由于用户将这些警报视为噪声，它们最终会被过滤掉。您应该将通知路由到要对问题负责的用户。

警觉后，你将永远无法在一天得到完美的，我们可以争辩说，它可能永远不会是完美的。您只想确保逐步改进警报，以防止警报疲劳，这可能导致员工倦怠和系统出现许多问题。

注意

有关如何对系统进行警报和管理的进一步见解，请阅读 Rob Ewaschuk 的“我的警报哲学”，该哲学基于 Rob 作为 Google 站点可靠性工程师 （SRE） 的观察结果。

监控、日志和告警的最佳实践

以下是您应该采用的有关监控、日志和告警的最佳做法。

监控

• 监视节点和所有 Kubernetes 组件的利用率、饱和度和错误率，并监视应用程序的速率、错误和持续时间。
• 使用黑盒监控来监视系统的症状而不是预测性运行状况。
• 使用白盒监控使用仪表检查系统及其内部。
• 实施基于时间序列的指标，以获得高精度指标，从而让您深入了解应用程序的行为。
• 利用像Prometheus这样的监测系统，为高维性提供关键标签;这将给影响问题的症状提供更好的信号。
• 使用平均指标根据事实数据可视化子计和指标。利用总和指标来可视化特定指标的分布。

日志

• 您应该将日志记录与指标监视结合使用，以全面了解环境的运行情况。
• 小心将日志存储超过 30 到 45 天，如果需要，请使用更便宜的资源进行长期存档。
• 限制sidecar模式使用日志转发器，因为它们会利用更多的资源。选择使用守护程序集作为日志转发器，并将日志发送到 STDOUT。

告警

• 警惕疲劳，因为它会导致人和流程中的不良行为。
• 在发出警报时，始终关注渐进式改进，并接受它并不总是完美的。
• 针对影响 SLO 和客户的症状发出警报，而不是针对不需要立即人工关注的暂时性问题。

总结

在本章中，我们讨论了可用于使用指标和日志收集来监视系统的模式、技术和工具。从本章中最重要一点是，您需要重新思考如何执行监视并从一开始就执行监视。太多时候，我们看到这个实现后的事实，它可以让你进入一个非常糟糕的境地，监控就是要更好的了解你的系统。并能够提供更好的恢复能力，从而为您的应用程序提供更好的最终用户体验。监视分布式应用程序和分布式系统（如 Kubernetes）需要大量的工作，因此您必须在您的旅程开始时做好准备。