すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:コンテナの可観測性に関するベストプラクティス

最終更新日:Mar 26, 2026

Container Service for Kubernetes (ACK) は、Alibaba Cloud の可観測性サービスと標準で統合されており、インフラストラクチャ、オペレーティングシステム、コンテナ/クラスター、アプリケーションという 4 つのレイヤーにわたるメトリクス、ログ、トレースを提供します。

image

推奨される可観測性構成では、クラスターの安定性を確保するための以下の 3 つの領域をカバーします:

  • コントロールプレーン — コア Kubernetes コンポーネントの健全性およびキャパシティ

  • データプレーン — ノードの健全性、ストレージ、ネットワークコンポーネント

  • アプリケーション — Pod のステータス、ログ、APM、トレーシング

可観測性信号の概要

次の表は、ACK における各信号タイプに対応するツールを示しています。

信号ツール対象範囲
コントロールプレーンのメトリクスManaged Service for Prometheuskube-apiserver、etcd、kube-scheduler、kube-controller-manager
コントロールプレーンのログSimple Log Service (SLS)マネージドクラスターのコンポーネント向け集中型ログストレージ
ノードイベントack-node-problem-detector + SLS イベントセンター90 日間の保持期間;1 分間隔でのチェック
ノードプロセスのメトリクスCloudMonitorノードごとのリソース消費量上位 5 プロセス
ノード OS のジャーナルログSLSkubelet、カーネル、コンテナエンジンのログ
コンテナ/Pod のメトリクスManaged Service for Prometheus(kubelet + kube-state-metrics)Pod ごとの CPU、メモリ、ネットワーク、ストレージ
コンテナストレージのメトリクスManaged Service for Prometheus + csi-pluginNAS、CPFS、OSS、ディスクボリューム
コンテナネットワークのメトリクスManaged Service for Prometheus(kubelet)Pod ごとのインバウンド/アウトバウンドトラフィック
アプリケーションログSLSstdout またはログファイルからの非侵入型ログ収集
APM/分散トレーシングApplication Real-Time Monitoring Service (ARMS)Java、Python、Go、OpenTelemetry
フロントエンド監視ARMS Real User Monitoring (RUM)Web、モバイル、ミニアプリ
GPU のメトリクスManaged Service for Prometheus + ack-gpu-exporterNVIDIA DCGM 互換メトリクス、共有 GPU および専有 GPU
カーネルレベルのコンテナ監視SysOMメモリ関連問題、ページキャッシュ、OS レベルの可視性
アラートACK アラート管理ノード、Pod、ワークロード、ネットワーク向け事前設定済みルールセット

クイックセットアップチェックリスト

各セクションに進む前に、以下のベースライン機能を有効化してください。

  1. ノードイベントの監視のために ack-node-problem-detector をデプロイします。

  2. クラスターおよびコンテナのメトリクス収集のために、Managed Service for Prometheus を有効化します。

  3. Pod およびコントロールプレーンコンポーネントからのログ収集のために、SLS を接続します。

  4. ノード、Pod、ワークロード、ネットワーク例外に対する アラートルールセット を設定します。

  5. ECS ノードプールで CloudMonitor プラグインを有効化し、ホストレベルのプロセスメトリクスを取得します。

イベント監視および Prometheus 監視を有効化した後、クラスターやアプリケーションを担当する担当者向けに連絡先および連絡先グループを設定し、対応するアラートルールを設定して、それらの連絡先グループへ通知オブジェクトをサブスクライブします。

1. クラスターインフラストラクチャのコントロールプレーン

image

コントロールプレーンは、API オペレーション、ワークロードのスケジューリング、Kubernetes リソースのリソースオーケストレーション、クラウドリソースのプロビジョニング、メタデータのストレージを処理します。主要なコンポーネントには、kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager、etcd が含まれます。

ACK は、サービスレベルアグリーメント(SLA)保証とともに、ACK マネージドクラスターのコントロールプレーンを完全に管理します。以下の機能により、コントロールプレーンの健全性をリアルタイムで確認できます。

コントロールプレーンコンポーネントの監視を有効化

ACK は、外部クライアントおよびクラスター内コンポーネント(例:Prometheus)がコントロールプレーンのメトリクスをスクレイプできるよう、Kubernetes の RESTful API を拡張しています。

コントロールプレーンコンポーネントのログを収集

ACK クラスターは、お客様の SLS プロジェクトへの集中型ログ記録をサポートしています。詳細については、「ACK マネージドクラスターのコントロールプレーンコンポーネントログの収集」をご参照ください。

