モニター

サービスがユーザーに対して利用可能でアクセス可能であることを確認することが重要です。これを監視するために、SUSE Observabilityは、サービスに少なくとも1つのエンドポイントが利用可能であるかどうかを確認するチェックを設定しました。エンドポイントは、分散システム内の異なるコンポーネント間の通信を可能にするネットワークアドレスであり、サービスが適切に機能するためには利用可能である必要があります。 過去10分間において利用可能なエンドポイントが一つも確認されなかった場合、モニターは逸脱状態を維持し、サービスに問題がある可能性があることを示します。 モニター引数のオーバーライドを許可します。

ユーザーはネームスペース内でリソース（ポッド、サービスなど）を作成し、クォータシステムは使用状況を追跡して、リソースクォータで定義されたCPUのハードリソース制限を超えないようにします。モニターは、ネームスペース内のCPU制限の合計がクォータで設定された90％以上に達したときに警告します。ネームスペース内の各`resourcequota`は、モニターの健康状態を生成します。

ユーザーはネームスペース内でリソース（ポッド、サービスなど）を作成し、クォータシステムは使用状況を追跡して、リソースクォータで定義されたCPUのハードリソースリクエストを超えないようにします。モニターは、ネームスペース内のCPUリクエストの合計がクォータで設定された90％以上に達したときに警告します。ネームスペース内の各`resourcequota`は、モニターの健康状態を生成します。

デーモンセットの希望するレプリカ数が満たされていることが重要です。デーモンセットは、クラスター内のすべてまたは一部のノードで実行する必要があるポッドのセットを管理するために使用され、指定された基準を満たす各ノードでポッドのコピーが実行されることを保証します。これは、ログ記録、監視、およびクラスター内のすべてのノードで実行する必要があるその他のクラスター レベルのタスクに役立ちます。

これを監視するために、SUSE Observability は、利用可能なレプリカが希望するレプリカの数と一致するかどうかを確認するチェックを設定しました。このチェックは、希望するレプリカの数がゼロより大きい DaemonSet にのみ適用されます。

完全なモニター定義を理解するには、詳細を確認してください。

Kubernetes クラスター内の永続ボリュームクレーム (PVC) の使用状況を時間の経過とともに監視することが重要です。PVC は、コンテナの寿命を超えて永続化する必要があるデータを保存するために使用され、データを保存するための十分なスペースがあることを確認することが重要です。 これを追跡するために、4日間にわたってKubernetesボリューム使用量の傾向を予測する線形予測を使用するチェックを設定しました。傾向がこの期間内に PVC がスペースを使い果たすことを示す場合、通知を受け取り、データ損失やダウンタイムを防ぐための対策を講じることができます。

Kubernetes クラスター内の永続ボリュームクレーム (PVC) の使用状況を監視することが重要です。PVC は、コンテナの寿命を超えて永続化する必要があるデータを保存するために使用され、データを保存するための十分なスペースがあることを確認することが重要です。これを追跡するために、12時間にわたってKubernetesボリューム使用量の傾向を予測する線形予測を使用するチェックを設定しました。傾向がこの期間内に PVC がスペースを使い果たすことを示す場合、通知を受け取り、データ損失やダウンタイムを防ぐための対策を講じることができます。

デプロイメントにおいて、希望されるレプリカ数が確保されていることが重要です。デプロイメントは、Kubernetesクラスター内の同一のポッド群のデプロイとスケーリングを管理するために使用されます。希望するレプリカが実行され、利用可能であることを確認することで、デプロイメントはKubernetesアプリケーションやサービスの可用性と信頼性を維持するのに役立ちます。これを監視するために、SUSE Observability は、利用可能なレプリカが希望するレプリカの数と一致するかどうかを確認するチェックを設定しました。

このチェックは、希望するレプリカの数がゼロより大きいデプロイメントにのみ適用されます。

完全なモニター定義を理解するには、詳細を確認してください。

HTTPレスポンスのステータスコードが5xxの範囲にある場合、サーバー側のエラー、例えば設定ミス、過負荷、または内部サーバーエラーを示します。 良好なユーザーエクスペリエンスを確保するために、5xx レスポンスの割合はKubernetesサービスの総HTTPレスポンスの5%未満であるべきです。

正確な閾値と深刻度はアプリケーションに依存する可能性があるため、閾値はサービスに対して Kubernetes アノテーション を介して上書きすることができます。例えば、事前に設定された逸脱閾値を上書きし、代わりに6%のクリティカル閾値のみを持つには、このアノテーションをサービスに追加してください：

