Kubernetes 最佳实践 （Kubernetes 监控与日志）

作者  Brendan Burns, Eddie Villalba, Dave Strebel and Lachlan Evenson

 

在本章中，我们讨论了在Kubernetes中进行监视和记录的最佳实践。我们将深入探讨各种监视模式，要收集的重要指标以及根据这些原始指标构建仪表板的细节。然后，我们总结一些为Kubernetes集群实施监视的示例。
Metrics Versus Logs

您首先需要了解日志收集和指标收集之间的区别。它们彼此互补，但具有不同的目的。
Metrics
一段时间内测得的一系列数字
Logs
用于系统的探索性分析
当应用程序性能不佳时，需要同时使用指标和日志记录的一个示例。我们对该问题的第一个指示可能是在托管该应用程序的Pod上出现高延迟的警报，但是这些指标可能无法很好地指示该问题。然后，我们可以查看日志以对应用程序发出的错误进行调查。
监控技巧
黑盒监视着重于从应用程序外部进行监视，这是监视系统中的CPU，内存，存储等组件的传统方法。黑盒监视对于在基础架构级别进行监视仍然很有用，但是缺乏对应用程序运行方式的了解和上下文。例如，要测试集群是否健康，我们可以安排一个Pod，如果成功，我们知道调度程序和服务发现在集群中是健康的，因此我们可以假设集群组件是健康的。
白盒监视着眼于应用程序状态上下文中的详细信息，例如HTTP请求总数，500个错误的数量，请求的延迟等等。通过白盒监控，我们可以开始了解我们系统状态的“为什么”。它使我们可以问：“为什么磁盘已满？”而不仅仅是“磁盘已满”。

监控模式
您可能会看着监视说：“这有多难？我们一直在监控我们的系统。”是的，您今天使用的一些典型监控模式也适合您监控Kubernetes的方式。区别在于Kubernetes之类的平台具有更大的动态性和瞬态性，您将需要改变有关如何监视这些环境的想法。例如，在监视虚拟机（VM）时，您希望VM处于24/7状态，并保留其所有状态。在Kubernetes中，Pod可能是非常动态且短暂的，因此您需要在适当的位置进行监视以处理这种动态和短暂的特性。
监视分布式系统时，有两种不同的监视模式需要关注。
由Brendan Gregg推广的USE方法着重于以下方面：

· R—Rate· E—Errors· D—Duration

此方法专注于基础结构监视，因为将其用于应用程序级监视存在局限性。USE方法描述为“对于每种资源，请检查利用率，饱和度和错误率。”此方法使您可以快速确定系统的资源限制和错误率。例如，要检查群集中节点的网络运行状况，您将需要监视利用率，饱和度和错误率，以便能够轻松识别网络堆栈中的任何网络瓶颈或错误。USE方法是较大工具箱中的工具，不是您将用来监视系统的唯一方法。
Tom Willke推广了另一种称为RED方法的监视方法。RED方法的方法集中在以下方面：

·R-Rate·E-Errors·D-Duration

该理念取自Google的四个黄金信号：

· Latency (服务请求需要多长时间)· Traffic (你的系统有多少需求)· Errors (失败请求的速率)· Saturation (你的服务利用率如何)

例如，您可以使用此方法监视在Kubernetes中运行的前端服务，以计算以下内容：
·我的前端服务正在处理多少个请求？
·服务的用户收到多少个500错误？
·服务是否被请求过度使用？
从上一个示例中可以看到，此方法更着重于用户的体验以及他们对服务的体验。鉴于USE方法专注于基础架构组件，而RED方法专注于监视应用程序的最终用户体验，因此USE和RED方法是相互补充的。

