アプリ・アラート

クラスターでのアプリ・モニタリングのセットアップに役立つ、以下のアプリ・レベルのメトリックおよびアラートしきい値を確認します。

モニター対象の般的なアプリ・レベル条件には、次のようなものがあります。

• 複数のアプリ・ポッドまたはコンテナーが 10 分以内に再始動します。
• アプリの複数のレプリカが実行されていません。
• 10 分のうちに 10 個を超える 5XX HTTP 応答コードを受信しました。
• 名前空間内の複数のポッドが不明な状態です。
• ワーカー・ノードで 5 つを超えるポッドをスケジュールすることはできません (保留状態)。

これらの症状の根本的な問題には、次のようなものがあります。

• 1 つ以上のワーカー・ノードが正常でない状態です。
• ワーカー・ノードで CPU、メモリー、またはディスク・スペースが不足しています。
• クラスターごとのポッドが最大限度に達しました。
• アプリそれ自体に問題があります。

これらの条件のモニターをセットアップするには、以下の IBM Cloud Monitoring メトリックに基づいてアラートを構成します。 アラートしきい値は、クラスター構成によって異なる可能性があることに注意してください。

ワーカー・ノード・アラート

ワーカー・ノードの以下のしきい値およびアラートを確認します。

ゾーン・アラート

ゾーン・レベルのアラートをセットアップするには、 sysdig-agent configmap を編集して、必要なラベル・フィルターを組み込みます。

1. 次のコマンドを実行して configmap を編集します。

   kubectl edit configmap sysdig-agent -n ibm-observe
   

2. k8s_cluster_name: <cluster_name> の後に次の YAML ブロックを追加します。 <cluster_name> をモニター対象のクラスターの名前で置き換えます。

   k8s_labels_filter:
     - include: "kubernetes.node.label.kubernetes.io/hostname"
     - include: "kubernetes.node.label.kubernetes.io/role"
     - include: "kubernetes.node.label.ibm-cloud.kubernetes.io/zone"
     - exclude: "*.kubernetes.io/*"
     - exclude: "*.pod-template-hash"
     - exclude: "*.pod-template-generation"
     - exclude: "*.controller-revision-hash"
     - include: "*"
   

3. IBM Cloud Monitoring ポッドを再始動します。 すべてのポッドを削除し、それらが再始動するまで待ちます。 ポッドのリストを取得します。

   kubectl get pods -n ibm-observe
   

4. ポッドを削除して再始動します。

   kubectl delete pods sysdig-agent-1111 sysdig-agent-2222 sysdig-agent-3333 -n ibm-observe
   

5. ポッドが再始動するまで 5 分間待ちます。 ポッドが再始動すると、以前に追加したラベルが IBM Cloud Monitoring で使用可能になります。
6. IBM Cloud Monitoring ダッシュボード > 「探索」 > **「PromQL 照会 (PromQL query)」**を開いて、ラベルが現在表示されていることを確認します。
7. 照会フィールドに kube_node_labels と入力し、Run Query をクリックします。

クラスター・アラート

クラスター・レベルでアラートを作成するためのしきい値の例を以下で確認してください。

• リージョンに含まれるすべてのワーカー・ノードが 80% のキャパシティーしきい値に達しようとしています。
• すべてのワーカー・ノードの 50% より多くが異常な状態になっています。
• アカウントあたりのファイル・ボリュームとブロック・ストレージ・ボリュームの最大数 (250) に達しようとしています。
• クラスターあたりのワーカー・ノードの最大数 (500) に達しようとしています。

アカウント・アラート

アカウントあたりのクラスターの最大数が制限に達しようとしている場合のアラートをセットアップできます。 例えば、リージョン/インフラストラクチャー・プロバイダーあたりで 100 にします。

Block Storage for VPC のアラート

Block Storage for VPC アラートでは、以下のメトリクスを使用できます：

• kubelet_volume_stats_available_bytes
• kubelet_volume_stats_capacity_bytes
• kubelet_volume_stats_inodes
• kubelet_volume_stats_inodes_free
• kubelet_volume_stats_inodes_used

1. Block Storage for VPC アラートのモニター・インスタンスを作成します。 Forwarding cluster and app metrics to IBM Cloud Monitoring の説明を参照してください。

2. syslog エージェントをインストールする。

   1. IBM Cloud コンソールで、メニューから 「プログラム識別情報」 を選択します。
   2. **「モニタリング」**を選択します。
   3. Block Storage for VPC アラートのインスタンスの行で、 「ダッシュボードを開く」 を選択します。
   4. メニューから、 「開始」 を選択します。
   5. 「エージェントのインストール」 セクションで、 「ソースの追加」 を選択します。
   6. 指示に従ってエージェントをインストールしてください。
   7. kubectl get pods -n CLUSTER_NAME | grep syslog コマンドを使用して、エージェントが実行されていることを確認します。

