监控 Nomad

Nomad 客户端和服务器代理会收集各种运行时指标。这些指标对于监控 Nomad 集群的健康状况和性能非常有用。仔细监控可以发现趋势，避免问题发生，并在问题出现时帮助调试。

所有 Nomad 代理，包括服务器和客户端，都会报告基本的系统和 Go 运行时指标。

Nomad 服务器会报告许多指标，但有些指标仅特定于 Leader 服务器。由于领导权可能随时更改，因此应在所有服务器上监控这些指标。非 Leader 服务器缺失（或为 0）的指标可以安全地忽略。

Nomad 客户端为其运行的主机以及正在运行的每个分配都有单独的指标。必须显式启用这两组指标。必须显式启用。

默认情况下，Nomad agent 以 1 秒间隔收集遥测数据。请注意，Nomad 支持 计量器、计数器和计时器。

有三种方法可以从 Nomad 获取指标

• 查询 /v1/metrics API 端点以返回当前 Nomad 进程的指标。此端点支持 Prometheus 格式的指标。

• 将 USR1 信号发送到 Nomad 进程。这将把当前的遥测信息转储到 STDERR（在 Linux 上）。

• 配置 Nomad 以自动将指标转发到第三方提供商，例如 DataDog、Prometheus、statsd 和 Circonus。

告警

推荐的告警实践是利用您的监控提供商的告警功能。Nomad 的意图是公开指标，以便用户使用现有的监控系统作为支架来配置必要的告警，而不是原生支持告警。

• 使用 StatsD exporter 将指标从 Nomad 导出到 Prometheus，在 Prometheus 中定义 告警规则，并使用 Alertmanager 进行汇总和路由/通知（到 PagerDuty、Slack 等）。类似的工作流程也适用于 Datadog。

• 定期将测试作业提交到 Nomad，以确定您的应用程序部署管道是否正常工作。这种模式非常适合批处理工作负载。

• 在 Nomad 上部署 Nagios。集中管理 Nomad 作业文件，并在添加新的 Nomad 作业时添加 Nagios 监控。删除作业时，删除 Nagios 监控。将 Consul 告警映射到 Nagios 监控。这提供了一个特定于作业的告警系统。

• 编写一个脚本，查看每个批处理作业的历史记录，以确定作业是否处于不健康状态，并相应地更新您的监控系统。在许多情况下，如果给定的批处理作业偶尔失败，只要它恢复通过，这可能是可以接受的。

关键绩效指标

Nomad 服务器的内存、CPU、磁盘和网络使用量都随集群大小和调度吞吐量线性扩展。确保 Nomad 正常运行的最重要方面是监控这些系统资源，以确保服务器没有遇到资源限制。

Raft 共识协议

Nomad 使用 Raft 共识协议进行 Leader 选举和状态复制。虚假 Leader 选举可能是由于服务器之间的网络问题、CPU 资源不足或磁盘 IOPS 不足引起的。云环境中的用户通常会将服务器提升到具有改进的网络和 CPU 的下一个实例类别，以稳定 Leader 选举，或切换到更高性能的磁盘。

指标 nomad.raft.leader.lastContact 是 Raft 延迟的一般指标，可用于观察 Raft 定时器性能并指导基础设施配置。如果此数字上升，请查看 CPU、磁盘 IOPS 和网络延迟。 nomad.raft.leader.lastContact 不应过于接近 Leader 租期超时 500 毫秒。

指标 nomad.raft.replication.appendEntries 是 Raft 事务复制到追随者法定数量所需时间的一个指标。如果此数字上升，请检查追随者的磁盘 I/O 以及 Leader 和追随者之间的网络延迟。

如何检查 CPU、IO 操作和网络的方式取决于您的平台和环境。在 Linux 上，sysstat 包包含许多有用的工具。以下是一些需要考虑的示例。

• CPU - vmstat 1，云服务提供商的“CPU %”指标

• IO - iostat，sar -d，云服务提供商的“volume write/read ops”和“burst balance”指标

• Network - sar -n，netstat -s，云服务提供商的接口“allowance”指标

指标 nomad.raft.fsm.apply 是服务器将 Raft 条目应用到内部状态机所需时间的一个指标。如果这个数字呈上升趋势，请查看 nomad.nomad.fsm.* 指标，以查看是否有特定的 Raft 条目的延迟正在增加。您可以将其与 Nomad 服务器上关于 attempting to apply large raft entry 的 warn 级别日志进行比较。如果这里出现特定类型的消息，则可能存在具有大型作业规范或调度负载的作业，从而增加了应用 Raft 消息所需的时间。尝试通过将不同的任务组放入单独的作业、下载模板而不是嵌入它们，或减少任务组上的 count 来缩小作业的大小。

调度

关于 调度 的文档描述了评估如何成为调度计划和放置分配的工作流程。

进度

在 Nomad 中可能存在一类错误，即调度流水线的两个部分（worker 和 leader 的计划应用器）不同意计划的有效性。在极端情况下，这可能导致作业永远无法完成调度，因为 worker 生成相同的计划，而计划应用器会重复拒绝它。

虽然这一类错误非常罕见，但可以通过 Nomad 服务器上重复出现的包含 plan for node rejected 的日志行来检测。

nomad: plan for node rejected: node_id=0fa84370-c713-b914-d329-f6485951cddc reason="reserved port collision" eval_id=098a5

虽然由于正常的集群条件，这些日志行可能会偶尔出现，但它们不应该重复出现并阻止作业最终运行（查找日志中记录的评估 ID 以找到作业）。

计划拒绝跟踪器