Kubernetes指标概述
现在我们知道了不同的监视技术和模式，下面让我们看一下您应该在Kubernetes集群中监视哪些组件。Kubernetes集群由控制平面组件和工作节点组件组成。控制平面组件包括API服务器，etcd，调度程序和控制器管理器。工作程序节点由kubelet，容器运行时，kube-proxy，kube-dns和pod组成。您需要监视所有这些组件，以确保群集和应用程序正常运行。
Kubernetes以多种方式公开这些指标，因此让我们看一下可用于在集群中收集指标的不同组件。
cAdvisor
Container Advisor或cAdvisor是一个开源项目，它为节点上运行的容器收集资源和指标。cAdvisor内置在Kubernetes kubelet中，该kubelet在集群中的每个节点上运行。它通过Linux控制组（cgroup）树收集内存和CPU指标。如果您不熟悉cgroup，则它是Linux内核功能，可隔离CPU，磁盘I / O或网络I / O的资源。cAdvisor还将通过内置在Linux内核中的statfs收集磁盘指标。这些是您无需真正担心的实施细节，但是您应该了解这些指标的显示方式以及可以收集的信息类型。您应该将cAdvisor视为所有容器指标的真实来源。
Metrics Server
Kubernetes指标服务器和Metrics Server API替代了已弃用的Heapster。Heapster在实现数据接收器方面存在一些体系结构方面的劣势，这导致了Heapster核心代码库中的许多供应商解决方案。通过在Kubernetes中实现资源和自定义指标API作为聚合API来解决此问题。这允许在不更改API的情况下切换实现。
在Metrics Server API和Metrics服务器中需要了解两个方面。
首先，Resource Metrics API的规范实现是指标服务器。指标服务器收集诸如CPU和内存之类的资源指标。它从kubelet的API收集这些指标，然后将它们存储在内存中。Kubernetes在调度程序，Horizontal Pod Autoscaler（HPA）和Vertical Pod Autoscaler（VPA）中使用这些资源指标。
其次，自定义指标API允许监视系统收集任意指标。这允许监视解决方案构建自定义适配器，从而允许扩展到核心资源指标之外。例如，Prometheus构建了第一个自定义指标适配器，它使您可以基于自定义指标使用HPA。这将根据您的用例提供更好的扩展能力，因为现在您可以引入基于Kubernetes外部指标的队列大小和规模之类的指标。
现在有了一个标准化的Metrics API，这为在普通的旧CPU和内存指标之外扩展提供了许多可能性。
kube-state-metrics
kube-state-metrics是一个Kubernetes插件，用于监视存储在Kubernetes中的对象。在使用cAdvisor和指标服务器提供有关资源使用情况的详细指标的情况下，kube-state-metrics专注于识别部署到集群的Kubernetes对象的条件。
以下是kube-state-metrics可以为您解答的一些问题：
pods
•集群中部署了多少个Pod？
•有多少个pods处于挂起状态？
•是否有足够的资源来满足Pod的请求？
Deployments
•有多少个Pod处于运行状态而不是所需状态？
•有多少个副本可用？
•已更新哪些部署？
Nodes
•我的工作节点的状态是什么？
•我的群集中可分配的CPU内核是什么？
•是否有不可计划的节点？
Jobs
•什么时候开始工作？
•工作何时完成？
•有多少工作失败了？
在撰写本文时，kube-state-metrics跟踪了22种对象类型。这些总是在扩展，您可以在Github存储库中找到文档。

