ETCD 关键监控指标

Etcd 是一种分布式键值数据存储，为分布式应用程序提供高可用、持久的存储。在 Kubernetes 中，etcd 充当控制平面的一部分，将有关资源的实际和期望状态的数据存储在集群中。Kubernetes controller 使用 etcd 的数据来调谐集群的实际状态与其所需状态。

本系列重点关注 Kubernetes 中的 etcd 监控。在本文后面，我们将向您展示应监控的关键指标，以确保 etcd 有效支持 Kubernetes 集群的运行状况和性能。但首先，我们将探讨 etcd 如何提供高可用的数据存储以及 Kubernetes 如何使用该数据来管理集群的状态。

etcd 的工作原理

在本节中，我们将了解 etcd 如何存储和管理 Kubernetes 集群的状态数据，以及它如何提供高可用性和数据一致性。

etcd 中的 Kubernetes 集群数据

etcd 中存储的每个对象都将 Kubernetes 资源定义为键值对的集合。默认情况下，每个 etcd 对象都有一个以 /registry 开头的键名。该键还包括资源的类型、命名空间和名称。作为示例，请考虑default命名空间中名为 <POD_NAME> 的 pod。定义 pod 的 etcd 对象将使用键名 /registry/pods/default/<POD_NAME> 。该对象的值将包含描述 Pod 的数据，包括其名称、容器镜像以及资源请求和限制。

Kubernetes API 服务器 - kube-apiserver 充当 etcd 的客户端。当 API Server 接收来自其自己的客户端的请求时，它通过向 etcd 的 API 发送 gRPC 请求来代表客户端读取和写入集群状态信息。例如，当 kube-scheduler 需要将工作负载分配给节点，它可以通过将更改传达给 kube-apiserver 来更新集群的所需状态，然后 kube-apiserver 向 etcd 发送写入请求。其他 Kubernetes 组件通过 kube-apiserver 与 etcd 交互，包括 kube-controller-manager、cloud controller manager 和 kubelet。

Etcd 使用多版本并发控制 (MVCC) 来提供对集群状态历史记录的可见性。当 etcd 创建、更新或删除对象时，它首先提交更改，将新版本的数据写入磁盘的预写日志 (WAL) 中。接下来，它应用更改，将其保存到键值存储并增加修订版本（所有已发生更改的计数器）。

通过记录数据存储的修订以及所有版本中每个键的值，etcd 维护历史记录，使 kube-apiserver 能够读取集群状态的先前版本。这样一来，kube-apiserver 可以知道 etcd 中存储的对象发生了变化，并及时通知其他组件。比如 kube-scheduler 是 kube-apiserver 的客户端，如果 etcd 中的 desired state 发生变化，kube-apiserver 会及时通知 kube-scheduler。各类 Controller 也是依赖 kube-apiserver 来监视 etcd 的数据，以便知道何时需要采取行动。比如 node controller 可以创建一个监视来检测并驱逐已变得无响应的节点。Etcd 通过 gRPC 流向 kube-apiserver 发送事件以通知其这些更改，然后 kube-apiserver 通知 controller。

高可用性和数据一致性

为了提供高可用性，etcd 被设计为在三个或更多冗余节点的集群中运行，每个节点都有键值存储的本地副本。在集群中，即使某些成员不可用，etcd 也可以继续运行。例如，由于节点故障、网络分区、网络故障导致某些节点无法加入集群。

集群大小决定了它的容错能力，因为它只需要大多数节点即可继续运行。具有奇数个节点的集群提供最佳的容错能力。五个节点的集群最多可能会丢失两个节点。 Kubernetes 建议将集群状态数据存储在五节点 etcd 集群中，这样可以容忍两个节点的丢失。较大的 etcd 集群性能不佳，因为它们需要跨更多节点复制数据。因此，etcd 建议最大集群大小为 7 个节点。

虽然将数据分布在多个节点上可以为 etcd 提供高可用性，但它需要一种方法来管理数据一致性，以便查询任何节点都会得到相同的结果。 Etcd使用Raft共识算法来同步集群中所有节点上的数据。 Raft 使节点能够选举一个领导者，该领导者处理所有写入或更新数据的请求。所有其他节点都是追随者，它们在必要时将请求转发给领导者以确保一致性。

领导者每 100 毫秒（默认）向所有追随者发送一条心跳消息，以确认其领导者状态。如果追随者在选举超时（默认为 1000 毫秒）内没有收到心跳，则认为集群已失去领导权。例如，如果领导者发生故障或网络分区中断了心跳流，则可能会发生这种情况。然后追随者可以提名自己，发起新的选举。

当领导者收到来自客户端或从追随者转发的写入请求时，它将提议的更改提交到其 WAL，然后将其作为提案发送给所有追随者。追随者将提案提交给他们的 WAL 并向领导者发送确认。一旦大多数追随者确认，领导者就会应用更改，更新其键值存储的副本以反映更改。然后，领导者通知追随者将更改应用到键值存储的本地副本。