この JSON スニペットで逸脱閾値を省略すると、設定された5%のままとなり、クリティカル閾値が6%であるため、モニターは5%から6%の間のエラー比率に対してのみ逸脱状態を示します。

Kubernetesサービスの95パーセンタイル（Q95） HTTPレスポンスタイムを追跡することで、ユーザーに影響を与える可能性のある遅いリクエストやパフォーマンスの異常を特定するのに役立ちます。指定された時間ウィンドウ内で Q95 レスポンスタイムが3秒を超えると、モニターは逸脱状態で警告します。

このモニターは、サービスに対して Kubernetes アノテーションを使用して、時間ウィンドウ、閾値、または分位数などの デフォルト設定を上書きする ことで、アプリケーションのニーズに合わせて調整できます。この柔軟性は、サービスに特有のパフォーマンス要件がある場合に役立ちます。例えば、ロングポーリングサービスです。

モニターをカスタマイズするには、サービスに次のようなアノテーションを追加し、必要に応じて値を調整してください：

Kubernetes クラスター内の永続ボリュームクレーム (PVC) の使用状況を監視することが重要です。PVC は、コンテナの寿命を超えて永続化する必要があるデータを保存するために使用され、データを保存するための十分なスペースがあることを確認することが重要です。これを追跡するために、SUSE Observabilityは、12時間の期間にわたるKubernetesボリューム使用量のトレンドを予測するために線形予測を使用するチェックを設定しました。傾向がこの期間内に PVC がスペースを使い果たすことを示す場合、通知を受け取り、データ損失やダウンタイムを防ぐための対策を講じることができます。

Kubernetes クラスター内の永続ボリュームクレーム (PVC) の使用状況を時間の経過とともに監視することが重要です。PVC は、コンテナの寿命を超えて永続化する必要があるデータを保存するために使用され、データを保存するための十分なスペースがあることを確認することが重要です。 これを追跡するために、SUSE Observabilityは、Kubernetesのボリューム使用トレンドを4日間にわたって予測する線形予測を使用するチェックを設定しました。傾向がこの期間内に PVC がスペースを使い果たすことを示す場合、通知を受け取り、データ損失やダウンタイムを防ぐための対策を講じることができます。

ユーザーは名前空間内でリソース（ポッド、サービスなど）を作成し、クォータシステムは使用状況を追跡して、リソースクォータで定義されたメモリのハードリソース制限を超えないようにします。モニターは、名前空間内の総メモリ制限がクォータによって設定された90％以上に達したときに警告します。名前空間内の各`resourcequota`は、モニターの健康状態を生成します。

ユーザーは名前空間内でリソース（ポッド、サービスなど）を作成し、クォータシステムは使用状況を追跡して、リソースクォータで定義されたメモリのハードリソース要求を超えないようにします。モニターは、名前空間内の総メモリ要求がクォータによって設定された90％以上に達したときに警告します。名前空間内の各`resourcequota`は、モニターの健康状態を生成します。

ノードディスク圧力とは、ノードに接続されたディスクが過度の負荷を受ける状況を指します。Kubernetesのビルトインの予防策により、ノードディスク圧力に遭遇する可能性は低いですが、まれに発生することがあります。ノードディスク圧力が発生する主な理由は2つあります。最初の理由は、Kubernetesが未使用のイメージをクリーンアップできないことに関連しています。通常、Kubernetesは定期的に使用されていないイメージをチェックして削除します。したがって、これはノードディスク圧力の珍しい原因ですが、承認されるべきです。より可能性の高い問題は、ログの蓄積です。Kubernetesでは、ログは通常、コンテナが実行中のときと、最も最近終了したコンテナのログがトラブルシューティングの目的で保持されるときに保存されます。このアプローチは、重要なログを保持し、不要なログを時間とともに破棄するバランスを取ることを目的としています。しかし、長時間実行されるコンテナが大量のログを生成すると、それらが蓄積してノードディスクの容量を超える可能性があります。完全なモニター定義を理解するには、詳細を確認してください。 モニター引数のオーバーライドを許可します。