我要监视哪些指标？
一个简单的答案是“一切”，但是如果您尝试监视太多，则会产生过多的噪声，从而滤除您需要深入洞察的真实信号。当我们考虑在Kubernetes中进行监视时，我们想采取一种考虑以下因素的分层方法：
·物理或虚拟节点
·群集组件
·群集附件
·最终用户应用程序
使用这种分层的监视方法，您可以更轻松地在监视系统中识别正确的信号。它使您可以使用更有针对性的方法来解决问题。例如，如果您的Pod处于挂起状态，则可以从节点的资源利用率开始，如果一切正常，则可以定位集群级组件。
以下是您要在系统中定位的指标：
·节点
•CPU利用率
•内存利用率
•网络利用率
•磁盘利用率
·群集组件
•etcd延迟
·群集附件
•群集自动缩放器
•入口控制器
·应用
•容器内存利用率和饱和度
•容器CPU利用率
•容器网络利用率和错误率
•特定于应用程序框架的指标
监控工具
有许多可与Kubernetes集成的监控工具，并且每天都有更多的监控工具，这些工具基于它们的功能集可以更好地与Kubernetes集成。以下是一些与Kubernetes集成的流行工具：
Prometheus
Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包。自2012年成立以来，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。现在，它是一个独立的开源项目，并且独立于任何公司进行维护。为了强调这一点并阐明项目的治理结构，Prometheus加入了Cloud Native，2016年，计算基金会（CNCF）是继Kubernetes之后的第二个托管项目。
InfluxDB
InfluxDB是一个时序数据库，旨在处理较高的写入和查询负载。它是TICK（Telegraf，InfluxDB，Chronograf和Kapacitor）堆栈的组成部分。InfluxDB旨在用作涉及大量时间戳数据的任何用例的后备存储，包括DevOps监控，应用程序指标，IoT传感器数据和实时分析。
Datadog
Datadog为云级应用程序提供监视服务，通过基于SaaS的数据分析平台监视服务器，数据库，工具和服务。
Sysdig
Sysdig Monitor是一个商业工具，可为容器本机应用程序提供Docker监视和Kubernetes监视。Sysdig还允许您通过直接Kubernetes集成来收集，关联和查询Prometheus指标。
Cloud provider tools
GCP Stackdriver
Stackdriver Kubernetes Engine监视旨在监视Google KubernetesEngine（GKE）群集。它一起管理监视和日志记录服务，并具有一个界面，该界面提供了针对GKE集群定制的仪表板。Stackdriver Monitoring提供了对基于云的应用程序的性能，正常运行时间和整体运行状况的可见性。它从Google Cloud Platform（GCP），Amazon Web Services（AWS），托管正常运行时间探测和应用程序工具收集指标，事件和元数据。
Microsoft Azure Monitor for containers
用于容器的Azure Monitor是一项功能，旨在监视部署到Azure容器实例或托管在Azure Kubernetes Service上的托管Kubernetes群集的容器工作负载的性能。监视容器至关重要，尤其是在使用多个应用程序大规模运行生产集群时。通过容器的Azure Monitor，可以通过Metrics API从Kubernetes中可用的控制器，节点和容器收集内存和处理器指标，从而使您可以查看性能。还将收集容器日志。从Kubernetes群集启用监视后，将通过适用于Linux的Log Analytics代理的容器化版本为您自动收集指标和日志。
AWS Container Insights
如果您在Amazon EC2上使用Amazon ElasticContainer Service（ECS），AmazonElastic Kubernetes Service或其他Kubernetes平台，则可以使用CloudWatch Container Insights从容器化的应用程序和微服务中收集，汇总和汇总指标和日志。这些指标包括对CPU，内存，磁盘和网络等资源的利用率。Container Insights还提供诊断信息，例如容器重新启动失败，以帮助您隔离问题并快速解决问题。
在考虑实施监视指标的工具时，一个重要方面是查看指标的存储方式。提供具有键/值对的时间序列数据库的工具

使用Prometheus监控Kubernetes
在本节中，我们重点介绍通过Prometheus监控指标，该指标与Kubernetes标签，服务发现和元数据提供了良好的集成。我们在本章中贯彻的高级概念也将适用于其他监视系统。
Prometheus是由CNCF托管的开源项目。它最初是由SoundCloud开发的，其许多概念都基于Google的内部监控系统BorgMon。它使用键对实现了多维数据模型，该键对的工作方式与Kubernetes标签系统的工作方式非常相似。Prometheus以人类可读的格式公开指标，如以下示例所示：
＃HELP node_cpu_seconds_total每种模式下CPU花费的秒数。
＃TYPE node_cpu_seconds_total计数器

node_cpu_seconds_total {cpu ="0"，mode ="idle"}5144.64node_cpu_seconds_total {cpu ="0"，mode ="iowait"}117.98

 

为了收集度量标准，Prometheus使用拉模型，在该模型中，它会刮取度量标准端点以收集度量并将其吸收到Prometheus服务器中。像Kubernetes这样的系统已经以Prometheus格式公开了它们的指标，从而使收集指标变得简单。许多其他Kubernetes生态系统项目（NGINX，Traefik，Istio，LinkerD等）
还以Prometheus格式公开其指标。Prometheus还可以使用导出器，该导出器允许您从服务中获取发出的指标并将其转换为Prometheus格式的指标。
Prometheus的架构非常简化，如图3-1所示。

 

 