默认情况下，etcd 保证它将使用最新值响应每个读取请求，无论哪个节点为该请求提供服务。如果追随者收到读取请求，但它有尚未应用的挂起更改，则会将请求转发给领导者以确保客户端将收到最新数据。不过，这会引入延迟，并且您可以选择配置 etcd 的一致性模式，以使在这种情况下的关注者能够用陈旧的数据进行响应。

关键 etcd 监控指标

到目前为止，在这篇文章中，我们已经了解了 Kubernetes 如何在 etcd 中存储数据以及 etcd 如何提供高可用性和数据一致性。在本节中，我们将了解您可以监控的指标，以确保 etcd 集群的运行状况和性能。我们将探讨以下类别的指标：

• Resource metrics
• Watch metrics
• Raft metrics
• Kubernetes metrics

Resource metrics

etcd 集群中的每个节点都使用其本地资源来运行 etcd 进程；接收、转发和响应请求；并维护键值存储的副本。本节中描述的指标可以让您了解各个节点的运行状况，并可以帮助您将 etcd 集群的资源使用情况与 Kubernetes 集群的性能相关联。

进程相关的指标：

• process_open_fds、process_max_fds 进程打开的文件描述符数量和最大文件描述符数量，比如告警规则： process_open_fds / process_max_fds > 0.8 表示 fd 使用率超过 80%。
• process_resident_memory_bytes 进程驻留内存大小，显然，在触发 OOM 之前提前发现内存问题是很重要的。所以这个指标也值得创建告警规则。

Etcd文档 提供了基线性能数据，显示您期望 etcd 服务器处理的查询速率。如果集群的性能与这些数字不符，则磁盘性能可能是根本原因。

如果 etcd 将数据写入磁盘的时间比预期长，可能会降低 Kubernetes 集群的性能并减慢应用程序的速度。使用高性能磁盘可以最大程度地减少延迟，使用以下指标来了解磁盘延时问题，特别是在运行大型且繁忙的 Kubernetes 集群时。

• etcd_disk_backend_commit_duration_seconds etcd 将最近的更改保存到磁盘所需的时间（以秒为单位），比如最近 5 分钟增长了 25% 就要关注下。
• etcd_disk_wal_fsync_duration_seconds etcd 将预写日志 (WAL) 中存在的 pending changes 持久保存到磁盘所需的时间（以秒为单位）。比如最近 5 分钟增长了 50% 就要关注下。
• etcd_mvcc_db_total_size_in_bytes etcd 数据库的大小（以字节为单位），默认情况下，etcd 最多可以存储 2 GiB 的数据。该最大值是可配置的，但 etcd 建议将最大大小设置为不超过 8 GiB。如果达到最大大小，etcd 将不再接受任何写入，并且 Kubernetes 无法执行集群管理任务，例如调度新的 pod。您应该创建一个监视器来通知您数据库是否使用了其配置的最大存储的 80% 以上。这将为您提供足够的时间在空间耗尽之前修复问题，例如，通过压缩etcd 和碎片整理或修改 kube-apiserver 的自动压缩间隔（默认值为五分钟）。

Etcd 依赖于健康的网络来与 kube-apiserver 以及 etcd 集群节点之间进行高效通信。如果您的应用程序延迟增加，本节中的指标可以帮助您确定网络性能的根本原因。

• etcd_network_peer_round_trip_time_seconds 请求在两个 etcd 节点之间往返所需的时间，以秒为单位
• grpc_server_handled_total 服务器处理的 gRPC 请求总数

etcd_network_peer_round_trip_time_seconds

Raft 协议要求 etcd 节点相互通信，以保持数据一致性——例如，当领导者向追随者转发提案时。影响网络任何部分的往返时间的增加可能会降低 Kubernetes 的性能。您应该设置一个监视器，以便在五分钟内往返时间增加超过 15% 时通知您。这样的增加可能会导致较高的提交延迟，因此您应该排查并解决任何网络级问题，以避免降低集群的性能。

grpc_server_handled_total

该指标计算 etcd 已完成的 gRPC 请求数，无论结果如何。您可以将其分解以显示 gRPC 方法和请求的服务，例如，查看有多少次调用将发送至 etcd 的watch和kv API。您还可以根据 gRPC 调用产生的状态代码来分析 etcd 的活动，例如，通过过滤DeadlineExceeded结果来查看调用是否超时或PermissionDenied结果来识别潜在的安全问题。

您可以跨集群中的节点比较此指标，以了解流向每个节点的请求流量的相对量。如果任何单个节点显示处理的请求量下降，您应该调查相关网段并查看节点级指标以检查 CPU、内存或网络限制。您可以将其与 grpc_server_started_total 进行比较——它计算 etcd 开始处理的 gRPC 请求的数量（即使它没有完成）——以查看未完成的请求的比例。如果节点无法处理请求，您应该在其 gRPC 日志中查找错误。

Watch metrics