アラート管理を設定

ACK には、コアコンテナの異常を検出するためのデフォルトルールが含まれています。ルールの追加またはカスタマイズを行うには、以下をご参照ください。

2. クラスターインフラストラクチャのデータプレーン

クラスターノード

ACK ワーカーノードは、ワークロード実行のためのリソース環境を提供します。Kubernetes には、一時的なノード障害への耐性を確保するための組み込み スケジューリング、プリエンプション、エビクション 機構がありますが、包括的な安定性を確保するには、ノードの状態およびリソース負荷に対する能動的な監視が必要です。

ack-node-problem-detector を使用したイベント監視

ack-node-problem-detector は、ACK のノード イベント監視 コンポーネントです。以下の機能を提供します。

  • アップストリーム Kubernetes Node Problem Detector との完全互換性

  • クラスターノード環境、OS 互換性、コンテナエンジン向けの ACK 固有の強化機能

  • 強化されたノード診断プラグイン(1 分間隔でのチェック)

  • 統合された kube-eventer Deployment を介した 90 日間のイベントデータ保持。これは、Kubernetes イベントを SLS イベントセンターにストリーミングすることで、etcd のデフォルト保持期間(1 時間)をバイパスします。

ack-node-problem-detector が異常なノード状態を検出した場合、kubectl describe node ${NodeName} を実行してノードの Condition を確認するか、ACK コンソールの [ノード] ページでノード一覧を表示します。

Pod の起動失敗および利用不可の Service エンドポイントに対してアラートを受信するには、アラート管理 を設定し、イベントベースの通知をサブスクライブします。SLS 監視でもイベントアラートをサポートしています。

サポートされるチェック項目:「ack-node-problem-detector による GPU 障害の検出」および「ノード診断プラグイン」をご参照ください。

クラスターノードの ECS プロセスレベル監視

各 ACK ノードは、ECS インスタンスに対応します。プロセス監視 機能を CloudMonitor で有効化すると、以下の情報を取得できます。

  • 履歴プロセス分析: メモリ消費量、CPU 使用率、オープンファイルディスクリプタ数の上位 5 プロセス

  • ホストレベルの OS 監視: CPU、メモリ、ネットワーク、ディスク使用率、inode 数、ネットワークトラフィック、同時接続数

重要

プロセス監視の設定は、ノードプールで CloudMonitor を有効化した後に追加されたノードにのみ適用されます。

ホストメトリクス vs. ノードメトリクス

両者はリソース使用量を測定しますが、範囲および計算方法が異なります。

