ACK クラスターでは、Alibaba Cloud Prometheus およびオープンソースの Prometheus の両方をサポートしています。事前に構成されたメトリクスが監視要件を満たさない場合は、カスタム PromQL 式を作成して、クラスターノード、ホスト、コンテナレプリカ、ワークロード向けのアラートルールを定義します。アラートルールは、メトリクスがしきい値を超えた場合、または特定の条件が満たされた場合に発火します。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
ACK クラスターで Prometheus モニタリングが有効化されていること。Alibaba Cloud Prometheus モニタリング(推奨)または オープンソースの Prometheus モニタリング を使用します。
カスタム PromQL を使用したアラートルールの設定
Alibaba Cloud Prometheus およびオープンソースの Prometheus の両方で、カスタム PromQL に基づくアラートルールをサポートしています。アラートルールの条件が満たされると、システムはアラートイベントを生成し、通知を送信します。
Alibaba Cloud Prometheus
カスタム PromQL を使用して Prometheus アラートルールを作成するには、「Prometheus アラートルールの作成」をご参照ください。
オープンソースの Prometheus
アラート通知ポリシーを設定します。オープンソースの Prometheus では、Webhook、DingTalk ロボット、メールによる通知をサポートしています。
receiverパラメーターを ack-prometheus-operator アプリケーションで設定することで、通知方法を指定します。詳細については、「アラート機能の設定」をご参照ください。アラートルールを作成します。アラートルールを定義するには、クラスター内に 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 に転送します:
bash kubectl port-forward svc/ack-prometheus-operator-prometheus 9090:9090 -n monitoringブラウザで
localhost:9090を開きます。ページ上部の ステータス > ルール を選択します。ルール ページに該当のアラートルールが表示された場合、そのルールは有効です。
アラートルールのリファレンス
複数のクラスターおよびアプリケーションにおける運用・保守 (O&M) 経験に基づき、ACK では以下のような推奨される Prometheus アラートルール構成を提供しています。これらのルールは、クラスターの安定性、ノードの異常、ノードのリソース使用量、コンテナレプリカの異常、ワークロードの異常、ストレージ例外、ネットワーク例外をカバーしています。
アラートルールでは、以下の重大度レベルを使用します。
重大:問題がクラスター、アプリケーション、またはお客様のビジネスに影響を及ぼす場合。即時の対応が必要です。
警告:問題がクラスター、アプリケーション、またはお客様のビジネスに影響を及ぼす場合。できる限り早期に調査してください。
通常:アラートが重要な機能変更に関連している場合。
ルール説明 列は、アラート ページの アラートルール タブを操作のエントリポイントとしています。アラートルールを更新するには、Container Service for Kubernetes (ACK) コンソール にログインし、クラスター リストから対象のクラスター名をクリックし、左側のナビゲーションウィンドウで 操作 > アラート を選択してから、アラートルール タブをクリックします。
異常なコンテナレプリカ
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルール説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| Pod のステータスが異常 | 重大 | min_over_time(sum by (namespace, pod, phase) (kube_pod_status_phase{phase=~"Pending|Unknown|Failed"})[5m:1m]) > 0 | > 0 | 5 分 | 過去 5 分間に Pod のステータスが異常(Pending、Unknown、Failed)の場合に発火します。操作のエントリポイントで、Pod 異常用のアラートルールセット をクリックし、Pod の異常 アラートルールを設定します。詳細については、「ACK におけるアラートの管理」をご参照ください。 | 「Pod の例外のトラブルシューティング」をご参照ください。 |
| Pod の起動に失敗 | 重大 | sum_over_time(increase(kube_pod_container_status_restarts_total{}[1m])[5m:1m]) > 3 | > 3 回の再起動 | 5 分 | 過去 5 分間に Pod の起動が 3 回以上失敗した場合に発火します。操作のエントリポイントで、Pod 異常用のアラートルールセット をクリックし、Pod の起動失敗 アラートルールを設定します。詳細については、「ACK におけるアラートの管理」をご参照ください。 | 「Pod の例外のトラブルシューティング」をご参照ください。 |
| 1,000 個以上の Pod がスケジュールできなかった | 重大 | sum(sum(max_over_time(kube_pod_status_phase{phase=~"Pending"}[5m])) by (pod)) > 1000 | > 1,000 個の Pod | 5 分 | 過去 5 分間にスケジューリング失敗により Pending ステータスとなった Pod が 1,000 個を超えた場合に発火します。 | これは、大規模クラスターにおける過剰なスケジューリング負荷を示している可能性があります。ACK マネージドクラスター Pro エディションでは、強化されたスケジューリング機能および SLA(サービスレベル合意)を提供しています。詳細については、「ACK マネージドクラスター Pro エディションの概要」をご参照ください。 |
| コンテナの CPU スロットルが頻繁に発生 | 警告 | rate(container_cpu_cfs_throttled_seconds_total[3m]) * 100 > 25 | > 25 % のスロットル時間 | 3 分 | 過去 3 分間でスロットルされた CPU 時間が総 CPU 時間の 25 % を超えた場合に発火します。CPU スロットルは、プロセスに割り当てられるタイムスライスを短縮するため、プロセスの実行時間が延長され、アプリケーションの処理速度が低下する可能性があります。 | Pod の CPU resource limit が低すぎるかどうかを確認してください。CPU Burst ポリシーを適用してスロットルを軽減します — 「CPU Burst ポリシーの有効化」をご参照ください。マルチコアノードでは、断片化された CPU リソースを最大限に活用するために、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 | >= 85 % の Pod 制限 | 1 分 | 指定された名前空間または指定された Pod の CPU 使用率が制限の 85 % を超えた場合に発火します。Pod に制限が設定されていない場合は、このルールは無効です。85 % のしきい値は推奨デフォルト値です — 必要に応じて調整してください。Pod または名前空間でフィルターを適用するには、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 | >= 85 % の Pod 制限 | — | Pod のメモリ使用率が制限の 85 % を超えた場合に発火します。Pod に制限が設定されていない場合は、このルールは無効です。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 の例外のトラブルシューティング」をご参照ください。 |
| Job の実行に失敗 | 重大 | kube_job_status_failed{} > 0 | > 0 | — | Job の実行に失敗した場合に発火します。操作のエントリポイントで、ワークロード例外用のアラートルールセット をクリックし、Job の実行失敗 アラートルールを設定します。詳細については、「ACK におけるアラートの管理」をご参照ください。 | Job の下にある失敗した Pod のログを確認して、エラーの詳細を取得してください。「Pod の例外のトラブルシューティング」をご参照ください。 |
ストレージ例外
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルール説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| PersistentVolume (PV) のステータスが異常 | 重大 | kube_persistentvolume_status_phase{phase=~"Failed|Pending"} > 0 | > 0 | — | PV が Failed または Pending ステータスになった場合に発火します。操作のエントリポイントで、ストレージ例外用のアラートルールセット をクリックし、PV の異常 アラートルールを設定します。詳細については、「ACK におけるアラートの管理」をご参照ください。 | 「ディスク PV の FAQ」のディスクマウントに関するセクションをご参照ください。 |
| ホストのディスク使用率が 85 % を超える | 重大 | (100 - node_filesystem_avail_bytes / node_filesystem_size_bytes * 100) >= 85 | >= 85 % | — | ノードのディスクブロックデバイスの空き領域が 10 % 未満になった場合に発火します。操作のエントリポイントで、リソース例外用のアラートルールセット をクリックし、ノード - ディスク使用率 >= 85 % アラートルールを設定します。詳細については、「ACK におけるアラートの管理」をご参照ください。 | ノードをスケールアウトするか、ディスク容量を拡張します。「ディスク PV の FAQ」をご参照ください。 |
異常なノードステータス
| 説明 | 重大度 | 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 ステータスが予期されたものか(例:ノードの交換や計画メンテナンスなど)を判断してください。予期されていない場合は、アプリケーションポッドへの影響を確認し、必要に応じてポッドを退避させてください。メモリ圧迫やディスクの満杯など、一般的な原因についてノードの状態を確認してください。 |
異常なホストリソース使用量
ホストリソースメトリクスは、ノードが実行される物理マシンまたは仮想マシンのリソースを測定します。使用率 = (ホスト上のすべてのプロセスのリソース使用量)/(ホストの最大容量)。
| 説明 | 重大度 | PromQL | しきい値 | ウィンドウ | ルール説明 | 一般的なトラブルシューティング |
|---|---|---|---|---|---|---|
| ホストのメモリ使用率が 85 % を超える | 警告 | (100 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) >= 85 | >= 85 % | — | ホストのメモリ使用率が 85 % を超えた場合に発火します。操作のエントリポイントで、リソース例外用のアラートルールセット をクリックし、ノード - メモリ使用率 >= 85 % アラートルールを設定します。詳細については、「ACK におけるアラートの管理」をご参照ください。85 % のしきい値は推奨デフォルト値です — 必要に応じて調整してください。 説明 ACK のアラート設定に含まれるルールは CloudMonitor によって提供されており、そのメトリクスは対応する Prometheus ルールのメトリクスと整合性があります。 | リソースを解放します:コスト分析機能を使用して、ポッドがスケジュール可能なリソースを不当に占有していないかを確認します(「コスト分析機能の有効化」をご参照ください)。また、リソースプロファイリングを使用してメモリ要求量を最適化します(「リソースプロファイリング」をご参照ください)。キャパシティを計画し、ノードをスケールアウトします — 「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 % を超えた場合に発火します。計算式:ノードのリソース使用量 / ノードの総割り当て可能リソース量。 | リソースを解放します:コスト分析機能(「コスト分析機能の有効化」をご参照ください)およびリソースプロファイリングを使用してポッドをノード間で分散させます(「リソースプロファイリング」をご参照ください)。ノードをスケールアウトします — 「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 % | — | スケジュール済みの Pod の総リソース要求量がノードの総割り当て可能リソース量の 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 % | — | スケジュール済みの Pod の総リソース制限量がノードの総割り当て可能リソース量の 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 % を超えた場合に発火します。計算式:ノードのリソース使用量 / ノードの総割り当て可能リソース量。 | リソースを解放します:コスト分析機能(「コスト分析機能の有効化」をご参照ください)およびリソースプロファイリングを使用してポッドをノード間で分散させます(「リソースプロファイリング」をご参照ください)。ノードをスケールアウトします — 「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 % | — | スケジュール済みの Pod の総リソース要求量がノードの総割り当て可能リソース量の 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 % | — | スケジュール済みの Pod の総リソース制限量がノードの総割り当て可能リソース量の 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 マネージドクラスター(Pro エディションおよび Basic エディション)でのみ検出可能です。 | クラスター内の CoreDNS ポッドが正常に実行されているかどうかを確認してください。 |
| CoreDNS の panic 例外 | 重大 | sum(rate(coredns_panic_count_total{}[3m])) > 0 | > 0 | 3 分 | ACK マネージドクラスター(Pro エディションおよび Basic エディション)でのみ検出可能です。 | クラスター内の CoreDNS ポッドが正常に実行されているかどうかを確認してください。 |
| Ingress コントローラー証明書の有効期限が 14 日以内に切れる | 警告 | ((nginx_ingress_controller_ssl_expire_time_seconds - time()) / 24 / 3600) < 14 | < 14 日 | — | ACK Ingress コントローラーコンポーネントが 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 の差分 | — | Horizontal Pod Autoscaler (HPA) の現在のレプリカ数が設定された最大値に達した場合に発火します。 説明 まず Alibaba Cloud Prometheus で | HPA ポリシーが期待通りに動作しているかどうかを確認してください。ワークロードが継続的に高い場合は、maxReplicas の値を増加させるか、アプリケーションのパフォーマンスを最適化してください。 |
次のステップ
コンソールまたは API を使用して Prometheus モニタリングデータを照会します:「PromQL を使用した Prometheus モニタリングデータの照会」。
コンテナネットワークの問題を特定および診断します:「KubeSkoop を使用したネットワーク問題の特定」。
Alibaba Cloud Prometheus の使用時に発生する一般的な問題:「可観測性に関する FAQ」。