Kubernetes API 服务器使用 etcd API 建立 Watch，发现有对象更改的时候，就要即使通知相关组件，比如要暴露一个 Service 或者替换一个失败的 Pod。监控这些指标可以帮助您确保 kube-apiserver 的监视功能正常，使控制器能够将集群保持在所需的状态。

• etcd_debugging_store_watchers 监视 etcd 数据变化的查询数量
• etcd_debugging_mvcc_slow_watcher_total 不同步的观察者数量

etcd_debugging_store_watchers

Etcd 应该自动平衡监视，以便在集群节点之间按比例分配它们。连接严重不平衡可能是由过时的 gRPC 客户端或服务器版本引起的。

etcd_debugging_mvcc_slow_watcher_total

当 kube-apiserver 无法像 etcd 流式传输事件一样快地消费事件（即更新其正在监视的数据）时，该值将会增加。这可能是由网络延迟或控制平面节点上的资源争用引起的，这可能会阻止 kube-apiserver 足够快地消耗事件以与服务器保持同步。

Raft metrics

Etcd使用Raft共识算法来确保集群中所有节点的数据一致。本节中描述的指标可以帮助您了解集群的共识是否健康或存在风险。

• etcd_server_leader_changes_seen_total etcd 集群领导层发生变化的次数
• etcd_server_proposals_failed_total 未能获得多数节点确认的提案数量
• etcd_server_proposals_committed_total, etcd_server_proposals_applied_total 节点成功提交和应用更改的次数

etcd_server_leader_changes_seen_total

由于领导节点故障或网络延迟导致追随者无法在配置的超时时间内接收心跳，集群领导地位可能随时发生变化。当选举新的领导者时，集群无法添加或更新数据，因此您的应用程序可能会遇到延迟增加的情况。

您应该警惕领导层持续高频率的变动，例如一小时内超过 100 次。这可能是由于网络吞吐量不足造成的。这也可能是由于 etcd 节点上的资源限制（如果 etcd 集群太繁忙，可能会导致领导者失败），因此您可能需要扩展 etcd 节点。

etcd_server_proposals_failed_total

当 etcd 领导者提议对数据进行更改并且该提议未得到大多数节点的确认时，该提议将失败。该指标跟踪这种情况发生的次数。由于领导者选举，失败的提案可能会偶尔发生，但如果您看到此指标持续增加，则可能表明存在导致集群失去法定人数的网络问题。

etcd_server_proposals_applied_total

当法定​​人数同意提案时，所有节点都会将更改提交到其 WAL，然后将更改应用到键值存储的本地副本。如果一个节点是健康的，它将显示提交的提案数量和应用的提案数量之间只有很小的差异。如果您发现这两个指标的比率持续下降，则意味着节点应用更改的速度不够快，这可能是由于CPU 或磁盘 I/O 资源不足造成的。如果问题与主机上的 CPU 使用率增加相关，您可以通过扩展节点来提供更多资源。

您还应该寻找 etcd_disk_backend_commit_duration_seconds 指标的相关增加，以确定磁盘性能是否是一个因素。您可以通过升级到更快的磁盘和节点仅用于 etcd 存储的专用磁盘来缓解这一问题。

Kubernetes metrics

Kubernetes 提供了一些描述 etcd 性能的指标。尽管它们仍处于 alpha 阶段，但这些指标可以为您提供额外的视角来帮助您了解 etcd 性能。在本节中，我们将了解如何使用这些指标之一来查看 etcd 是否是影响 Kubernetes 集群或应用程序的错误或延迟的根源。

etcd_request_duration_seconds

该指标含义是 etcd 客户端收到请求所花费的时间。当 kube-apiserver 发送请求读取 Kubernetes 集群所需的状态时，它必须等待 etcd 的响应。此操作中的任何延迟都会影响依赖 kube-apiserver 获取用于管理集群状态的数据的控制器。

您可以监控 etcd_request_duration_seconds 来跟踪 etcd 响应不同类型请求的速度，包括create 、 update 、 get和list 。如果您发现 etcd 的响应时间增加，您应该尝试将其与 etcd 性能相关联：所有这些请求类型都可能受到 etcd网络和磁盘性能的影响。但您也应该单独跟踪不同的请求类型。 list操作可能变得特别低效，并且您可以通过实现通知者模式而不是依赖list请求来优化 etcd 的性能。

总结

在本文中，我们了解了 etcd 如何存储和管理 Kubernetes 集群的状态数据，以及它如何提供高可用性和数据一致性。我们还了解了应监控的关键指标，以确保 etcd 有效支持 Kubernetes 集群的运行状况和性能。通过监控 etcd 的资源、监视和 Raft 指标，您可以了解 etcd 集群的运行状况，并及时发现潜在的问题。这将有助于您确保 etcd 集群的稳定性和可靠性，从而提高 Kubernetes 集群的性能和可用性。

原文地址：https://www.datadoghq.com/blog/etcd-key-metrics/