ノードメモリ圧力とは、Kubernetesノードのメモリリソースが過度に負荷を受ける状況を指します。Kubernetesのビルトインリソース管理メカニズムにより、ノードのメモリ圧力に遭遇することは稀ですが、特定の状況下では発生する可能性があります。ノードのメモリ圧力が発生する主な理由は2つあります。一つ目の理由は、ノード上で実行されているコンテナのリソースリクエストと制限が誤って設定されているか、不十分であることに関連しています。Kubernetesは、リソースリクエストと制限に依存して、リソースを効果的に割り当て、管理します。コンテナがメモリ要件を正確に設定されていない場合、予想以上のメモリを消費し、ノードのメモリ圧力を引き起こす可能性があります。二つ目の理由は、メモリ集約型のアプリケーションやプロセスの存在です。特定のワークロードやアプリケーションは、より高いメモリ要求を持ち、ノード上のメモリ使用量が増加する結果となります。複数のポッドやコンテナが、適切なリソース割り当てなしに同じノード上にスケジュールされると、メモリ圧力を引き起こす可能性があります。ノードのメモリ圧力を軽減するためには、コンテナのリソースリクエストと制限を見直し、アプリケーションの実際のメモリニーズに合わせて調整することが重要です。アプリケーション内でのメモリ使用量を監視し最適化することも、メモリ消費を減少させるのに役立ちます。さらに、メモリ使用量に基づいてポッドの数を動的にスケールするために、水平ポッドオートスケーリングを検討してください。定期的な監視、メモリ関連のメトリクスの分析、メモリリソースの積極的な割り当ては、Kubernetesノードの健全なメモリ状態を維持するのに役立ちます。ワークロードの特定の要件を理解し、メモリ圧力を防ぎ、最適なパフォーマンスを確保するためにリソース割り当てを調整することが不可欠です。 モニター引数のオーバーライドを許可します。

ノード PID 圧力は、Kubernetesノード上の利用可能なプロセス識別（PID）リソースが過度に逼迫しているときに発生します。一つ目の理由は、ノード上で実行されているコンテナのリソースリクエストと制限が誤って設定されているか、不十分であることに関連しています。Kubernetesは、リソースを効果的に割り当て、管理するために、正確なリソースリクエストと制限に依存しています。コンテナがPID要件を正しく設定されていない場合、予想以上のPIDを消費し、ノードPID圧力を引き起こす可能性があります。二つ目の理由は、PID集約型のアプリケーションやプロセスの存在です。一部のワークロードやアプリケーションは、プロセス識別に対する要求が高く、ノード上のPID使用量が増加する結果となります。複数のポッドやコンテナが、適切なリソース割り当てなしに同じノード上にスケジュールされると、PID圧力を引き起こす可能性があります。ノードPID圧力に対処するためには、リソースの要求と制限を見直し、調整して、アプリケーションの実際のPIDニーズに合致させることが重要です。アプリケーション内でのPID使用状況を監視し最適化することも、PID消費を減らすのに役立ちます。さらに、水平ポッドオートスケーリングを考慮することで、PID利用に基づいてポッドの数を動的にスケールさせることができます。定期的な監視、PID関連のメトリクスの分析、PIDリソースの積極的な割り当ては、KubernetesノードでのPID使用の健全な状態を維持するために重要です。ワークロードの具体的な要件を理解し、それに応じてリソースの割り当てを調整することは、PID圧力を防ぎ、最適なパフォーマンスを確保するために不可欠です。 モニター引数のオーバーライドを許可します。

ノードが期待通りに稼働しているか確認してください。 モニター引数のオーバーライドを許可します。

孤立した永続ボリュームがないことを確認してください。孤立した永続ボリュームとは、永続ボリュームクレームに関連付けられていない永続ボリュームのことです。孤立した永続ボリュームは、使用されていない機密データを含む可能性があるため、セキュリティリスクとなることがあります。孤立した永続ボリュームは、使用されていないため、リソースの無駄にもなります。 モニター引数のオーバーライドを許可しますが、`enabled`プロパティのみです。

Kubernetesクラスター内で稼働しているコンテナが適切に機能するために十分なメモリを持っていることを確認することが重要です。メモリ不足（OOM）状態は、コンテナがクラッシュしたり応答しなくなったりする原因となり、再起動やデータ損失の可能性を引き起こします。 これらの状態を監視するために、SUSE Observabilityは、クラスター内で稼働しているコンテナのOOMイベントを検出し報告するチェックを設定しました。このチェックは、メモリ不足に陥っているコンテナを特定し、問題が発生する前に対策を講じることを可能にします。 モニター引数のオーバーライドを許可します。

スケジュールされたポッドが稼働しており、期待される時間内にトラフィックを受け入れる準備ができているかを確認します。