图3-1。普罗米修斯架构
Tip
您可以在群集内或群集外安装Prometheus。最好从“实用程序群集”监视群集，以避免生产问题也影响监视系统。有诸如Thanos之类的工具可为Prometheus提供高可用性，并允许您将指标导出到外部存储系统。
对Prometheus体系结构的深入探讨超出了本书的范围，您应该参考另一本专门的书在这个主题。Prometheus：Up＆Running（O’Reilly）是一本很好的入门书籍。
因此，让我们深入研究并在我们的Kubernetes集群上设置Prometheus。有许多不同的方法来执行此操作，并且部署将取决于您的特定实现。在本章中，我们将安装Prometheus Operator：
Prometheus Server
拉并存储从系统收集的指标。
Prometheus Operator
使Prometheus配置Kubernetes本地化，并管理和操作Prometheus和Alertmanager集群。允许您通过本机Kubernetes资源定义创建，销毁和配置Prometheus资源。
Node Exporter
从集群中的Kubernetes节点导出主机指标。
kube--statestate--metrics指标
收集特定于Kubernetes的指标。
Alertmanager
允许您配置警报并将警报转发到外部系统。
Grafana
提供Prometheus仪表板功能的可视化。

helm install --name prom stable/prometheus-operator

安装operator后，应该会看到以下pods已部署到群集：
 

$ kubectl get pods -n monitoringNAME READY STATUS RESTARTS AGEalertmanager-main-0 2/2 Running 0 5h39malertmanager-main-1 2/2 Running 0 5h39malertmanager-main-2 2/2 Running 0 5h38mgrafana-5d8f767-ct2ws 1/1 Running 0 5h39mkube-state-metrics-7fb8b47448-k6j6g 4/4 Running 0 5h39mnode-exporter-5zk6k 2/2 Running 0 5h39mnode-exporter-874ss 2/2 Running 0 5h39mnode-exporter-9mtgd 2/2 Running 0 5h39mnode-exporter-w6xwt 2/2 Running 0 5h39mprometheus-adapter-66fc7797fd-ddgk5 1/1 Running 0 5h39mprometheus-k8s-0 3/3 Running 1 5h39mprometheus-k8s-1 3/3 Running 1 5h39mprometheus-operator-7cb68545c6-gm84j 1/1 Running 0 5h39m

 

让我们看一下Prometheus Server，以了解如何运行一些查询来检索Kubernetes指标：
kubectl port-forward svc/prom-prometheus-operator-prometheus 9090

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

 

图3-2显示了您是否成功将Prometheus部署到群集上的屏幕。
现在我们已经部署了Prometheus，让我们通过PrometheusPromQL查询语言探索一些Kubernetes指标。有可用的PromQL基础指南。
我们在本章前面的内容中谈到了使用USE方法，因此让我们收集一些有关CPU利用率和饱和度的节点指标。

 

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

avg(rate(node_cpu_seconds_total[5m]))

这将返回整个群集的平均CPU利用率。
如果要获取每个节点的CPU利用率，可以编写如下查询：

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

这将返回群集中每个节点的平均CPU利用率。
因此，既然您已经具备在Prometheus中运行查询的经验，让我们看一下Grafana如何帮助我们为要跟踪的这些常见USE方法指标构建仪表板可视化。关于您安装的Prometheus Operator的妙处在于，它带有一些可以使用的预先构建的Grafana仪表板。
现在，您需要创建一个通往Grafana pod的端口转发隧道，以便可以从本地计算机访问它：
 

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

 

 

现在，将您的Web浏览器指向

http://localhost:3000

并使用以下凭据登录：
· Username: admin
· Password: admin
在Grafana仪表板下，您会找到一个名为Kubernetes / USE Method / Cluster的仪表板。该仪表板为您很好地概述了Kubernetes集群的利用率和饱和度，这是USE方法的核心。图3-3给出了一个仪表板示例。
图3-3。Grafana仪表板

 

 

 