Nomad 提供了一种机制来跟踪每个客户端的计划拒绝历史记录，并在给定时间窗口内数量超过给定阈值时将它们标记为不合格。可以使用 plan_rejection_tracker 服务器配置启用此功能。

当节点由于过多的计划拒绝而被标记为不合格时，将注册以下节点事件

Node marked as ineligible for scheduling due to multiple plan rejections, refer to https://developer.hashicorp.org.cn/nomad/s/port-plan-failure for more information

以及日志行

[WARN]  nomad.state_store: marking node as ineligible due to multiple plan rejections: node_id=67af2541-5e96-6f54-9095-11089d627626

如果客户端由于重复的计划拒绝而被标记为不合格，请尝试 清空 节点并关闭它。未被验证捕获的配置错误可能导致节点进入此状态：#11830。

如果 plan for node rejected 日志确实重复出现，并且引用了相同的 node_id，但客户端未被设置为不合格，您可以尝试调整服务器的 plan_rejection_tracker 配置。

性能

以下指标允许观察调度过程各个点的吞吐量变化。

• nomad.worker.invoke_scheduler.<type> - 运行给定类型调度器的时间。每个调度器 worker 一次处理一个评估，完全在内存中。如果此指标增加，请检查调度器的 CPU 和内存资源。

• nomad.blocked_evals.total_blocked - 阻塞的评估数量。当调度器无法将所有分配作为计划的一部分放置时，会创建阻塞的评估。阻塞的评估将被重新评估，以便可以使用集群资源的变化来进行阻塞评估的分配。阻塞评估数量的增加可能意味着集群的客户端资源不足，或者提交了无法放置所有分配的作业。

• nomad.broker.total_unacked - 未确认的评估数量。当评估被处理后，worker 会向 leader 发送确认 RPC，以向 eval broker 信号处理完成。未确认的评估是指在调度器中进行中但尚未确认的评估。未确认评估数量的增加可能意味着调度器具有大量的评估队列需要处理。请参阅上面的 invoke_scheduler 指标，并检查调度器的 CPU 和内存资源。Nomad 还会为每个单独的调度器发出类似的指标。例如 nomad.broker.batch_unacked 显示批处理调度器的未确认评估数量。

• nomad.broker.total_pending - eval broker 中待处理的评估数量。Nomad 仅并发处理给定作业的一个评估。当未确认的评估被确认后，Nomad 将丢弃作业的最新评估之外的所有评估。此指标的增加可能意味着集群状态的变化速度超过了调度器可以跟上的速度。

• nomad.plan.evaluate - worker 提交的调度器计划的评估时间。此操作发生在 leader 上，以序列化所有调度器 worker 的计划。这完全发生在 leader 的内存中。如果此指标增加，请检查 leader 的 CPU 和内存资源。

• nomad.plan.wait_for_index - 计划者等待计划的 Raft 索引被处理的时间。如果此指标增加，请参阅上面的 共识协议 (Raft) 部分。如果此指标接近 5 秒，则调度操作可能会失败并重试。如果可能，请减少调度负载，直到指标改善为止。

• nomad.plan.submit - 从 worker 向 leader 提交调度器计划的时间。此操作需要写入 Raft，包括来自 nomad.plan.evaluate 和 nomad.plan.wait_for_index (上面) 的时间。如果此指标增加，请参阅上面的 共识协议 (Raft) 部分。

• nomad.plan.queue_depth - 正在等待评估的调度器计划的数量，在提交后。如果此指标增加，请检查 nomad.plan.evaluate 和 nomad.plan.submit 指标，以确定问题是普遍的 leader 资源还是 Raft 性能。

以上任何指标的上升都表明调度器吞吐量下降。

容量

监控资源可用性的重要性取决于工作负载。批处理工作负载通常假定集群应处于或接近满容量，排队的作业在有足够的资源可用时运行。主要负责具有正常运行时间要求的长期服务的集群可能希望保持 20% 或更高的余量。可以使用以下指标来评估集群中每个客户端的容量。

• nomad.client.allocated.cpu
• nomad.client.unallocated.cpu
• nomad.client.allocated.disk
• nomad.client.unallocated.disk
• nomad.client.allocated.memory
• nomad.client.unallocated.memory

任务资源消耗

可以在 此处 列出的指标可用于跟踪每个任务的基础上资源消耗。对于面向用户的服务，当 CPU 处于或高于任务的保留资源时，通常会发出警报。

作业和任务状态

请参阅 作业摘要指标 以监控在 Nomad 上运行的工作负载的健康状况和状态。

运行时指标

运行时指标适用于所有客户端和服务器。以下指标是负载和内存压力的总体指标。

• nomad.runtime.num_goroutines
• nomad.runtime.heap_objects
• nomad.runtime.alloc_bytes

建议对以上任何指标的上升发出警报，特别是服务器内存使用情况。

Serf 集群联邦部署

Nomad 使用 Serf 库的成员管理和故障检测功能，为集群联邦部署中的所有服务器维护一个单一的全局 gossip 池。 member.flap 和/或 msg.suspect 的增加是成员关系不稳定的可靠指标。

如果这些指标增加，请检查服务器的 CPU 负载以及 Serf 地址的网络延迟和丢包情况。

客户端介绍

当您将 Nomad 配置为将 client_introduction.enforcement 设置为 warn 或 strict 时，处理客户端注册请求的服务器会每次在没有介绍令牌的情况下进行新的注册时，都会增加 nomad.client.introduction.enforcement 计数器。

监控此指标可以帮助识别未使用介绍令牌注册的客户端，这在迁移到更严格的执行级别时非常重要。