ディメンションホストメトリクスノードメトリクス
範囲物理または仮想マシンのリソースコンテナエンジンのリソース
メモリ分子すべてのプロセスが使用する合計メモリ(Usage合計ワーキングメモリ(WorkingSet)、割り当てられたメモリ、使用中のメモリ、ページキャッシュを含む
メモリ分母ホストのメモリ容量(Capacity合計割り当て可能メモリ(Allocatable)、コンテナエンジン用に予約されたリソースを除く
計算式Usage / CapacityWorkingSet / Allocatable

詳細については、「リソース予約ポリシー」をご参照ください。

ノード異常に対するアラート管理

ノードの健全性に関するアラートルールセットを有効化し、サブスクライブします。

  • ノード例外アラートルールセット — 異常なノード状態

  • リソース例外アラートルールセット — リソース使用率しきい値の超過

これらの設定は、アラート管理 を通じて行います。

ノード OS ジャーナルログ監視

systemd は Linux ノード上の init システムおよびサービスマネージャーとして機能します。そのジャーナルコンポーネントは、システムログの収集、保存、リアルタイムクエリ、分析を提供します。

以下のようなシナリオで、OS ジャーナルログを SLS に収集・永続化します。

  • ノードの安定性監視(kubelet、OS カーネル)

  • OS やコンテナエンジンの変更に敏感なワークロード(特権モードで実行されるコンテナ、頻繁にリソース過剰割り当てが発生するノード、OS リソースを直接使用するワークロードなど)

詳細については、「ノードの systemd ジャーナルログの収集」をご参照ください。

GPU および AI ワークロード監視

AI トレーニングおよび機械学習タスク向けに、ACK は Pod レベルでの GPU の健全性監視およびリソース監視を提供します。

クラスターのデータプレーンシステムコンポーネント

コンテナストレージ

ACK は、以下のストレージタイプをサポートしています。

  • ローカルノードストレージ: システムディスク、データディスク、HostPath ボリューム(Kubernetes による監視対象外 — 手動監視が必要)、emptyDir ボリューム(一時的ストレージの Resource Requests および Limits を介して管理)。一時的ストレージ監視の対象には、tmpfs 以外の emptyDir ボリューム、ノード上の Pod ログファイル、Pod 内のすべてのコンテナの書き込み可能レイヤーが含まれます。

  • Secret/ConfigMap: クラスターリソースのメタデータとして使用;厳密なストレージ監視要件なし。

  • PersistentVolumes(PV)および PersistentVolumeClaims(PVC)を介した外部ストレージ: 追加マウントされたディスクボリューム、NAS(Network Attached Storage)ボリューム、Cloud Parallel File Storage(CPFS)ボリューム、Object Storage Service(OSS)ボリューム。

csi-plugin コンポーネントは、サポートされるすべてのストレージタイプの監視メトリクスを公開し、Managed Service for Prometheus がこれらをすぐに使えるダッシュボードに収集します。サポートおよび非サポートのストレージタイプの完全な概要については、「コンテナストレージ監視の概要」をご参照ください。

コンテナネットワーク

CoreDNS

CoreDNS は、クラスターの DNS サービス検出コンポーネントです。以下の項目を監視します。

  • データプレーンにおける CoreDNS のリソース使用量

  • レスポンス(rcode 別) メトリクス — NXDOMAIN、SERVFAIL、FormErr などの異常な解決応答コード

推奨される構成は以下のとおりです。

  • Managed Service for Prometheus ユーザー: 組み込みの CoreDNS 監視ダッシュボード をご利用ください。

  • セルフマネージド Prometheus ユーザー: コミュニティ版 CoreDNS 監視手法を用いてメトリクス収集を設定します。

  • アラート管理 を有効化し、以下をサブスクライブします。

    • ネットワーク例外アラートルールセット — CoreDNS 構成の再読み込み失敗およびステータス異常

    • Pod 例外アラートルールセット — CoreDNS Pod のステータスおよびリソース問題

  • CoreDNS ログの分析 を実施し、遅延した解決および高リスクドメイン要求を診断します。

Ingress

外部トラフィックのルーティングに Ingress を使用する場合、トラフィック量および呼び出しの詳細を監視し、異常なルーティング状態に対してアラートを発行します。

  • メトリクス監視: ACK Ingress コントローラーを備えた Managed Service for Prometheus を使用して、事前設定済みのトラフィックダッシュボードを活用します。「SLS を使用した Ingress ログの監視および分析」をご参照ください。

  • トレーシング: ACK の Ingress トレーシングを有効化し、NGINX Ingress コントローラーのテレメトリを Managed Service for OpenTelemetry に報告することで、リアルタイム集約、トポロジーのマッピング、および永続的なトレースストレージを実現します。「ALB Ingress トレースデータの Xtrace 有効化(Albconfig 経由)」をご参照ください。

  • アラート:アラート管理 を通じて、ネットワーク例外アラートルールセット をサブスクライブします。

基本的なコンテナネットワークトラフィック監視

ACK クラスターは、ノードの kubelet を介して コミュニティ標準のコンテナメトリクス を公開しており、Pod のインバウンドおよびアウトバウンドトラフィック、異常トラフィック検出、パケットレベルの監視をカバーします。

HostNetwork モードで構成された Pod は、ホストのプロセスネットワーク挙動を継承します。この場合、基本的なコンテナ監視メトリクスは、Pod レベルのネットワークトラフィックを正確に反映しません。

監視オプションは以下のとおりです。

3. ユーザーアプリケーション

コンテナ Pod 監視

Pod は、ACK におけるアプリケーションデプロイの基本単位です。そのステータスおよびリソース消費量は、アプリケーションのパフォーマンスに直接影響します。

  • Prometheus ベースの Pod メトリクス: Managed Service for Prometheus またはセルフマネージド Prometheus を使用して、ノードの kubelet から コミュニティ標準のコンテナメトリクス を収集します。さらに、Managed Service for Prometheus または ACK 提供の prometheus-operator Helm チャートに含まれる kube-state-metrics を併用することで、CPU、メモリ、ストレージ、ネットワークを含む包括的な Pod メトリクスを取得できます。Managed Service for Prometheus と統合された ACK クラスターには、すぐに使える Pod 監視ダッシュボードが含まれます。

  • Pod 異常のイベント監視: Pod ステータスの変更はイベントをトリガーします。異常な状態(OOM キル、Ready にならない Pod など)を追跡するために、イベント監視 を有効化します。リアルタイムデータは イベントセンター ページで確認でき、履歴データは SLS(90 日間保持)で確認できます。Pod イベント監視ダッシュボードを通じて、Pod のライフサイクルタイムラインを分析します。

  • アラートのサブスクリプション:アラート管理 および イベント監視 を有効化した後、以下をサブスクライブします。「Prometheus におけるアラートルール設定のベストプラクティス」をご参照ください。

    • ワークロード例外アラートルールセット

    • Pod 例外アラートルールセット

  • カスタム Prometheus アラートルール: アプリケーション固有のしきい値向けにカスタムルールを作成します。「Prometheus インスタンス向けアラートルールの作成」をご参照いただき、Pod の異常 からサンプル PromQL を活用してください。

コンテナアプリケーションログ監視

ACK は、アプリケーション Pod に対する非侵入型ログ収集を提供します。「ACK クラスターにおけるアプリケーションログの収集」を行い、SLS のログ分析機能を活用して異常診断および運用状況評価を行います。

ビジネスアプリケーションがログファイルの分割を実装していない場合は、Pod の stdout ログを使用します。

細かい粒度のメモリ監視

Kubernetes では、コンテナのリアルタイムメモリ使用量は Working Set Size(WSS)によって測定されます。これは、Kubernetes がスケジューリングおよびリソース割り当てに使用するメトリクスです。WSS には以下の要素が含まれます。

  • アクティブな OS カーネルメモリコンポーネント(非アクティブな匿名メモリを除く)

  • OS レイヤーのメモリコンポーネント

image.png

異常な WSS の増加は、PodOOMKilled イベントやノードレベルのメモリ圧迫および Pod のエビクションを引き起こす可能性があります。Log4J や Logback を使用する Java アプリケーションで、デフォルトの new I/O(NIO)およびメモリマップドファイル(mmap)構成を採用している場合に見られる共通パターンは以下のとおりです。

  • 匿名メモリの急増 — 大量のログ出力下での頻繁な読み取り/書き込み操作によるもの

  • メモリ割り当てのブラックホール — 見えない WSS の増加を引き起こす

ACK は、SysOM を基盤としたカーネルレベルのコンテナ監視 を提供し、OS レイヤーのメモリ詳細を明らかにします。「SysOM を用いたコンテナメモリ問題の観察および解決」をご参照ください。

カスタムアプリケーションメトリクスの統合

チームがアプリケーションコードを作成している場合、Prometheus クライアント を使用して、イベントトラッキングを通じてビジネス固有のメトリックを公開します。これらのメトリックを Prometheus で収集および可視化し、インフラストラクチャチームおよびアプリケーションチーム向けの統合ダッシュボードを構築することで、インシデント対応の迅速化と平均復旧時間(MTTR)の短縮を実現します。

APM および分散トレーシング

Application Real-Time Monitoring Service(ARMS)は、複数のランタイム向けアプリケーションパフォーマンスモニタリング(APM)を提供します。アプリケーションの言語に応じて、統合方法を選択してください。

言語インストルメンテーション方式機能設定方法
Java非侵入型(コード変更不要)アプリケーショントポロジー、3D 依存関係マップ、インターフェイス/JVM 監視、例外および遅延トランザクションのキャプチャJava アプリケーション監視
Python侵入型(コードにインストルメンテーションを追加)Django/Flask/FastAPI 対応;LlamaIndex/Langchain AI/LLM トレーキング;トポロジー、トレース、API 診断ack-onepilot をインストールし、Dockerfile を調整します。「Python アプリケーション監視」をご参照ください。
Goバイナリインストルメンテーションアプリケーショントポロジー、データベースクエリ分析、API 呼び出し監視ack-onepilot をインストールし、instgo を用いてコンパイルします。「Go アプリケーション監視」をご参照ください。
OpenTelemetry侵入型エンドツーエンドの分散トレーシング、リクエスト分析、トポロジーおよび依存関係分析OpenTelemetry 向けマネージドサービス — 言語固有の設定については、「統合ガイド」をご参照ください。

フロントエンド監視

外部ユーザーにサービスを提供する Web アプリケーション、モバイルアプリ、ミニアプリの場合、ARMS の リアルユーザーモニタリング(RUM) 機能を有効化します。RUM は以下の機能を提供します。

  • ユーザーインタラクションフローの完全な再構築

  • パフォーマンスメトリクス:ページ読み込み速度および API リクエストトレーシング

  • 障害分析:JavaScript エラーおよびネットワーク障害

  • 安定性監視:JavaScript 読み込みエラー、クラッシュ、アプリケーション応答なし(ANR)エラー

  • ログ相関による根本原因診断の高速化

開始するには、「アプリケーションを統合する」をご参照ください。

サービスメッシュの可観測性

Alibaba Cloud Service Mesh(ASM) は、オープンソース Istio と互換性のあるフルマネージドサービスメッシュプラットフォームです。トラフィックのルーティングおよび分割、サービス間通信のセキュリティ保護、メッシュの可観測性を提供し、開発および運用保守のオーバーヘッドを削減します。

ASM は、以下の 3 つの運用フェーズにわたるフルライフサイクルの可観測性をサポートします。

フェーズ焦点
Day 0(計画)システムリリース時のトラフィック構成状態の検証
Day 1(デプロイメント)マイクロサービス間のリアルタイムトラフィック配分の監視
Day 2(メンテナンス)サービスレベル目的(SLO)メトリクスに基づく安定性の強制

ASM は、統合テレメトリパイプラインを通じて、統一された サービスメッシュの可観測性機能 を提供します。

マルチクラウドおよびハイブリッドクラウドの可観測性

Distributed Cloud Container Platform for Kubernetes(ACK One) は、Alibaba Cloud のハイブリッドクラウド、マルチクラスター管理、分散コンピューティング、ディザスタリカバリ向けエンタープライズプラットフォームです。以下の機能を提供します。

  • 任意のリージョンまたはインフラストラクチャにまたがるインフラストラクチャ横断のクラスター管理

  • コンピューティング、ネットワーク、ストレージ、セキュリティ、モニタリング、ロギング、ジョブ、アプリケーション、トラフィックの統一ガバナンス

  • シームレスな統合を実現するコミュニティ準拠の API

ACK One 登録済みクラスターの可観測性

ACK One 登録済みクラスターは、SLSイベントセンターアラートARMSManaged Service for Prometheus との連携など、標準 ACK クラスターと同じ可観測性機能を提供します。

登録済みクラスターでは、異種ネットワーク環境および権限システムのため、追加のネットワーク構成および権限付与が必要です。

ACK One Fleet のグローバル監視

ACK One Fleet は、グローバル集約インスタンス を通じて、複数のクラスターから Prometheus メトリクスを集約し、統一モニタリングダッシュボードを提供します。これにより、クラスター間での手動メトリクス比較が不要になります。ACK One Fleet インスタンスを作成し、2 つのクラスターを関連付けた後、グローバル監視 を有効化します。

統一アラート管理

すべての関連クラスターに一貫性を保証するため、Fleet レベルでアラートルールを管理します。

  • 集中ルール管理:Fleet レベルでアラートルールを作成または更新し、自動的に関連クラスターへ同期します。

  • 差別化アラート:個々のクラスターが異なるしきい値を必要とする場合、クラスター固有のアラートルールを設定します。

GitOps の可観測性

Argo Workflows 監視

Argo Workflows は、バッチデータ処理、機械学習パイプライン、インフラストラクチャ自動化、CI/CD のためのクラウドネイティブワークフローエンジンです。ACK 上で Argo Workflows をデプロイする場合、または 分散 Argo ワークフロー向け Kubernetes クラスター を使用する場合、以下の機能を有効化します。

  • SLS を使用したログ永続化: ネイティブ Kubernetes の GC は、リソースのクリーンアップ後に Pod およびワークフローログをパージします。SLS をワークフローコンポーネントと統合 し、ワークフロー実行中に生成されたログを収集・永続化します。ワークフローログは Argo CLI または Argo UI から閲覧可能です。

  • Prometheus 監視:Managed Service for Prometheus の有効化 を行い、ワークフローの実行状態およびクラスターの健全性を監視します。

Knative アプリケーションの可観測性

ACK Knative は、コミュニティ版 Knative を基盤とした ACK のサーバーレスフレームワークです。Knative は、リクエスト駆動型のオートスケーリング(ゼロスケールを含む)およびカナリアロールアウトを伴うバージョン管理を提供します。ACK Knative は、インスタンスの保持によるコールドスタート遅延の低減および Advanced Horizontal Pod Autoscaler(AHPA)を活用したワークロード予測といった機能を追加しています。「Knative の可観測性」をご参照ください。