继续并花一些时间来探索可在Grafana中可视化的不同仪表板和指标。
TIP
避免创建过多的仪表板（又称“图形墙”），因为工程师在故障排除情况下可能难以推理。您可能会认为，在仪表板中拥有更多信息意味着更好的监视，但是在大多数情况下，它会使查看仪表板的用户更加困惑。将仪表板设计重点放在结果和解决时间上。
记录概述
到目前为止，我们已经讨论了很多有关指标和Kubernetes的内容，但是要全面了解您的环境，您还需要从Kubernetes群集和部署到您的群集的应用程序中收集和集中日志。
使用日志记录时，可能很容易地说“让我们记录所有内容”，但这会导致两个问题：
·噪音太大，无法快速发现问题。
·日志会消耗大量资源，并且成本很高。
对于确切应该记录的内容，没有明确的答案，因为调试日志会成为必然的危害。随着时间的流逝，您将开始更好地了解您的环境，并了解可以从日志记录系统中消除哪些噪声。另外，要解决存储的日志数量不断增长的问题，您将需要实施保留和归档策略。从最终用户的经验来看，拥有30到45天之间的历史日志非常适合。这样可以调查出现在较长时间段内的问题，但同时也减少了存储日志所需的资源量。如果出于法规遵从性原因需要长期存储，则需要将日志归档到更具成本效益的资源中。

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

· Node logs· Kubernetes control-plane logs• API server• Controller manager• Scheduler· Kubernetes audit logs· Application container logs

 

使用节点日志，您想收集发生在基本节点服务上的事件。例如，您将要从运行在工作节点上的Docker守护程序收集日志。健康的Docker守护程序对于在工作节点上运行容器至关重要。收集这些日志将帮助您诊断Docker守护程序可能遇到的任何问题，并为您提供有关该守护程序的任何潜在问题的信息。您还需要从基础节点登录其他基本服务。
Kubernetes控制平面由几个组件组成，您需要从中收集日志，以便您更深入地了解潜在问题
在它里面。Kubernetes控制平面是运行状况良好的群集的核心，您将希望将其存储在主机上的日志聚合到/var/log/kube-APIserver.log、/var/log/kube-scheduler.log和/var/log/kube-controller-manager.log。控制器管理器负责创建最终用户定义的对象。例如，以用户身份创建一个类型为LoadBalancer的Kubernetes服务，该服务只是处于挂起状态；Kubernetes事件可能无法提供诊断问题的所有详细信息。如果您在集中式系统中收集日志，它将为您提供更多有关潜在问题的详细信息，并为调查该问题提供了更快的方法。
您可以将Kubernetes审核日志视为安全监视，因为它们使您可以了解谁在系统中执行了哪些操作。这些日志可能非常嘈杂，因此您需要针对环境进行调整。在许多情况下，这些日志在首次初始化时可能会导致日志系统中的峰值，因此请确保遵循有关审计日志监视的Kubernetes文档指南。
应用程序容器日志使您可以深入了解应用程序发出的实际日志。您可以通过多种方式将这些日志转发到中央存储库。第一种推荐的方法是将所有应用程序日志发送到STDOUT，因为这为您提供了统一的应用程序日志记录方式，并且监视守护程序集可以收集日志
直接从Docker守护程序。另一种方法是使用Sidecar模式，并在Kubernetes容器中的应用程序容器旁边运行日志转发容器。如果您的应用程序登录到文件系统，则可能需要使用此模式。
注意
有许多用于管理Kubernetes审核日志的选项和配置。这些审核日志可能非常嘈杂，并且记录所有操作的成本可能很高。您应该考虑查看审核日志记录文档，以便可以针对您的环境微调这些日志。
记录工具
就像收集指标一样，有许多工具可以从Kubernetes和集群中运行的应用程序收集日志。您可能已经拥有用于此目的的工具，但是请注意该工具如何实现日志记录。该工具应具有作为Kubernetes DaemonSet运行的能力，还应具有作为不向STDOUT发送日志的应用程序的辅助工具运行的解决方案。使用现有工具可能是有利的，因为您已经对该工具有很多操作知识。
与Kubernetes集成的一些更流行的工具是：