3. 通知チャネルを構成します。

   1. IBM Cloud モニター・ダッシュボードで、 「モニター操作」>「設定」 を選択します。
   2. 「通知チャネル (Notification Channels)」 > 「通知チャネルの追加 (Add Notification Channel)」 を選択し、使用可能な通知方法の 1 つを選択します。
   3. 新規チャネルの設定を完了し、 「保存」 をクリックします。
   4. オプション：チャンネルを追加するには、前の手順を繰り返します。

4. アラートを作成します。

   1. IBM Cloud モニター・ダッシュボードで、 「アラート」 > 「ライブラリー」 を選択します。
   2. いずれかのテンプレートを選択し、 「アラートの有効化」 を選択します。 例えば、 PVC storage を検索して、 PVC Storage Usage Is Reaching The Limit アラートを有効にすることができます。
   3. テンプレートのアラート設定をカスタマイズし、 「アラートの有効化」 を選択して設定を適用します。

Block Storage for VPC ボリュームが容量に達している場合は、 ボリューム拡張をセットアップ できます。

構成マップの構成要素について

ヘルス・チェックの個々の構成要素に関する以下の情報を参照してください。

• name: 構成名 ibm-worker-recovery-checks は定数であり、変更できません。
• namespace: kube-system 名前空間は定数であり、変更できません。
• checknode.json: 各ワーカー・ノードが Ready 状態であるかどうかを検査する Kubernetes API ノード検査を定義します。 特定のワーカー・ノードがReady 状態でない場合、そのワーカー・ノードの検査結果は失敗となります。 サンプル YAML では、検査が 3 分ごとに実行されます。 連続して 3 回失敗すると、ワーカー・ノードは再ロードされます。 この操作は、ibmcloud ks worker reload を実行することと同等です。 **「有効」**フィールドを false に設定するか、または検査を除去するまで、ノード検査は有効になります。 再ロードは、クラシック・インフラストラクチャーのワーカー・ノードでしかサポートされないことに注意してください。
• checkpod.json: ワーカー・ノード上の NotReady ポッドの合計パーセンテージを、そのワーカー・ノードに割り当てられた合計ポッド数に基づいて検査する、Kubernetes API ポッド検査を定義します。 NotReady ポッドの合計パーセンテージが、定義済みの PodFailureThresholdPercent より大きい場合、そのワーカー・ノードの検査結果は失敗となります。 サンプル YAML では、検査が 3 分ごとに実行されます。 連続して 3 回失敗すると、ワーカー・ノードは再ロードされます。 この操作は、ibmcloud ks worker reload を実行することと同等です。 例えば、デフォルト PodFailureThresholdPercent は 50% です。 NotReady ポッドのパーセンテージが 50% を 3 回連続して超えると、ワーカー・ノードが再ロードされます。 デフォルトでは、すべての名前空間で検査が実行されます。 指定した名前空間内のポッドのみに検査を限定するには、Namespaceフィールドを検査に追加します。 **「有効」**フィールドを false に設定するか、または検査を除去するまで、ポッド検査は有効になります。 再ロードは、クラシック・インフラストラクチャーのワーカー・ノードでしかサポートされないことに注意してください。
• checkhttp.json: ワーカー・ノードで稼働している HTTP サーバーが正常かどうかを検査する HTTP 検査を定義します。 このチェックを使用するには、 デーモン・セットを使用してクラスタ内のすべてのワーカー・ノードに HTTP サーバをデプロイする必要があります。 HTTP サーバーが正常かどうかを検証できるヘルス・チェックを、/myhealth パスで利用できるように実装する必要があります。 他のパスを定義するには、Route パラメーターを変更します。 HTTP サーバーが正常である場合は、ExpectedStatus で定義されている HTTP 応答コードを返す必要があります。 HTTP サーバーは、ワーカー・ノードのプライベート IP アドレスで listen するように構成する必要があります。 プライベート IP アドレスを調べるには、kubectl get nodes ノードを実行します。 例えば、プライベート IP アドレスが 10.10.10.1 および 10.10.10.2 の 2 つのノードがクラスターにあるとします。 この例では、http://10.10.10.1:80/myhealth および http://10.10.10.2:80/myhealth の 2 つのルートの 200 HTTP 応答を検査します。 サンプル YAML では、検査が 3 分ごとに実行されます。 連続して 3 回失敗すると、ワーカー・ノードはリブートされます。 この操作は、ibmcloud ks worker reboot を実行することと同等です。 **「有効」**フィールドを true に設定するまで、HTTP 検査は無効になります。

ヘルス・チェックの個々の構成要素について

ヘルス・チェックの個々の構成要素に関する以下の表を参照してください。