カスタム PromQL アラートルールを作成して、クラスターノード、ホスト、コンテナレプリカ、ワークロードをモニタリングします。
前提条件
開始する前に、以下の条件を満たしていることを確認してください:
-
ご利用の Container Service for Kubernetes (ACK) クラスターで Prometheus モニタリングが有効化されていること。Alibaba Cloud Prometheus モニタリング (推奨) または オープンソース Prometheus モニタリング を使用します。
カスタム PromQL を使用したアラートルールの設定
Alibaba Cloud Prometheus とオープンソース Prometheus はどちらも、条件が満たされたときに通知をトリガーする、カスタム PromQL ベースのアラートルールをサポートしています。
Alibaba Cloud Prometheus
カスタム PromQL を使用して Prometheus アラートルールを作成する方法については、「Prometheus アラートルールの作成」をご参照ください。
オープンソース Prometheus
-
アラート通知ポリシーを設定します。オープンソース Prometheus は、Webhook、DingTalk、およびメールをサポートしています。ack-prometheus-operator の
receiverパラメーターを介して通知方法を設定します。詳細については、「アラート設定」をご参照ください。 -
アラートルールを作成します。クラスターに PrometheusRule CRD をデプロイして、アラートルールを定義します (詳細については、「Prometheus ルールのデプロイ」をご参照ください)。次の例では、ノードの CPU 使用率が 2 分間のウィンドウで 90% を超えるとアラートが発動します。
exprフィールドは、PromQL 式とトリガー条件を指定します。apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: labels: # ラベルは Prometheus CRD の ruleSelector.matchLabels と一致する必要があります。 prometheus: example role: alert-rules name: prometheus-example-rules spec: groups: - name: example.rules rules: - alert: ExampleAlert # expr: PromQL クエリとトリガー条件。 # 以下の表のアラートルールの PromQL 設定列をご参照ください。 expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) > 90 -
アラートルールがアクティブであることを確認します。
-
次のコマンドを実行して、Prometheus サービスをご利用のローカルマシンのポート 9090 に転送します:
kubectl port-forward svc/ack-prometheus-operator-prometheus 9090:9090 -n monitoring -
ブラウザで
localhost:9090を開きます。 -
[ステータス] > [ルール] を選択します。アラートルールが [ルール] ページに表示される場合、そのルールはアクティブです。
-
アラートルールリファレンス
ACK は、運用保守経験に基づいた推奨アラートルールを提供します。これらは、クラスターの安定性、ノードとホストのリソース使用量、コンテナレプリカ、ワークロード、ストレージ、およびネットワーキングをカバーしています。
重大度レベル:
-
緊急:クラスター、アプリケーション、またはビジネスに影響を与えます。即時の対応が必要です。
-
警告:クラスター、アプリケーション、またはビジネスに影響を与えます。迅速に調査する必要があります。
-
通常: 重要な機能変更を示します。
[ルール説明] 列は、[アラート] ページの [アラートルール] タブをエントリポイントとして使用します。 アクセスするには、ACK コンソールにログインし、[クラスター] リストで対象のクラスターをクリックして、[オペレーション] > [アラート] > [アラートルール] の順に選択します。
コンテナレプリカの異常
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルールの説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| Pod の異常ステータス | 重大 | min_over_time(sum by (namespace, pod, phase) (kube_pod_status_phase{phase=~"Pending|Unknown|Failed"})[5m:1m]) > 0 |
> 0 | 5 分 | Pod が 5 分間 Pending、Unknown、または Failed ステータスに留まった場合に発生します。[Pod 例外のアラートルールセット] > [Pod アノマリー] で設定します。詳細については、「ACK のアラートを管理する」をご参照ください。 | 詳細については、「Pod の例外のトラブルシューティング」をご参照ください。 |
| Pod の起動失敗 | 重大 | sum_over_time(increase(kube_pod_container_status_restarts_total{}[1m])[5m:1m]) > 3 |
> 3 回の再起動 | 5 分 | Pod の例外用アラートルールセットポッドの起動失敗Pod が 5 分以内に 3 回以上再起動した場合に発動します。 > で設定します。詳細については、「ACK でのアラート管理」をご参照ください。 | 詳細については、「Pod の例外のトラブルシューティング」をご参照ください。 |
| 10 分間連続で 1,000 を超える Pod のスケジューリングに失敗 | 重大 | count((min_over_time(kube_pod_status_phase{phase="Pending"}[10m]) == 1) and (count_over_time(kube_pod_status_phase{phase="Pending"}[10m:15s]) >= (10 * 4 - 1))) > 1000 |
> 1,000 Pod | 10 分 | スケジューリングの失敗により、1,000 を超える Pod が 10 分間以上 Pending 状態のままである場合に発動します。 | 過度のスケジューリングプレッシャーを示している可能性があります。ACK プロ版は、強化されたスケジューリングと SLA を提供します。詳細については、「ACK マネージドクラスタープロ版の概要」をご参照ください。 |
| コンテナの頻繁な CPU スロットリング | 警告 | rate(container_cpu_cfs_throttled_seconds_total[3m]) * 100 > 25 |
> 25% のスロットリング時間 | 3 分 | スロットリングされた CPU 時間が 3 分間で 25% を超えると発動します。スロットリングはタイムスライスを減らし、プロセスのランタイムを増加させ、アプリケーションロジックを遅くします。 | Pod の CPU resource limit が低すぎないか確認してください。CPU Burst ポリシーを使用してスロットリングを減らします。マルチコアノードでは、CPU トポロジー対応スケジューリングを使用して、フラグメント化された CPU リソースを最大限に活用します。 |
| Pod の CPU 使用率 > 制限の 85% | 警告 | (sum(irate(container_cpu_usage_seconds_total{pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*",container!="",container!="POD"}[1m])) by (namespace,pod) / sum(container_spec_cpu_quota{pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*",container!="",container!="POD"}/100000) by (namespace,pod) * 100 <= 100 or on() vector(0)) >= 85 |
>= Pod 制限の 85% | 1 分 | Pod の CPU がその制限の 85% を超えると発動します。制限が設定されていない場合は効果がありません。デフォルトのしきい値は 85% です。必要に応じて調整してください。フィルタリングするには、pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*" を実際の値に置き換えます。フィルターを削除すると、すべての Pod をクエリします。 |
高い CPU 使用率はスロットリングを引き起こし、タイムスライスを減少させます。CPU resource limit が低すぎないか確認してください。詳細については、「CPU Burst ポリシーの有効化」および「CPU トポロジー対応スケジューリングの有効化」をご参照ください。 |
| Pod のメモリ使用量 > 制限の 85% | 警告 | ((sum(container_memory_working_set_bytes{pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*",container!="",container!="POD"}) by (pod,namespace) / sum(container_spec_memory_limit_bytes{pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*",container!="",container!="POD"}) by (pod, namespace) * 100) <= 100 or on() vector(0)) >= 85 |
>= Pod 制限の 85% | — | Pod のメモリがその制限の 85% を超えると発動します。制限が設定されていない場合は効果がありません。デフォルトのしきい値は 85% です。必要に応じて調整してください。 | 高いメモリ使用量は OOM 強制終了をトリガーし、Pod の再起動を引き起こす可能性があります。メモリの resource limit が低すぎないか確認してください。リソースプロファイリングを使用して制限を適切なサイズに調整します。 |
ワークロードの異常
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルールの説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| Deployment のレプリカの不一致 | クリティカル | kube_deployment_spec_replicas{} != kube_deployment_status_replicas_available{} |
不一致 | — | 利用可能な Deployment のレプリカ数が期待される数と一致しない場合にトリガーされます。設定は、[ワークロード例外のアラートルールセット] > [Deployment Pod のアノマリー] で行います。詳細については、ACK でのアラート管理をご参照ください。 | Pod の例外のトラブルシューティングをご参照ください。 |
| DaemonSet のレプリカの不一致 | クリティカル | ((100 - kube_daemonset_status_number_ready{} / kube_daemonset_status_desired_number_scheduled{} * 100) or (kube_daemonset_status_desired_number_scheduled{} - kube_daemonset_status_current_number_scheduled{})) > 0 |
> 0 | — | 利用可能な DaemonSet のレプリカ数が期待される数と一致しない場合にトリガーされます。設定は、[ワークロード例外のアラートルールセット] > [DaemonSet Pod のアノマリー] で行います。詳細については、ACK でのアラート管理をご参照ください。 | Pod の例外のトラブルシューティングをご参照ください。 |
| DaemonSet のスケジューリングエラー | クリティカル | kube_daemonset_status_number_misscheduled{job} > 0 |
> 0 | — | DaemonSet のレプリカが不適切なノードで実行されている場合にトリガーされます。設定は、[ワークロード例外のアラートルールセット] > [DaemonSet Pod のスケジューリングエラー] で行います。詳細については、ACK でのアラート管理をご参照ください。 | Pod の例外のトラブルシューティングをご参照ください。 |
| ジョブの失敗 | クリティカル | kube_job_status_failed{} > 0 |
> 0 | — | ジョブが失敗した場合にトリガーされます。設定は、[ワークロード例外のアラートルールセット] > [ジョブ実行の失敗] で行います。詳細については、ACK でのアラート管理をご参照ください。 | 失敗した Pod のログでエラー詳細を確認してください。Pod の例外のトラブルシューティングをご参照ください。 |
ストレージの例外
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルールの説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| 永続ボリューム (PV) の状態異常 | クリティカル | kube_persistentvolume_status_phase{phase=~"Failed|Pending"} > 0 |
> 0 | — | PV が Failed または Pending 状態になると発行されます。 [ストレージ例外のアラートルールセット] > [PV アノマリー] で設定します。 詳細は、「ACK でのアラートの管理」をご参照ください。 | 「ディスク PV に関するよくある質問」のディスクマウントのセクションをご参照ください。 |
| ホストのディスク使用率 > 85% | クリティカル | (100 - node_filesystem_avail_bytes / node_filesystem_size_bytes * 100) >= 85 |
>= 85% | — | ノードディスクの空き領域が 15% 未満になると発行されます。 [リソース例外のアラートルールセット] > [ノード - ディスク使用率 >= 85%] で設定します。 詳細は、「ACK でのアラートの管理」をご参照ください。 | ノードをスケールアウトするか、そのディスクを拡張します。 詳細は、「ディスク PV に関するよくある質問」をご参照ください。 |
ノードの異常ステータス
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルールの説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| ノードが 3 分間 NotReady | クリティカル | (sum(max_over_time(kube_node_status_condition{condition="Ready",status="true"}[3m]) <= 0) by (node)) or (absent(kube_node_status_condition{condition="Ready",status="true"})) > 0 |
> 0 | 3 分 | ノードが 3 分間 NotReady 状態のままの場合に発生します。[ノード例外のアラートルールセット] > [ノードがスケジュール不可状態に変わる] で設定します。詳細については、「ACK でのアラートの管理」をご参照ください。 | NotReady が予期されたものか (例えば、ノードの交換やメンテナンスなど) を判断します。予期しない場合は、アプリケーション Pod が影響を受けているか確認し、必要に応じて退避させます。メモリプレッシャーやディスクフルなどの原因についてノードの状態を確認します。 |
ホストリソースの異常な使用量
ホストリソースメトリックは、物理マシンまたは仮想マシンのリソースを測定します。使用量 = すべてのプロセスのリソース使用量 / ホストの最大容量。
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルールの説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| ホストのメモリ使用量 > 85% | 警告 | (100 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) >= 85 |
>= 85% | — |
ホストのメモリ使用量が 85% を超えると発動します。
[リソース例外のアラートルールセット]
>
[ノード - メモリ使用量 >= 85%]
で設定します。詳細については、
ACK でのアラート管理
をご参照ください。デフォルトのしきい値は 85% です。必要に応じて調整してください。
説明
ACK のアラートルールは CloudMonitor によって提供され、メトリックは Prometheus のルールと一致しています。 |
コスト分析リソースを解放します:で Pod のリソース割り当てを確認し、リソースプロファイリングでメモリリクエストを適切なサイズに調整します。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
| ホストのメモリ使用量 > 90% | 重大 | (100 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) >= 90 |
>= 90% | — | ホストのメモリ使用量が 90% を超えると発動します。 | コスト分析とリソースプロファイリングでリソースを解放します。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
| ホストの CPU 使用率 > 85% | 警告 | 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) >= 85 |
>= 85% | 2 分 |
ホストの CPU 使用率が 85% を超えると発動します。
[リソース例外のアラートルールセット]
>
[ノード - CPU 使用率 >= 85%]
で設定します。
説明
ACK は CloudMonitor ECS メトリックを使用しており、これはこの Prometheus ルールと同等です。デフォルトのしきい値は 85% です。必要に応じて調整してください。詳細については、「ACK でのアラート管理」をご参照ください。 |
コスト分析とリソースプロファイリングでリソースを解放します。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
| ホストの CPU 使用率 > 90% | 重大 | 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) >= 90 |
>= 90% | 2 分 | ホストの CPU 使用率が 90% を超えると発動します。 | コスト分析とリソースプロファイリングでリソースを解放します。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
ノードリソースの異常
ノードリソースメトリックは、物理マシンの容量ではなく、ノードの割り当て可能容量に対するコンテナリソースの消費量を測定します。
消費リソース (分子):ワーキングセットメモリ、ページキャッシュなどを含む、ノード上のすべてのコンテナの総リソース。
割り当て可能リソース (分母):ノードの予約分を差し引いた後、コンテナが利用できるリソース。詳細については、「ノードリソース予約ポリシー」をご参照ください。
Pod のスケジューリングは、実際のリソース使用量ではなく、リソースリクエストに基づいています。
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルールの説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| ノードの CPU 使用率 > 85% | 警告 | sum(irate(container_cpu_usage_seconds_total{pod!=""}[1m])) by (node) / sum(kube_node_status_allocatable{resource="cpu"}) by (node) * 100 >= 85 |
>= 85% | 1 分 | ノードの CPU 使用率が割り当て可能リソースの 85% を超えると発動します。計算式:ノードのリソース使用量 / ノードの総割り当て可能リソース。 | コスト分析とリソースプロファイリングを使用してリソースを解放し、Pod をノード間に分散させます。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
| ノードの CPU リソース割り当て率 > 85% | 正常 | (sum(sum(kube_pod_container_resource_requests{resource="cpu"}) by (pod, node) * on (pod) group_left max(kube_pod_status_ready{condition="true"}) by (pod, node)) by (node)) / sum(kube_node_status_allocatable{resource="cpu"}) by (node) * 100 >= 85 |
>= 85% | — | CPU リソースの割り当て率が割り当て可能リソースの 85% を超えると発動します。計算式:スケジュールされた Pod の総リソースリクエスト / ノードの総割り当て可能リソース。 | これ以上 Pod をスケジュールするためのリソースが不足しています。コスト分析とリソースプロファイリングでリソースの無駄 (実際のリソース使用量がリクエストを大幅に下回る) がないか確認してください。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
| ノードの CPU オーバーコミット率 > 300% | 警告 | (sum(sum(kube_pod_container_resource_limits{resource="cpu"}) by (pod, node) * on (pod) group_left max(kube_pod_status_ready{condition="true"}) by (pod, node)) by (node)) / sum(kube_node_status_allocatable{resource="cpu"}) by (node) * 100 >= 300 |
>= 300% | — | CPU のオーバーコミット率が割り当て可能リソースの 300% を超えると発動します。計算式:スケジュールされた Pod の総リソース制限 / ノードの総割り当て可能リソース。300% のしきい値は推奨されるデフォルト値です。必要に応じて調整してください。 | CPU の総制限が割り当て可能リソースを大幅に超えています。トラフィックのピーク時には、競合とスロットリングによって応答が遅くなる可能性があります。コスト分析とリソースプロファイリングを使用して CPU のリクエストと制限を適切なサイズに調整します。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
| ノードのメモリ使用量 > 85% | 警告 | sum(container_memory_working_set_bytes{pod!=""}) by (node) / sum(kube_node_status_allocatable{resource="memory"}) by (node) * 100 >= 85 |
>= 85% | — | ノードのメモリ使用量が割り当て可能リソースの 85% を超えると発動します。計算式:ノードのリソース使用量 / ノードの総割り当て可能リソース。 | コスト分析とリソースプロファイリングを使用してリソースを解放し、Pod をノード間に分散させます。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
| ノードのメモリリソース割り当て率 > 85% | 正常 | (sum(sum(kube_pod_container_resource_requests{resource="memory"}) by (pod, node) * on (pod) group_left max(kube_pod_status_ready{condition="true"}) by (pod, node)) by (node)) / sum(kube_node_status_allocatable{resource="memory"}) by (node) * 100 >= 85 |
>= 85% | — | メモリリソースの割り当て率が割り当て可能リソースの 85% を超えると発動します。計算式:スケジュールされた Pod の総リソースリクエスト / ノードの総割り当て可能リソース。 | これ以上 Pod をスケジュールするためのリソースが不足しています。コスト分析とリソースプロファイリングでリソースの無駄 (実際のリソース使用量がリクエストを大幅に下回る) がないか確認してください。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
| ノードのメモリオーバーコミット率 > 300% | 警告 | (sum(sum(kube_pod_container_resource_limits{resource="memory"}) by (pod, node) * on (pod) group_left max(kube_pod_status_ready{condition="true"}) by (pod, node)) by (node)) / sum(kube_node_status_allocatable{resource="memory"}) by (node) * 100 >= 300 |
>= 300% | — | メモリのオーバーコミット率が割り当て可能リソースの 300% を超えると発動します。計算式:スケジュールされた Pod の総リソース制限 / ノードの総割り当て可能リソース。300% のしきい値は推奨されるデフォルト値です。必要に応じて調整してください。 | メモリの総制限が割り当て可能リソースを大幅に超えています。トラフィックのピーク時には、メモリがノードの制限に達し、ワークロードを中断させる OOM 強制終了をトリガーする可能性があります。コスト分析とリソースプロファイリングを使用してメモリのリクエストと制限を適切なサイズに調整します。ノードをスケールアウトします。詳細については、「ACK クラスター内のノードのスケーリング」をご参照ください。 |
ネットワークの例外
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルールの説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| CoreDNS のリクエスト数がゼロに低下 | 重大 | (sum(rate(coredns_dns_request_count_total{}[1m]))by(server,zone)<=0) or (sum(rate(coredns_dns_requests_total{}[1m]))by(server,zone)<=0) |
<= 0 | 1 分 | ACK マネージドクラスター (プロ版およびベーシック版) でのみ検出可能です。 | クラスター内の CoreDNS Pod が正常に実行されているか確認してください。 |
| CoreDNS パニック例外 | 重大 | sum(rate(coredns_panic_count_total{}[3m])) > 0 |
> 0 | 3 分 | ACK マネージドクラスター (プロ版およびベーシック版) でのみ検出可能です。 | クラスター内の CoreDNS Pod が正常に実行されているか確認してください。 |
| Ingress コントローラーの証明書が 14 日以内に有効期限切れ | 警告 | ((nginx_ingress_controller_ssl_expire_time_seconds - time()) / 24 / 3600) < 14 |
< 14 日 | — | Ingress 機能が有効になっている ACK Ingress コントローラーコンポーネントがインストールされている必要があります。 | Ingress コントローラーの証明書を再発行してください。 |
Auto Scaling の例外
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルールの説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| HPA のレプリカ数が最大値に到達 | 警告 | max(kube_horizontalpodautoscaler_spec_max_replicas) by (namespace, horizontalpodautoscaler) - max(kube_horizontalpodautoscaler_status_current_replicas) by (namespace, horizontalpodautoscaler) <= 0 |
<= 0 の差 | — |
HPA の現在のレプリカ数が設定された最大値に達した場合に発動します。
説明
|
HPA ポリシーが期待どおりか確認してください。ワークロードが高いままである場合は、maxReplicas を増やすか、アプリケーションのパフォーマンスを最適化します。 |
次のステップ
-
コンソールまたは API から Prometheus データをクエリする:PromQL を使用した Prometheus モニタリングデータのクエリ。
-
コンテナネットワークの問題を特定する:KubeSkoop を使用してネットワークの問題を特定する。
-
Alibaba Cloud Prometheus の一般的な問題: 可観測性に関するよくある質問