· Elastic Stack· Datadog· Sumo Logic· Sysdig· Cloud provider services (GCP Stackdriver, Azure Monitorfor containers, and Amazon CloudWatch)

 

在寻找一种用于集中日志的工具时，托管解决方案可以提供很多价值，因为它们可以分担很多运营成本。在第N天，托管您自己的日志记录解决方案似乎很棒，但是随着环境的发展，维护该解决方案可能会非常耗时。
使用EFK堆栈进行记录
出于本书的目的，我们使用Elasticsearch，Fluentd和Kibana（EFK）堆栈为集群设置监控。实施EFK堆栈可能是入门的好方法，但有时您可能会问自己：“管理我自己的日志记录平台真的值得吗？”通常情况下，这不值得付出努力，因为自托管日志记录解决方案在第一天就很出色，但是到365天，它们变得过于复杂。随着环境的扩展，自托管日志记录解决方案在操作上变得更加复杂。没有一个正确的答案，因此请评估您的业务需求是否需要您托管自己的解决方案。
还有许多基于EFK堆栈的托管解决方案，因此，如果您选择不自己托管它，则始终可以轻松移动。
您将为监视堆栈部署以下内容：
·Elasticsearch运算符
·Fluentd（将日志从我们的Kubernetes环境转发到Elasticsearch）
·Kibana（可视化工具，用于搜索，查看和与Elasticsearch中存储的日志进行交互）
将清单部署到您的Kubernetes 集群

 

kubectl get pods -n logging​efk-kibana-854786485-knhl5 1/1 Running 0 4melasticsearch-operator-5647dc6cb-tc2st 1/1 Running 0 5melasticsearch-operator-sysctl-ktvk9 1/1 Running 0 5melasticsearch-operator-sysctl-lf2zs 1/1 Running 0 5melasticsearch-operator-sysctl-r8qhb 1/1 Running 0 5mes-client-efk-cluster-9f4cc859-sdrsl 1/1 Running 0 4mes-data-efk-cluster-default-0 1/1 Running 0 4mes-master-efk-cluster-default-0 1/1 Running 0 4mfluent-bit-4kxdl 1/1 Running 0 4mfluent-bit-tmqjb 1/1 Running 0 4mfluent-bit-w6fs5 1/1 Running 0

 

在所有Pod都“运行”之后，让我们继续，并通过端口转发到我们的本地主机连接到Kibana：

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

 

现在，将您的Web浏览器指向http：// localhost：5601以打开Kibana仪表板。
要与从我们的Kubernetes集群转发的日志进行交互，您首先需要创建一个索引。
首次启动Kibana时，将需要导航到“管理”选项卡，并为Kubernetes日志创建索引模式。系统将指导您完成所需的步骤。
创建索引后，可以使用Lucene查询语法搜索日志，例如：

log:(WARN|INFO|ERROR|FATAL)

这将返回包含警告，信息，错误或致命字段的所有日志。您可以在图3-4中看到一个示例。

 

图3-4。Kibana仪表板

 

