**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# EKS ノードモニタリングエージェントのノードのヘルス問題を検出する
<a name="node-health-nma"></a>

このトピックでは、EKS ノードモニタリングエージェントによって検出されたノードのヘルス問題、それらの問題がノード条件またはイベントとしてどのように表示されるか、ノードモニタリングエージェントを設定する方法について説明します。

EKS ノードモニタリングエージェントは、EKS 自動ノード修復の有無にかかわらず使用できます。EKS 自動ノード修復の詳細については、「[EKS クラスター内のノードを自動的に修復する](node-repair.md)」を参照してください。

EKS ノードモニタリングエージェントのソースコードは、GitHub の [aws/eks-node-monitoring-agent](https://github.com/aws/eks-node-monitoring-agent) リポジトリに公開されています。

## ノードのヘルスの問題
<a name="node-health-issues"></a>

次の表は、ノードモニタリングエージェントが検出できるノードのヘルス問題を示しています。次の 2 種類の問題があります。
+ 症状 – インスタンスの置き換えや再起動などの修復アクションを必要とするターミナルの問題。自動修復が有効になっている場合、Amazon EKS はノードの置換または再起動として修復アクションを実行します。詳細については、「[ノードの状態](learn-status-conditions.md#status-node-conditions)」を参照してください。
+ イベント – 一時的な問題または最適ではないノード設定。自動修復アクションは行われません。詳細については、「[ノードイベント](learn-status-conditions.md#status-node-events)」を参照してください。

## AcceleratedHardware ノードのヘルス問題
<a name="node-health-AcceleratedHardware"></a>

次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `AcceleratedHardwareReady` です。以下の表のイベントと条件は、NVIDIA および Neuron 関連のノードのヘルス問題に関するものです。


| 名前 | 緊急度 | 説明 | 修復アクション | 
| --- | --- | --- | --- | 
|  DCGMDiagnosticFailure  |  条件  |  DCGM アクティブ診断テストスイートからのテストケースが失敗しました。  |  なし  | 
|  DCGMError  |  条件  |  DCGM ホストプロセスへの接続を失ったか、確立できませんでした。  |  なし  | 
|  DCGMFieldError[Code]  |  イベント  |  DCGM が、フィールド識別子を介して GPU の劣化を検出しました。  |  なし  | 
|  DCGMHealthCode[Code]  |  イベント  |  DCGM ヘルスチェックが、致命的ではない方法で失敗しました。  |  なし  | 
|  DCGMHealthCode[Code]  |  条件  |  DCGM ヘルスチェックが、致命的な方法で失敗しました。  |  なし  | 
|  NeuronDMAError  |  条件  |  DMA エンジンで回復不可能なエラーが発生しました。  |  置換  | 
|  NeuronHBMUncorrectableError  |  条件  |  HBM で修正不可能なエラーが発生し、誤った結果が生成されました。  |  置換  | 
|  NeuronNCUncorrectableError  |  条件  |  Neuron Core の修正不可能なメモリエラーが検出されました。  |  置換  | 
|  NeuronSRAMUncorrectableError  |  条件  |  オンチップ SRAM でパリティエラーが発生し、誤った結果が生成されました。  |  置換  | 
|  NvidiaDeviceCountMismatch  |  イベント  |  NVML で認識される GPU の数が、ファイルシステムの NVIDIA デバイス数と一致していません。  |  なし  | 
|  NvidiaDoubleBitError  |  条件  |  GPU ドライバーによってダブルビットエラーが生成されました。  |  置換  | 
|  NvidiaNCCLError  |  イベント  |  NVIDIA Collective Communications ライブラリ (`libnccl`) でセグメンテーション違反が発生しました。  |  なし  | 
|  NvidiaNVLinkError  |  条件  |  NVLink エラーが GPU ドライバーによって報告されました。  |  置換  | 
|  NvidiaPCIeError  |  イベント  |  送信エラーから回復するために PCIe リプレイがトリガーされました。  |  なし  | 
|  NvidiaPageRetirement  |  イベント  |  GPU ドライバーがメモリページを廃止としてマークしました。これは、1 つのダブルビットエラーが起こった場合、または同じアドレスで 2 つのシングルビットエラーが起こった場合に発生する可能性があります。  |  なし  | 
|  NvidiaPowerError  |  イベント  |  GPU の電力使用率が許容しきい値を超えました。  |  なし  | 
|  NvidiaThermalError  |  イベント  |  GPU の熱ステータスが許容しきい値を超えました。  |  なし  | 
|  NvidiaXID[Code]Error  |  条件  |  重大な GPU エラーが発生しました。  |  置換または再起動  | 
|  NvidiaXID[Code]Warning  |  イベント  |  重要ではない GPU エラーが発生しました。  |  なし  | 

## NVIDIA XID エラーコード
<a name="nvidia-xid-codes"></a>

ノードモニタリングエージェントは、GPU カーネルログから NVIDIA XID エラーを検出します。XID エラーは 2 つのカテゴリに分類されます。
+  **既知の XID コード** – ノード条件 (`AcceleratedHardwareReady=False`) を設定し、有効になっている場合に自動修復をトリガーする重大なエラー。理由コードの形式は `NvidiaXID[Code]Error` です。EKS ノードモニタリングエージェントが検出する既知の XID コードは、修復アクションを必要とする NVIDIA XID コードの完全なリストを表していない場合があります。
+  **不明な XID コード** – Kubernetes イベントとしてのみログに記録されます。これらは自動修復をトリガーしません。理由コードの形式は `NvidiaXID[Code]Warning` です。不明な XID エラーを調査するには、`dmesg | grep -i nvrm` でカーネルログを確認します。

XID エラーの詳細については、「*NVIDIA GPU のデプロイおよび管理ドキュメント*」の「[Xid エラー](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1)」を参照してください。個々の XID メッセージの詳細については、「*NVIDIA GPU Deployment and Management Documentation*」の「[Understanding Xid Messages](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages)」を参照してください。

以下の表に、既知の XID コード、その意味、および有効になっている場合のデフォルトのノード修復アクションを示します。


| XID コード | 説明 | 修復アクション | 
| --- | --- | --- | 
|  13  |  グラフィックエンジン例外 – GPU グラフィックエンジンエラーが発生しました。通常、ソフトウェアの問題やドライバーのバグが原因です。  |  リブート  | 
|  31  |  GPU メモリページの障害 – アプリケーションがマッピングされていない、またはアクセスできない GPU メモリにアクセスしようとしました。  |  リブート  | 
|  48  |  ダブルビット ECC エラー – GPU メモリで修正不可能なダブルビットエラーが発生しました。これはハードウェアの劣化の可能性を示しています。  |  リブート  | 
|  63  |  GPU メモリの再マッピングイベント – 検出されたエラーにより、GPU ドライバーが GPU メモリの一部を再マッピングしました。これは多くの場合、回復可能です。  |  リブート  | 
|  64  |  GPU メモリの再マッピングの失敗 – GPU が欠陥メモリを再マッピングできませんでした。これはハードウェアの問題を示しています。  |  リブート  | 
|  74  |  NVLink エラー – GPU 間の高速 NVLink 相互接続でエラーが発生しました。  |  置換  | 
|  79  |  GPU がバスから切断された – GPU は PCIe 経由でアクセスできなくなりました。これは通常、ハードウェアの障害や電源の問題を示しています。  |  置換  | 
|  94  |  限定的なメモリエラー – メモリエラーが発生しましたが、その影響は限定的で、他のアプリケーションには影響しませんでした。  |  リブート  | 
|  95  |  非限定的なメモリエラー – メモリエラーが発生し、他のアプリケーションやシステムメモリに影響を与えた可能性があります。  |  リブート  | 
|  119  |  GSP RPC タイムアウト – GPU システムプロセッサとの通信がタイムアウトしました。これは、ファームウェアの問題が原因である可能性があります。  |  置換  | 
|  120  |  GSP エラー – GPU システムプロセッサでエラーが発生しました。  |  置換  | 
|  121  |  C2C エラー – チップ間相互接続 (マルチダイ GPU で使用) でエラーが発生しました。  |  置換  | 
|  140  |  ECC 未回復エラー – ECC エラーが検出されず、データが破損した可能性があります。  |  置換  | 

GPU ヘルスに関連する現在のノード条件を表示するには、以下のコマンドを実行します。

```
kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason'
```

クラスターで XID 関連のイベントを表示するには、以下のいずれかのコマンドを実行します。

```
kubectl get events | grep -i "NvidiaXID"
```

## ContainerRuntime ノードのヘルスの問題
<a name="node-health-ContainerRuntime"></a>

次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `ContainerRuntimeReady` です。


| 名前 | 緊急度 | 説明 | 修復アクション | 
| --- | --- | --- | --- | 
|  ContainerRuntimeFailed  |  イベント  |  コンテナランタイムはコンテナの作成に失敗しました。繰り返し発生する場合は、報告された問題に関連している可能性があります。  |  なし  | 
|  DeprecatedContainerdConfiguration  |  イベント  |  廃止されたイメージマニフェストバージョン 2、スキーマ 1 を使用するコンテナイメージが、最近 `containerd` を介してノードにプルされました。  |  なし  | 
|  KubeletFailed  |  イベント  |  kubelet が失敗状態になりました。  |  なし  | 
|  LivenessProbeFailures  |  イベント  |  ライブネスプローブの障害が検出されました。アプリケーションコードの問題や、繰り返し発生する場合はタイムアウト値が不十分である可能性を示しています。  |  なし  | 
|  PodStuckTerminating  |  条件  |  ポッドが終了しているか、または長時間停止していました。これは、ポッドの状態の進行を妨げる CRI エラーが原因で発生する可能性があります。  |  置換  | 
|  ReadinessProbeFailures  |  イベント  |  レディネスプローブの障害が検出されました。アプリケーションコードの問題や、繰り返し発生する場合はタイムアウト値が不十分である可能性を示しています。  |  なし  | 
|  [Name]RepeatedRestart  |  イベント  |  systemd ユニットが頻繁に再起動しています。  |  なし  | 
|  ServiceFailedToStart  |  イベント  |  systemd ユニットの起動に失敗しました。  |  なし  | 

## カーネルノードのヘルスの問題
<a name="node-health-Kernel"></a>

次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `KernelReady` です。


| 名前 | 緊急度 | 説明 | 修復アクション | 
| --- | --- | --- | --- | 
|  AppBlocked  |  イベント  |  タスクが長時間スケジュールからブロックされており、通常は入力または出力がブロックされていることが原因で発生します。  |  なし  | 
|  AppCrash  |  イベント  |  ノード上のアプリケーションがクラッシュしました。  |  なし  | 
|  ApproachingKernelPidMax  |  イベント  |  プロセスの数が、現在の `kernel.pid_max` 設定で使用可能な PID の最大数に近づいています。最大数に到達すると、これ以上プロセスを起動することはできません。  |  なし  | 
|  ApproachingMaxOpenFiles  |  イベント  |  開いているファイルの数は、現在のカーネル設定で可能な開いているファイルの最大数に近づいています。最大数に到達すると、新しいファイルを開くことができなくなります。  |  なし  | 
|  ConntrackExceededKernel  |  イベント  |  接続追跡がカーネルの最大数を超え、新しい接続を確立できなかったため、パケットロスが発生する可能性があります。  |  なし  | 
|  ExcessiveZombieProcesses  |  イベント  |  完全に再要求できないプロセスが大量に蓄積されています。これはアプリケーションの問題を示しており、システムプロセスの制限に達する可能性があります。  |  なし  | 
|  ForkFailedOutOfPIDs  |  条件  |  フォークまたは実行の呼び出しが失敗したのは、システムがプロセス ID またはメモリ不足であるためです。これは、ゾンビプロセスまたは物理メモリの枯渇が原因である可能性があります。  |  置換  | 
|  KernelBug  |  イベント  |  CPU またはメモリの使用率が高いノードが原因でイベント処理が遅れることがありますが、カーネルのバグが Linux カーネル自体によって検出および報告されました。  |  なし  | 
|  LargeEnvironment  |  イベント  |  このプロセスの環境変数の数は予想よりも多く、`enableServiceLinks` が true に設定されている多くのサービスが原因で発生する可能性があります。このため、パフォーマンスの問題が発生する可能性があります。  |  なし  | 
|  RapidCron  |  イベント  |  このノードでは、cron ジョブが 5 分間隔よりも速く実行されています。このため、ジョブが大量のリソースを消費すると、パフォーマンスに影響が出る可能性があります。  |  なし  | 
|  SoftLockup  |  イベント  |  CPU が一定時間停止しました。  |  なし  | 

## ネットワークノードのヘルスの問題
<a name="node-health-Networking"></a>

次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `NetworkingReady` です。


| 名前 | 緊急度 | 説明 | 修復アクション | 
| --- | --- | --- | --- | 
|  BandwidthInExceeded  |  イベント  |  インバウンド集計帯域幅がインスタンスの最大値を超えたため、パケットはキューに入れられたか、ドロップされました。  |  なし  | 
|  BandwidthOutExceeded  |  イベント  |  アウトバウンド集計帯域幅がインスタンスの最大値を超えたため、パケットはキューに入れられたか、ドロップされました。  |  なし  | 
|  ConntrackExceeded  |  イベント  |  接続追跡がインスタンスの最大数を超え、新しい接続を確立できなかったため、パケットロスが発生する可能性があります。  |  なし  | 
|  EFAErrorMetric  |  イベント  |  EFA ドライバーメトリクスは、パフォーマンスが低下しているインターフェイスがあることを示しています。  |  なし  | 
|  IPAMDInconsistentState  |  イベント  |  ディスク上の IPAMD チェックポイントの状態が、コンテナランタイム内の IP を反映していません。  |  なし  | 
|  IPAMDNoIPs  |  イベント  |  IPAMD が IP アドレスから外れています。  |  なし  | 
|  IPAMDNotReady  |  条件  |  IPAMD が API サーバーに接続できません。  |  置換  | 
|  IPAMDNotRunning  |  条件  |  Amazon VPC CNI プロセスは実行中であることが確認されませんでした。  |  置換  | 
|  IPAMDRepeatedlyRestart  |  イベント  |  IPAMD サービスで複数の再起動が発生しました。  |  なし  | 
|  InterfaceNotRunning  |  条件  |  このインターフェイスは実行されていないか、ネットワークの問題があります。  |  置換  | 
|  InterfaceNotUp  |  条件  |  このインターフェイスは起動していないか、ネットワークの問題があります。  |  置換  | 
|  KubeProxyNotReady  |  イベント  |  Kube-proxy がリソースの監視または一覧表示に失敗しました。  |  なし  | 
|  LinkLocalExceeded  |  イベント  |  ローカルプロキシサービスへのトラフィックの PPS がネットワークインターフェイスの最大値を超えたため、パケットがドロップされました。  |  なし  | 
|  MACAddressPolicyMisconfigured  |  イベント  |  systemd-networkd のリンク設定で、`MACAddressPolicy` の値が正しくありません。  |  なし  | 
|  MissingDefaultRoutes  |  イベント  |  デフォルトのルートルールが見つかりません。  |  なし  | 
|  MissingIPRoutes  |  イベント  |  Pod IP のルートがありません。  |  なし  | 
|  MissingIPRules  |  イベント  |  Pod IP のルールがありません。  |  なし  | 
|  MissingLoopbackInterface  |  条件  |  このインスタンスには、ループバックインターフェイスがないため、ローカル接続によってはサービスの不具合が発生します。  |  置換  | 
|  NetworkSysctl  |  イベント  |  このノードのネットワーク `sysctl` 設定が正しくない可能性があります。  |  なし  | 
|  PPSExceeded  |  イベント  |  双方向 PPS がインスタンスの最大値を超えたため、パケットはキューに入れられたか、ドロップされました。  |  なし  | 
|  PortConflict  |  イベント  |  ポッドが hostPort を使用する場合、ホストの既にバインドされているポートを上書きするように `iptables` ルールを書き込みできるため、API サーバーが `kubelet` にアクセスできなくなる可能性があります。  |  なし  | 
|  UnexpectedRejectRule  |  イベント  |  `iptables` で予期しない `REJECT` または `DROP` ルールが検出されたため、予想されたトラフィックがブロックされる可能性があります。  |  なし  | 

## ストレージノードのヘルスの問題
<a name="node-health-Storage"></a>

次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `StorageReady` です。


| 名前 | 緊急度 | 説明 | 修復アクション | 
| --- | --- | --- | --- | 
|  EBSInstanceIOPSExceeded  |  イベント  |  インスタンスの最大 IOPS を超えました。  |  なし  | 
|  EBSInstanceThroughputExceeded  |  イベント  |  インスタンスの最大スループットを超えました。  |  なし  | 
|  EBSVolumeIOPSExceeded  |  イベント  |  特定の EBS ボリュームに対する最大 IOPS を超えました。  |  なし  | 
|  EBSVolumeThroughputExceeded  |  イベント  |  特定の Amazon EBS ボリュームに対する最大スループットを超えました。  |  なし  | 
|  EtcHostsMountFailed  |  イベント  |  `kubelet-container` オペレーション中にユーザーデータを `/var/lib/kubelet/pods` に再マウントしたため、kubelet が生成した `/etc/hosts` のマウントに失敗しました。  |  なし  | 
|  IODelays  |  イベント  |  入力または出力の遅延がプロセスで検出されました。過剰な場合は入力/出力プロビジョニングが不十分である可能性があります。  |  なし  | 
|  KubeletDiskUsageSlow  |  イベント  |  `kubelet` は、ファイルシステムにアクセスしようとしているときにディスクの使用が遅いことを報告しています。これは、ディスクの入出力が不十分である、またはファイルシステムに問題がある可能性を示しています。  |  なし  | 
|  XFSSmallAverageClusterSize  |  イベント  |  XFS 平均クラスターサイズが小さいことは、空き領域が過度に断片化されていることを示しています。このため、inode や空き領域が使用可能であっても、ファイルを作成できない場合があります。  |  なし  | 

## ノードモニタリングエージェントを設定する
<a name="node-monitoring-agent-configure"></a>

EKS ノードモニタリングエージェントは DaemonSet としてデプロイされます。EKS アドオンとしてデプロイする場合、以下の設定値を使用してインストールをカスタマイズできます。デフォルト設定については、EKS ノードモニタリングエージェントの [Helm チャート](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml)を参照してください。


| 設定オプション | 説明 | 
| --- | --- | 
|   `monitoringAgent.resources.requests.cpu`   |  モニタリングエージェントの CPU リソースリクエスト。  | 
|   `monitoringAgent.resources.requests.memory`   |  モニタリングエージェントのメモリリソースリクエスト。  | 
|   `monitoringAgent.resources.limits.cpu`   |  モニタリングエージェントの CPU リソース制限。  | 
|   `monitoringAgent.resources.limits.memory`   |  モニタリングエージェントのメモリリソース制限。  | 
|   `monitoringAgent.tolerations`   |  テイントが適用されたノードでモニタリングエージェントをスケジュールするための許容範囲。  | 
|   `monitoringAgent.additionalArgs`   |  モニタリングエージェントに渡す追加のコマンドライン引数。  | 

**注記**  
EKS アドオンまたは Helm インストールを使用して、`hostname-override` と `verbosity` を `monitoringAgent.additionalArgs` として設定できます。現在、EKS アドオンまたは Helm インストールでは、追加の引数を使用してノードモニタリングエージェントの `probe-address` (`8002`) または `metrics-address` (`8003`) をカスタマイズすることはできません。

ノードモニタリングエージェントには、NVIDIA GPU をモニタリングするための NVIDIA DCGM (Data Center GPU Manager) サーバーコンポーネント (`nv-hostengine`) が含まれています。このコンポーネントは、エージェントの [Helm チャート](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml)の `nodeAffinity` で示されるように、NVIDIA GPU インスタンスタイプのノードでのみ実行されます。EKS ノードモニタリングエージェントで既存の NVIDIA DCGM インストールを使用することはできません。この機能が必要な場合は、EKS ロードマップ [GitHub 問題 \$12763](https://github.com/aws/containers-roadmap/issues/2763) に関するフィードバックを提供してください。

EKS ノードモニタリングエージェントを EKS アドオンとしてデプロイする場合、以下の設定値を使用して NVIDIA DCGM のインストールをカスタマイズできます。


| 設定オプション | 説明 | 
| --- | --- | 
|   `dcgmAgent.resources.requests.cpu`   |  DCGM エージェントの CPU リソースリクエスト。  | 
|   `dcgmAgent.resources.requests.memory`   |  DCGM エージェントのメモリリソースリクエスト。  | 
|   `dcgmAgent.resources.limits.cpu`   |  DCGM エージェントの CPU リソース制限。  | 
|   `dcgmAgent.resources.limits.memory`   |  DCGM エージェントのメモリリソース制限。  | 
|   `dcgmAgent.tolerations`   |  テイントが適用されたノードで DCGM エージェントをスケジュールするための許容範囲。  | 

以下の AWS CLI コマンドを使用して、EKS ノードモニタリングエージェントの EKS アドオンのバージョンとスキーマに関する有用な情報を取得できます。

Kubernetes バージョンの最新のエージェントアドオンバージョンを取得します。`1.35` を Kubernetes バージョンに置き換えます。

```
aws eks describe-addon-versions \
  --addon-name eks-node-monitoring-agent \
  --kubernetes-version 1.35 \
  --query='addons[].addonVersions[].addonVersion'
```

EKS アドオンでサポートされているエージェントアドオンスキーマを取得します。`v1.5.1-eksbuild.1` をエージェントバージョンに置き換えます。

```
aws eks describe-addon-configuration \
  --addon-name eks-node-monitoring-agent \
  --addon-version v1.5.1-eksbuild.1
```