サーバーとコンシューマースパンの期間を監視します。期間の95パーセンタイルが閾値（デフォルトは5000ms）を超えると、モニターは偏差状態になります。このモニターは、モニター引数のオーバーライドを介して設定のオーバーライドをサポートしています。

エラー状態を持つサーバーとコンシューマースパンの割合を監視します。エラースパンの割合が閾値（デフォルトは5）を超えると、モニターは偏差状態になります。このモニターは、モニター引数のオーバーライドを介して設定のオーバーライドをサポートしています。

ポッドが待機状態にあり、CreateContainerConfigError、CreateContainerError、CrashLoopBackOff、またはImagePullBackOffの理由を含む場合、それは偏差と見なされます。

レプリカセット（およびデプロイメント）の希望レプリカ数が満たされていることを確認することが重要です。レプリカセットとデプロイメントは、Kubernetesクラスター内の特定のポッドのレプリカ数を管理するために使用されます。

これを監視するために、SUSE Observability は、利用可能なレプリカが希望するレプリカの数と一致するかどうかを確認するチェックを設定しました。このチェックは、希望レプリカ数がゼロより大きいレプリカセットとデプロイメントにのみ適用されます。

さらに、レプリカセットの健康状態は、より包括的な監視のためにデプロイメントに伝播します。

Kubernetesクラスター内の各コンテナの再起動を監視することが重要です。コンテナは、アプリケーションやインフラストラクチャの問題など、さまざまな理由で再起動することがあります。 アプリケーションがスムーズに動作していることを確認するために、SUSE Observabilityは、10分間の期間にわたるコンテナの再起動数を追跡するモニターを設定しました。この期間中に3回以上の再起動が発生した場合、コンテナの健康状態は偏差状態に設定され、調査が必要な問題がある可能性を示します。

サービスがユーザーに対して利用可能でアクセス可能であることを確認することが重要です。これを監視するために、サービスに少なくとも1つのエンドポイントが利用可能であることを確認するチェックを設定しました。エンドポイントは、分散システム内の異なるコンポーネント間の通信を可能にするネットワークアドレスであり、サービスが適切に機能するためには利用可能である必要があります。 過去10分間に利用可能なエンドポイントがゼロの場合、モニターは偏差状態のままとなり、サービスに対処が必要な問題がある可能性を示します。 完全なモニター定義を理解するには、詳細を確認してください。

サーバーとコンシューマースパンの期間を監視します。期間の95パーセンタイルが閾値（デフォルトは5000ms）を超えると、モニターは偏差状態になります。このモニターは、モニター引数のオーバーライドを介して設定のオーバーライドをサポートしています。

Kubernetesサービスのエラー状態にあるサーバーおよびコンシューマースパンの割合。このモニターは、モニター引数のオーバーライドを介して設定のオーバーライドをサポートしています。

ステートフルセットの希望レプリカ数が満たされていることが重要です。ステートフルセットは、ステートフルアプリケーションを管理するために使用され、適切に機能するためには特定の数のレプリカが必要です。

これを監視するために、SUSE Observability は、利用可能なレプリカが希望するレプリカの数と一致するかどうかを確認するチェックを設定しました。このチェックは、希望レプリカ数がゼロより大きいステートフルセットにのみ適用されます。

Kubernetesで「NodeNotSchedulable」イベントに遭遇した場合、それはKubernetesスケジューラーが特定のノードにポッドを配置できなかったことを意味します。このイベントは、スケジューラーがリソース要件やその他の制約に基づいてポッドを実行するための適切なノードを見つけられないときに発生します。

クラスター自体には健康状態がありません。しかし、クラスターはいくつかのコンポーネントから構成されており、その中には正常な動作にとって重要なものもあります。モニターはこれらのコンポーネントの状態を集約します：

モニターはすべての最上位依存関係の状態を集約し、直接観測（例：メトリクスから）に基づいて最も重要な健康状態を返します。 このアプローチは、健康信号が低レベルの技術コンポーネント（ポッドなど）から高レベルの論理コンポーネントに伝播することを保証しますが、コンポーネント自体に観測された健康状態がない場合に限ります。 このモニターを効果的に使用するには、以下の健康チェックの一部またはすべてが無効になっていることを確認してください：

論理コンポーネントに直接モニターがない使用ケースがある場合は、派生状態モニター機能を使用して、それらが依存する技術コンポーネントに基づいて健康状態を推測できます。