在Kibana中，您可以对日志执行临时查询，还可以构建仪表板以概述环境。
继续并花一些时间来探索可以在Kibana中可视化的不同日志。
Alerting
警报是一把双刃剑，您需要在警报内容和应该监视的内容之间取得平衡。发出过多警报会引起警报疲劳，并且所有噪音都将丢失重要事件。一个示例是在Pod发生故障时随时生成警报。您可能会问：“我为什么不希望监视pod故障？”好吧，Kubernetes的优点在于它提供了自动检查容器运行状况并自动重启容器的功能。您真的想将警报重点放在影响您的服务水平目标（SLO）的事件上。SLO是您可以与服务的最终用户达成一致的特定可测量特征，例如可用性，吞吐量，频率和响应时间。设置SLO可以设置最终用户的期望值，并可以清晰地说明系统的行为方式。没有SLO，用户可以形成他们的意见，这可能是对该服务的不切实际的期望。在像Kubernetes这样的系统中发出警报需要一种不同于我们通常习惯的全新方法，并且需要关注最终用户如何体验该服务。例如，如果您的前端服务的SLO响应时间为20毫秒，并且看到的延迟高于平均水平，那么您希望收到有关此问题的警报。
您需要确定哪些警报是好的，并需要干预。在典型的监视中，您可能习惯于警告CPU使用率高，内存使用率高或进程没有响应。这些看似警报良好，但可能并不表示有人需要立即采取行动并需要通知值班工程师。向应召唤的工程师发出警报应该是需要立即引起人工关注并影响应用程序用户体验的问题。如果您曾经遇到过“该问题已自行解决”的情况，那么这很好地表明了该警报不需要联系值班工程师。
处理不需要立即采取措施的警报的一种方法是集中精力自动修复原因。例如，当磁盘已满时，您可以自动删除日志以释放磁盘上的空间。此外，在应用程序部署中使用Kubernetes活跃度探针可以帮助自动修复应用程序中未响应的流程问题。
建立警报时，还需要考虑警报阈值。如果您将阈值设置得太短，则警报可能会导致很多误报。通常建议将阈值设置为至少五分钟，以帮助消除误报。提出标准阈值可以帮助定义标准，并避免微观管理
不同的阈值。例如，您可能要遵循5分钟，10分钟，30分钟，1小时等的特定模式。
在为警报构建通知时，您要确保在通知中提供相关信息，例如，提供指向“剧本”的链接，该手册提供了疑难解答或其他有关解决问题的有用信息。您还应该在通知中包括有关数据中心，区域，应用程序所有者和受影响的系统的信息。提供所有这些信息将使工程师能够快速确定有关该问题的理论。
您还需要构建通知渠道以路由已触发的警报。在考虑“触发警报时应通知谁？”您应该确保不仅将通知发送到通讯组列表或团队电子邮件中。如果将警报发送给较大的组，则往往会由于将它们视为噪音而最终被过滤掉。您应该将通知路由给将对此问题负责的用户。
有了警报，您就不会在第一天就做到完美，而我们可以说它可能永远都不是完美的。您只想确保逐渐改进警报，以防止警报疲劳，这可能会导致人员倦怠和您的系统出现许多问题。
要进一步了解如何在系统上管理警报，请阅读Rob Ewaschuk撰写的“My Philosophy on Alerting”，该书基于Rob在Google担任站点可靠性工程师（SRE）的观察。
监视，记录和警报的最佳做法
以下是有关监视，日志记录和警报的最佳实践。
Monitoring

·监视节点和所有Kubernetes组件的利用率，饱和度和错误率，并监视应用程序的速率，错误和持续时间。
·使用黑盒监视来监视症状而不是预测系统的运行状况。
·使用白盒监视来通过仪器检查系统及其内部。
·实施基于时间序列的指标以获取高精度指标，这些指标还使您能够深入了解应用程序的行为。
·利用Prometheus之类的监控系统，这些系统可以为高维提供关键标签；这将更好地指示问题的症状。
·使用平均指标可基于事实数据可视化小计和指标。利用总和指标来可视化特定指标的分布。
Logging

·您应该将日志记录与指标监视结合使用，以全面了解您的环境如何运行。
·请谨慎保存日志30至45天以上，如果需要，请使用更便宜的资源进行长期归档。
·限制日志转发器以sidecar模式使用，因为它们将使用更多资源。选择对日志转发器使用DaemonSet并将日志发送到STDOUT。
Alerting

·注意警报疲劳，因为它可能导致人员和流程中的不良行为。
·始终注意在警报发生时逐步改进，并接受它并不总是完美的。
·警告会影响您的SLO和客户的症状，而不是那些不需要人为关注的暂时性问题。
摘要
在本章中，我们讨论了可用于通过度量标准和日志收集监视系统的模式，技术和工具。本章最重要的部分是您需要重新考虑如何执行监视并从一开始就进行监视。我们太多次看到这一事实是在事实之后实现的，它可能使您在理解系统方面陷入困境。监视就是要更好地了解系统并提供更好的弹性，从而为您的应用程序提供更好的最终用户体验。监视分布式应用程序和诸如Kubernetes之类的分布式系统需要进行大量工作，因此您必须在旅途开始时就做好准备。

 

我的公众号二维码，欢迎关注。