Container Service for Kubernetes:可観測性に関するよくある質問

症状

ACK クラスターのコンテナーログを収集するの手順に従っても、Simple Log Service コンソールの[プレビュー] ページでログが見つからない場合は、ログ収集が失敗した可能性があります。この問題をトラブルシューティングするには、構成、収集コンポーネントとノードのステータス、およびログ収集コンテナーの操作ログを確認してください。

事前準備

コンテナファイルからログを収集する際は、次の点にご注意ください。

• ログ収集コンポーネントは増分ログのみを収集します。Logtail 構成を適用した後にログファイルが更新されない場合、コンポーネントはそのファイルからログを収集しません。詳細については、「ログの読み取り」をご参照ください。

• デフォルトのコンテナストレージを使用するか、ローカルパスにマウントされているファイルからのみログを収集できます。他のストレージ方法はサポートされていません。

• ログが収集された後、Logstore でログをクエリして分析する前にインデックスを作成する必要があります。詳細については、「インデックスの作成」をご参照ください。

ステップ 1：収集構成の確認

Logtail 構成が正しいことを確認します。すべてのログ収集設定が正確であり、コンテナが継続的にログを生成していることを確認してください。

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  # リソース名を設定します。現在の Kubernetes クラスター内で一意である必要があります。この名前は、作成された収集構成にも使用されます。名前が重複している場合、構成は有効になりません。
  name: example-k8s-file
spec:
  # 宛先プロジェクトを指定します。
  project:
    name: k8s-log-<YOUR_CLUSTER_ID>
  logstores:
    # k8s-file という名前の Logstore を作成します。
    - name: k8s-file
  # 収集構成を定義します。
  config:
    # ログサンプル (オプション)。
    sample: |
      2024-06-19 16:35:00 INFO test log
      line-1
      line-2
      end
    # 入力プラグインを定義します。
    inputs:
      # input_file プラグインを使用して、コンテナから複数行のテキストログを収集します。
      - Type: input_file
        # コンテナ内のファイルパス。
        FilePaths:
          - /data/logs/app_1/**/test.LOG
        # コンテナ検出機能を有効にします。
        EnableContainerDiscovery: true
        # コンテナ情報フィルター条件を追加します。複数のオプション間の関係は「AND」です。
        CollectingContainersMeta: true
        ContainerFilters:
          # 収集対象のコンテナが配置されている Pod の名前空間を指定します。正規表現によるマッチングがサポートされています。
          K8sNamespaceRegex: default
          # 収集対象のコンテナの名前を指定します。正規表現によるマッチングがサポートされています。
          IncludeK8sLabel:
            app: ^(.*app.*)$
        # 複数行のログ収集を有効にします。単一行のログ収集の場合は、この構成を削除します。
        Multiline:
          # カスタム開始パターンモードを選択します。
          Mode: custom
          # 開始パターンの正規表現を構成します。
          StartPattern: '\d+-\d+-\d+\s\d+:\d+:\d+'
    # 処理プラグインを定義します。
    processors:
      # regex 解析プラグインを使用してログを解析します。
      - Type: processor_parse_regex_native
        # ソースフィールド名。
        SourceKey: content
        # 解析用の正規表現。キャプチャグループ「()」を使用して、抽出するフィールドをキャプチャします。
        Regex: (\d+-\d+-\d+\s\S+)(.*)
        # 抽出されたフィールドのリスト。
        Keys: ["time", "detail"]
    # 出力プラグインを定義します。
    flushers:
      # flusher_sls プラグインを使用して、指定された Logstore に出力します。
      - Type: flusher_sls
        # この Logstore が存在することを確認します。
        Logstore: k8s-file
        # エンドポイントが正しいことを確認します。
        Endpoint: cn-beijing.log.aliyuncs.com
        Region: cn-beijing
        TelemetryType: logs

ステップ 2：収集コンポーネントとマシングループのステータスの確認

Logtail や LoongCollector などのコレクションコンポーネントが各ワーカーノードにデプロイされて実行中であること、およびコレクションコンテナーからの [OK] ハートビートの数がワーカーノードの数と一致することを確認します。

1. 収集コンポーネント Pod のステータスを確認します。

   1. クラスターへの接続。

   2. 次のコマンドを実行して、関連するすべての収集 Pod が Running 状態であることを確認します。Pod が異常な状態にある場合は、「Pod の例外のトラブルシューティング」をご参照ください。

      kubectl get pods -n kube-system -l 'k8s-app in (loongcollector-ds,logtail)' 

      出力は次のようになります：

      NAME                      READY   STATUS    RESTARTS   AGE
      loongcollector-ds-fn5zn   1/1     Running   0          3d19h
      loongcollector-ds-ks76g   1/1     Running   0          3d19h

2. マシングループのハートビートステータスを確認します。

   1. Simple Log Service コンソールにログインします。

   2. [プロジェクト] セクションで、目的のプロジェクトをクリックします。

      

   3. 左側のナビゲーションウィンドウで、[リソース] > [マシングループ] を選択します。

   4. マシングループリストで、目的のマシングループをクリックします。

   5. [マシングループ設定] ページで、ハートビートステータスが [OK] のマシンの数を確認します。この数がクラスター内のワーカーノードの数と一致することを確認します。 詳細については、「ハートビートステータスの解決策」をご参照ください。

ステップ 3：LoongCollector (Logtail) の操作ログの表示

収集コンテナで収集エラーやエラーメッセージを確認し、問題の原因をさらに分析します。

1. 収集コンポーネント Pod に入ります。

   kubectl exec -it -n kube-system loongcollector-ds-XXXX  -- bash

2. Logtail のログは、Logtail コンテナの /usr/local/ilogtail/ ディレクトリに保存されます。ファイル名は ilogtail.LOG と logtail_plugin.LOG です。Logtail コンテナにログインし、次のコマンドを実行してログファイルを表示できます：

   # /usr/local/ilogtail/ ディレクトリを開きます。
   cd /usr/local/ilogtail
   
   # ilogtail.LOG と logtail_plugin.LOG ファイルを表示します。
   cat ilogtail.LOG
   cat logtail_plugin.LOG

3. エラーログのアラートメトリックを表示し、「Simple Log Service でのデータ収集における一般的なエラータイプ」で対応するソリューションを見つけます。

その他の O&M 操作

• Kubernetes クラスター内の Simple Log Service コンポーネントのステータスの表示

  Kubernetes クラスター内の Simple Log Service コンポーネントのステータスの表示

  次のコマンドを実行して、Simple Log Service デプロイメントのステータスと情報を表示します。

  kubectl get deploy -n kube-system | grep -E 'alibaba-log-controller|loongcollector-operator'

  次の結果が返されます：

  NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
  alibaba-log-controller   1/1     1            1           11d

  次のコマンドを実行して、DaemonSet リソースのステータス情報を表示します。

  kubectl get ds  -n kube-system | grep -E 'logtail-ds|loongcollector-ds'

  次の結果が返されます：

  NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR  AGE
  logtail-ds   2         2         2       2            2           **ux           11d

• Logtail のバージョン番号、IP アドレス、および起動時間の表示

  情報は Logtail コンテナの /usr/local/ilogtail/app_info.json ファイルに保存されます。

  kubectl exec logtail-ds-****k -n kube-system cat /usr/local/ilogtail/app_info.json

  次のような結果が返されます。

  {
     "UUID" : "",
     "hostname" : "logtail-****k",
     "instance_id" : "0EB****_172.20.4.2_1517810940",
     "ip" : "172.20.4.2",
     "logtail_version" : "0.16.2",
     "os" : "Linux; 3.10.0-693.2.2.el7.x86_64; #1 SMP Tue Sep 12 22:26:13 UTC 2017; x86_64",
     "update_time" : "2018-02-05 06:09:01"
  }

• ACK クラスターのログを別の Alibaba Cloud アカウントのプロジェクトに転送する

症状

このトピックでは、プロジェクトの削除方法と、「権限が不十分です」というエラーメッセージが表示されてプロジェクトを削除できない場合の対処法について説明します。

ソリューション

プロジェクトまたは Logstore の削除方法の詳細については、「プロジェクトの管理」および「Logstore の管理」をご参照ください。プロジェクトの削除に失敗した場合は、「プロジェクトを削除する際に「操作が拒否されました、権限が不十分です」というエラーメッセージが返された場合の対処法」をご参照ください。

原因

1. アプリケーション監視が一時停止しています。

2. アプリケーションが配置されている Pod に ARMS エージェントが期待どおりにロードされていません。

ソリューション

1. アプリケーション監視が一時停止しているかどうかの確認。

   1. ARMS コンソールにログインします。 左側のナビゲーションウィンドウで、[アプリケーションモニタリング] > [アプリケーションリスト]を選択します。

   2. [アプリケーション一覧] ページで、上部のナビゲーションバーでリージョンを選択し、アプリケーション名をクリックします。

      アプリケーションが見つからない場合は、ステップ 2：ARMS エージェントが期待どおりにロードされているかどうかの確認に進みます。

   3. 新しい Application Real-Time Monitoring Service (ARMS) コンソールを使用している場合は、アプリケーション詳細ページのトップナビゲーションバーで [設定] > [カスタム設定] を選択します。 [プローブスイッチ設定] セクションで、アプリケーション監視が一時停止されているかどうかを確認します。

      • [アプリケーション監視を一時停止] がオンになっている場合は、スイッチをオフにして [保存] をクリックします。

      • [アプリケーション監視を一時停止] がオフになっている場合は、ステップ 2：ARMS エージェントが期待どおりにロードされているかどうかの確認に進みます。

   4. 旧バージョンの ARMS コンソールを使用している場合は、アプリケーション詳細ページの左側のナビゲーションウィンドウで [アプリケーション設定] をクリックします。 表示されたページで、[カスタム設定] タブをクリックします。 [エージェントスイッチ設定] セクションで、[Probe Master Switch] がオンになっているかどうかを確認します。

      • [プローブマスタースイッチ] がオフになっている場合は、[プローブマスタースイッチ] をオンにして、ページ下部の [保存] をクリックします。

      • [プローブマスタースイッチ] がオンになっている場合は、ステップ 2：ARMS エージェントが期待どおりにロードされているかどうかの確認に進みます。

2. プローブが正しくロードされているかどうかの確認

   1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。「クラスター」ページで、クラスターの名前をクリックしてクラスターの詳細ページに移動します。

   2. 左側のナビゲーションウィンドウで、[ワークロード] > [ポッド] の順に選択します。

   3. [Pod] ページで、アプリケーションが存在する名前空間を選択し、アプリケーションを見つけ、[アクション] 列の [YAML の編集] をクリックします。

   4. [YAML の編集] ダイアログボックスで、YAML ファイルに initContainers が含まれているかどうかを確認します。

      

      • YAML ファイルに initContainers が含まれていない場合、Pod は one-pilot-initcontainer にインジェクションされていません。ステップ 5 を実行します。

      • YAML ファイルに initContainers が含まれている場合、Pod は one-pilot-initcontainer にインジェクションされています。ステップ 8 を実行します。

   5. クラスターの詳細ページの左側のナビゲーションウィンドウで、[ワークロード] > [Pod] を選択します。表示されたページで、[名前空間] パラメーターを [ack-onepilot] に設定します。Pod リストに、ローリングアップデートが完了した ack-onepilot-* という名前の Pod が存在するかどうかを確認します。

      • 指定された Pod が存在する場合は、ステップ 6 を実行します。

      • 指定された Pod が存在しない場合は、アプリケーションマーケットから ack-onepilot コンポーネントをインストールします。詳細については、「ack-onepilot をインストールして arms-pilot をアンインストールする方法」をご参照ください。

   6. クラスター詳細ページの左側のナビゲーションウィンドウで、[ワークロード] > [デプロイメント] または [StatefulSet] を選択します。 表示されたページで、アプリケーションを見つけ、[アクション] 列で > [YAML の編集] を選択します。 [YAML の編集] ダイアログボックスで、YAML ファイルの spec.template.metadata セクションに次のラベルが含まれているかどうかを確認します。

      labels:
        armsPilotAutoEnable: "on"
        armsPilotCreateAppName: "<your-deployment-name>"    # <your-deployment-name> を実際のアプリケーション名に置き換えます。
        armsSecAutoEnable: "on"    # アプリケーションを Application Security に接続する場合は、このパラメーターを構成する必要があります。

      • YAML ファイルにラベルが含まれている場合は、ステップ 7 を実行します。

      • YAML ファイルにラベルが含まれていない場合は、[YAML の編集] ダイアログボックスで、spec > template > metadata セクションにラベルを追加し、<your-deployment-name> を実際のアプリケーション名に置き換えます。その後、[更新] をクリックします。

   7. クラスター詳細ページの左側のナビゲーションウィンドウで、[ワークロード] > [Pod] の順に選択します。表示されたページで Pod を見つけ、[アクション] 列で [その他] > [ログ] の順に選択し、ack-onepilot の Pod ログに "Message":"STS error" フォーマットでセキュリティトークンサービス (STS) エラーが報告されているかどうかを確認します。

      • エラーが報告されている場合は、アプリケーションのクラスターを承認し、アプリケーションの Pod を再起動します。詳細については、「ACK にデプロイされた Java アプリケーション用の ARMS エージェントのインストール」をご参照ください。

      • エラーが報告されない場合は、チケットを送信してください。

   8. クラスターの詳細ページの左側のナビゲーションウィンドウで、[ワークロード] > [Pod] を選択し、目的の Pod を見つけ、[アクション] 列の [YAML の編集] をクリックします。[YAML の編集] ダイアログボックスで、YAML ファイルに次の javaagent パラメーターが含まれているかを確認します。

      -javaagent:/home/admin/.opt/ArmsAgent/aliyun-java-agent.jar

      説明

      2.7.3.5 より前の ARMS エージェントを使用している場合は、上記のコードの aliyun-java-agent.jar を arms-bootstrap-1.7.0-SNAPSHOT.jar に置き換えます。エージェントをできるだけ早く最新バージョンにアップグレードすることを推奨します。

      • YAML ファイルにパラメーターが含まれている場合、[Pods] ページで Pod を見つけ、[アクション] 列の [ターミナル] をクリックしてコマンドライン ページに移動します。次のコマンドを実行して、ログに .log 拡張子のファイルが含まれているかどうかを確認します。次に、チケットを送信します。

        cd /home/admin/.opt/ArmsAgent/logs

      • YAML ファイルにパラメーターが含まれていない場合は、チケットを送信してください。

症状

ターゲットクラスターに ARMS Addon Token が存在しません。

1. ACK コンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。 [クラスター]ページで、クラスターの名前をクリックすると、クラスターの詳細ページに移動します。

2. 左側のナビゲーションウィンドウで、[構成] > [シークレット] を選択します。

3. ページの上部で、名前空間 ドロップダウンリストから [kube-system] を選択し、[addon.arms.token] が有効になっているかどうかを確認します。

   

ソリューション

Container Service for Kubernetes (ACK) に ARMS リソースへのアクセス権限を付与します。

症状

• アプリケーションの名前空間を変更した後、カスタムダッシュボードの名前空間列に表示される値が更新されません。

  

• アプリケーションのクラスターを変更した後、レート、エラー、および期間 (RED) メトリックのデータは正常に表示されますが、CPU やメモリなどのコンテナ監視メトリックのデータは表示されません。

考えられる原因

Namespace や ClusterId などのコンテナ関連パラメーターは、アプリケーションの作成時に構成され、これらのパラメーターの値は自動的に更新できません。アプリケーションのクラスターまたは名前空間を変更すると、コンテナ関連のデータのクエリまたは表示に失敗する可能性があります。

ソリューション

• アプリケーションを削除し、アプリケーションを再作成してから、再度モニタリングデータをレポートします。詳細については、「アプリケーションの削除」をご参照ください。

  この方法では、既存データが失われます。

• チケットを送信します。

背景情報

標準的なデプロイメントでは、ack-onepilot コンポーネントは JAVA_TOOL_OPTIONS 環境変数をインジェクションすることで Java エージェントのマウントパスを指定します。ただし、次のような特定のシナリオでは、エージェントのマウントパスをカスタマイズする必要がある場合があります：

• 構成管理の一元化

  Kubernetes ConfigMap を使用してエージェントパスを一元管理し、複数の環境間で構成の一貫性を確保できます。

• 永続ストレージの要件

  企業のセキュリティポリシーや O&M 要件により、プローブファイルをカスタムの永続ボリューム (PVC) に保存する必要がある場合があります。

ソリューション

Java エージェントのマウントパスをカスタマイズするには、次のコンポーネントバージョンが必要です：

• ack-onepilot：バージョン 4.1.0 以降。

• ARMS Java エージェント：バージョン 4.2.2 以降。必要に応じてJava エージェントのバージョンを制御することもできます。

1. カスタムマウントされた Java エージェントを必要とする Deployment などの Kubernetes ワークロードに disableJavaToolOptionsInjection アノテーションを追加します。

   このアノテーションを追加すると、ack-onepilot コンポーネントは JAVA_TOOL_OPTIONS 環境変数を使用してエージェントのマウントパスや他の Java 仮想マシン (JVM) パラメーターを自動的に指定しなくなります。

   1. 次のコマンドを実行して、ターゲット Deployment の YAML ファイルを表示します。

      kubectl get deployment YOUR_DEPLOYMENT_NAME -o yaml

      説明

      Deployment 名がわからない場合は、次のコマンドを実行してすべての Deployment を一覧表示できます。結果からターゲット Deployment を見つけ、その YAML ファイルを表示します。

      kubectl get deployments --all-namespaces

   2. ターゲットのステートレスアプリケーション (Deployment) の YAML ファイルを編集できます。

      kubectl edit deployment YOUR_DEPLOYMENT_NAME -o yaml

   3. YAML ファイルで、`spec.template.metadata` の下に次の内容を追加します。

      labels:
        armsPilotAutoEnable: "on"
        armsPilotCreateAppName: "<span class="var-span" contenteditable="true" data-var="YOUR_DEPLOYMENT_NAME">YOUR_DEPLOYMENT_NAME"</span> # YOUR_DEPLOYMENT_NAME をアプリケーション名に置き換えます。
        disableJavaToolOptionsInjection: "true"            # Java エージェントのマウントパスをカスタマイズするには、これを true に設定します。

2. ARMS Java エージェントのマウントパスをアプリケーションの起動スクリプトまたは Java 起動コマンドに追加します。

   デフォルトのマウントパスは /home/admin/.opt/AliyunJavaAgent/aliyun-java-agent.jar です。このパスをカスタムパスに置き換えます。

   java -javaagent:/home/admin/.opt/AliyunJavaAgent/aliyun-java-agent.jar ... ... -jar xxx.jar

   レポートリージョンやライセンスキーなどの他の情報は、ack-onepilot によって環境変数を通じてインジェクションされます。

症状

リージョン A からリージョン B にデータをレポートする方法は？

ソリューション

1. ack-onepilot コンポーネントを V4.0.0 以降に更新します。

2. ack-onepilot 名前空間の ack-onepilot-ack-onepilot アプリケーションに ARMS_REPORT_REGION 環境変数を追加します。値は ARMS が利用可能なリージョンの ID である必要があります。例：cn-hangzhou または cn-beijing。

3. 既存のアプリケーションを再起動するか、新しいアプリケーションをデプロイして、リージョンをまたいでデータをレポートします。

   説明

   環境変数を追加した後、クラスターにデプロイされたすべてのアプリケーションは、前のステップで指定されたリージョンにデータをレポートします。

背景情報

古いアプリケーション監視エージェント arms-pilot はメンテナンスされなくなりました。新しいエージェント ack-onepilot をインストールしてアプリケーションを監視できます。ack-onepilot は arms-pilot と完全に互換性があります。アプリケーション構成を変更することなく、ack-onepilot をシームレスにインストールできます。このトピックでは、arms-pilot をアンインストールして ack-onepilot をインストールする方法について説明します。

ソリューション

• ack-onepilot は ACK クラスター V1.16 以降にインストールする必要があります。クラスターが V1.16 より古い場合は、まずクラスターをアップグレードしてください。詳細については、「ACK クラスターの Kubernetes バージョンの更新」をご参照ください。

• ack-onepilot をインストールする前に arms-pilot をアンインストールする必要があります。ack-onepilot と arms-pilot の両方がインストールされている場合、ARMS エージェントはマウントできません。arms-pilot が完全にアンインストールされていない場合、ack-onepilot は環境内で arms-pilot がまだ動作しているとみなし、動作しません。

• arms-pilot をアンインストールして ack-onepilot をインストールする場合、arms-pilot の構成は ack-onepilot に自動的に同期されません。構成を記録してから、手動で ack-onepilot を構成することを推奨します。

1. arms-pilot のアンインストール。

   1. ACK コンソールにログインします。 [クラスター] ページで、クラスターの名前をクリックします。

   2. 左側のナビゲーションウィンドウで、[アプリケーション] > [Helm] を選択します。

   3. [Helm] ページで、[arms-pilot] を探し、[アクション] 列の [削除] をクリックします。

   4. [削除] メッセージで、[OK] をクリックします。

2. arms-pilot がアンインストールされたかどうかの確認。

   ACK コンソールのクラスター詳細ページに移動します。 左側のナビゲーションウィンドウで、[ワークロード] > [デプロイメント]を選択します。 [デプロイメント] ページで、[名前空間] ドロップダウンリストから[arms-pilot]を選択し、名前空間の Pod が期待どおりに削除されているかどうかを確認します。

   説明

   arms-pilot が属する名前空間を変更した場合は、新しい名前空間を選択します。

3. ack-onepilot のインストール。

   1. ACK コンソールにログインします。 [クラスター] ページで、クラスターの名前をクリックします。

   2. 左側のナビゲーションウィンドウで[アドオン]をクリックし、[アドオン]ページで[ack-onepilot] を検索します。

   3. [ack-onepilot] カードの [インストール] をクリックします。

      説明

      デフォルトでは、ack-onepilot コンポーネントは 1,000 個の Pod をサポートします。クラスター内の Pod が 1,000 個増えるごとに、コンポーネントに 0.5 CPU コアと 512 MB のメモリを追加する必要があります。

   4. 表示されるダイアログボックスで、パラメーターを設定し、[OK] をクリックします。デフォルト値を使用することをお勧めします。

      説明

      ack-onepilot のインストール後は、[アドオン] ページでアップグレード、設定、またはアンインストールできます。

4. ack-onepilot がインストールされたかどうかの確認。

   ACK コンソールのクラスターの詳細ページに移動します。 左側のナビゲーションウィンドウで、[ワークロード] > [デプロイメント]を選択します。 [デプロイメント] ページで、[Namespace] ドロップダウンリストから ack-onepilot を選択し、名前空間の Pod が期待どおりに実行されているかどうかを確認します。

   

症状

Prometheus モニタリングを有効にすると、ターゲットクラスターの [オペレーション] > [Prometheus モニタリング] ページにメッセージ [ダッシュボードが見つかりません] が表示される場合は、以下のプロシージャに従って問題を解決してください。

ソリューション

1. Prometheus モニタリングコンポーネントを再インストールします。

   1. Prometheus モニタリングを無効にする。

   2. コンポーネントを再インストールします：

      1. アンインストールが完了したことを確認したら、[インストール] をクリックし、次にダイアログボックスで [OK] をクリックします。

      2. インストールが完了したら、Prometheus モニタリングページに戻り、問題が解決したかどうかを確認します。

         問題が解決しない場合は、次のステップに進みます。

2. Prometheus インスタンスの接続を確認します。

   1. ARMS コンソールの左側のナビゲーションウィンドウで、[統合管理] をクリックします。

   2. [統合環境] タブで、[コンテナーサービス] リストにクラスターと同じ名前のコンテナー環境があることを確認します。

      • 対応するコンテナ環境が存在しない場合：「ARMS または Prometheus コンソールを使用して接続する」をご参照ください。

      • コンテナー環境がある場合は、対象の環境の[アクション] 列で[エージェントの設定] をクリックし、[エージェントの設定] ページを開きます。

        インストールされたエージェントが期待どおりに実行されているかどうかを確認します。

原因

Managed Service for Prometheus でデータが表示されないのは、Alibaba Cloud Prometheus サービスとの同期タスクが失敗し、リソース登録が失敗したか、Prometheus インスタンスが正しくプロビジョニングされなかったことが原因である可能性があります。以下の手順に従って問題を確認し、解決してください。

ソリューション

1. Managed Service for Prometheus のプロビジョニングタスクのステータスを確認します。

   3. [ジョブ] ページで、ページ上部で [名前空間] を [arms-prom] に設定し、次に [o11y-init-environment] をクリックしてジョブが成功したことを確認します。

      成功しなかった場合、Alibaba Cloud Prometheus サービスとの同期およびリソースの登録に失敗した可能性があります。その Pod のログを表示して、失敗の具体的な原因を見つけることができます。詳細については、「Pod の例外のトラブルシューティング」をご参照ください。

      Pod がもう存在しない場合は、次の手順に進みます。

2. Prometheus モニタリングコンポーネントを再インストールします。

   1. Prometheus モニタリングを無効にする。

   2. コンポーネントを再インストールします：

      1. アンインストールが完了したことを確認したら、[インストール] をクリックし、ダイアログボックスで [OK] をクリックします。

      2. インストールが完了したら、Prometheus モニタリングページに戻り、問題が解決したかどうかを確認します。

         問題が解決しない場合は、次のステップに進みます。

3. Prometheus インスタンスのプロビジョニングを確認します。

   1. ARMS コンソールの左側のナビゲーションウィンドウで、[統合管理] をクリックします。

   2. [統合環境] タブの [コンテナーサービス] リストで、クラスターと同じ名前のコンテナー環境を確認します。

      • 対応するコンテナ環境が存在しない場合：「ARMS または Prometheus コンソールを使用して接続する」をご参照ください。

      • コンテナー環境がある場合は、対象の環境の [アクション] 列にある [エージェントの設定] をクリックして、[エージェントの設定] ページを開きます。

        インストールされたエージェントが期待どおりに実行されているかどうかを確認します。

症状

Prometheus エージェントをアンインストールして再インストールすると、次のエラーメッセージが表示されます：

rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: ClusterRole, namespace: , name: arms-pilot-prom-k8s

原因

コマンドを実行して Prometheus エージェントを手動でアンインストールした後、ロールなどのリソースが削除されない場合があります。

ソリューション

1. 次のコマンドを実行して、Prometheus エージェントの ClusterRole を見つけます：

   kubectl get ClusterRoles --all-namespaces | grep prom

2. 次のコマンドを実行して、前のステップでクエリされた ClusterRole を削除します：

    kubectl delete ClusterRole [$Cluster_Roles] -n arms-prom

   説明

   [$Cluster_Roles] パラメーターは、前のステップでクエリされた ClusterRole を指定します。

3. ClusterRole を削除しても問題が解決しない場合は、エラーメッセージの kind の値を確認して、ClusterRole 以外のリソースが存在するかどうかを確認します。上記の手順を実行して、それらを順番に削除します。

背景情報

クラスターにデプロイされている ack-arms-prometheus コンポーネントのバージョンと、更新が必要かどうかを確認する必要があります。

ソリューション

1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。

2. クラスター ページで、管理するクラスターを見つけ、その名前をクリックします。左側のナビゲーションウィンドウで、アドオン管理 をクリックします。

3. [コンポーネント管理] ページで、[ログとモニタリング] タブをクリックし、[ack-arms-prometheus] コンポーネントを探します。

   現在のバージョンはコンポーネント名の下に表示されます。新しいバージョンが利用可能な場合は、バージョン番号の横にある[アップグレード]をクリックしてコンポーネントをアップグレードします。

   説明

   インストールされているコンポーネントが最新バージョンではない場合にのみ、[アップグレード] ボタンが表示されます。

原因

GPU ノードに Taint がある場合、GPU モニタリングのデプロイに失敗することがあります。以下の手順で GPU ノードの Taint を確認できます。

ソリューション

1. 次のコマンドを実行して、ターゲット GPU ノードの Taint を表示します。

   GPU ノードにカスタム Taint がある場合、出力に関連するエントリが見つかります。このトピックでは、key が test-key、value が test-value、effect が NoSchedule の Taint を例として使用します：

   kubectl describe node cn-beijing.47.100.***.***

   期待される出力：

   Taints:test-key=test-value:NoSchedule

2. GPU ノードの Taint は、次のいずれかの方法で処理できます。

   • 次のコマンドを実行して、GPU ノードの Taint を削除します。

     kubectl taint node cn-beijing.47.100.***.*** test-key=test-value:NoSchedule-

   • GPU ノードの Taint に対して Toleration を宣言し、Pod がノードにスケジュールされることを許可します。

     # 1. 次のコマンドを実行して ack-prometheus-gpu-exporter を編集します。
     kubectl edit daemonset -n arms-prom ack-prometheus-gpu-exporter
     
     # 2. YAML ファイルに次のフィールドを追加して、Taint に対する Toleration を宣言します。
     # 他のフィールドは省略します。
     # tolerations フィールドは containers フィールドの上に追加され、containers フィールドと同じレベルにあります。
     tolerations:
     - key: "test-key"
       operator: "Equal"
       value: "test-value"
       effect: "NoSchedule"
     containers:
      # 他のフィールドは省略します。

背景情報

Prometheus Monitoring for Alibaba Cloud の名前空間のみを削除した場合、残存する構成が残り、再インストールが失敗する可能性があります。すべての ARMS-Prometheus 構成を完全に手動で削除するには、次の操作を実行します。

ソリューション

• arms-prom 名前空間を削除します。

  kubectl delete namespace arms-prom

• ClusterRoles を削除します。

  kubectl delete ClusterRole arms-kube-state-metrics
  kubectl delete ClusterRole arms-node-exporter
  kubectl delete ClusterRole arms-prom-ack-arms-prometheus-role
  kubectl delete ClusterRole arms-prometheus-oper3
  kubectl delete ClusterRole arms-prometheus-ack-arms-prometheus-role
  kubectl delete ClusterRole arms-pilot-prom-k8s
  kubectl delete ClusterRole gpu-prometheus-exporter
  kubectl delete ClusterRole o11y:addon-controller:role
  kubectl delete ClusterRole arms-aliyunserviceroleforarms-clusterrole

• ClusterRoleBinding を削除します。

  kubectl delete ClusterRoleBinding arms-node-exporter
  kubectl delete ClusterRoleBinding arms-prom-ack-arms-prometheus-role-binding
  kubectl delete ClusterRoleBinding arms-prometheus-oper-bind2
  kubectl delete ClusterRoleBinding arms-kube-state-metrics
  kubectl delete ClusterRoleBinding arms-pilot-prom-k8s
  kubectl delete ClusterRoleBinding arms-prometheus-ack-arms-prometheus-role-binding
  kubectl delete ClusterRoleBinding gpu-prometheus-exporter
  kubectl delete ClusterRoleBinding o11y:addon-controller:rolebinding
  kubectl delete ClusterRoleBinding arms-kube-state-metrics-agent
  kubectl delete ClusterRoleBinding arms-node-exporter-agent
  kubectl delete ClusterRoleBinding arms-aliyunserviceroleforarms-clusterrolebinding

• Role と RoleBinding を削除します。

  kubectl delete Role arms-pilot-prom-spec-ns-k8s
  kubectl delete Role arms-pilot-prom-spec-ns-k8s -n kube-system
  kubectl delete RoleBinding arms-pilot-prom-spec-ns-k8s
  kubectl delete RoleBinding arms-pilot-prom-spec-ns-k8s -n kube-system

ARMS-Prometheus リソースを手動で削除した後、Container Service for Kubernetes (ACK) コンソールで [運用管理 > コンポーネント管理] に移動し、[ack-arms-prometheus] コンポーネントを再インストールします。

原因

ack-arms-prometheus コンポーネントをデプロイする際に、「xxx in use」エラーが報告されます。これは、リソースが占有されているか、残存リソースが原因でコンポーネントのインストールが失敗している可能性があります。

ソリューション

1. [クラスター] ページで、対象クラスターの名前をクリックします。クラスター詳細ページの左側のナビゲーションウィンドウで、[アプリケーション] > [Helm] を選択します。

2. [Helm] ページで、ack-arms-prometheus が存在することを確認します。

   • [Helm] ページから ack-arms-prometheus を削除し、[アドオン] ページで再インストールします。 詳細については、「コンポーネントの管理」をご参照ください。

   • 見つからない場合：

     1. ack-arms-prometheus が見つからない場合、ack-arms-prometheus Helm Release の削除から残存リソースが残っていることを示します。その後、手動で ARMS-Prometheus を完全に削除する必要があります。

     2. Prometheus モニタリングを再度有効にする。

症状

ack-arms-prometheus コンポーネントをインストールしようとすると、最初に「コンポーネントがインストールされていません」というメッセージが表示され、2 回目の試行でもインストールに失敗します。

ソリューション

• ack-arms-prometheus コンポーネントが既にインストールされているかどうかを確認します。

  1. [クラスター] ページで対象のクラスターの名前をクリックし、クラスター詳細ページの左側のナビゲーションウィンドウで [アプリケーション] > [Helm] を選択します。

  2. [Helm] ページで、ack-arms-prometheus が存在することを確認します。

     • [Helm] ページから ack-arms-prometheus を削除し、[アドオン] ページで再インストールします。 詳細については、「コンポーネントの管理」をご参照ください。

     • 見つからない場合：

       1. ack-arms-prometheus が見つからない場合、ack-arms-prometheus Helm Release の削除から残存リソースが残っていることを示します。その後、手動で ARMS-Prometheus を完全に削除する必要があります。

       2. Prometheus モニタリングを再度有効にする。

• ack-arms-prometheus のログにエラーがないか確認します。

  1. クラスター詳細ページの左側にあるナビゲーションウィンドウで、[ワークロード] > [デプロイメント] を選択します。

  2. [デプロイメント] ページの上部で、[名前空間]を [arms-prom] に設定し、arms-prometheus-ack-arms-prometheus をクリックします。

  3. [ログ] タブをクリックし、ログでエラーを確認します。

• エージェントのインストール中にエラーが発生したかどうかを確認します。

  1. ARMS コンソールにログインします。左側のナビゲーションウィンドウで、[統合管理] をクリックします。

  2. [統合管理] タブで、[コンテナーサービス] リストから目的のコンテナー環境を探します。[アクション] 列で [エージェントの設定] をクリックして、[エージェントの設定] ページを開きます。

症状

オープンソース Prometheus をデプロイした後、DingTalk を使用してアラート通知を送信するように構成する必要があります。

ソリューション

1. DingTalk チャットボットの Webhook URL を取得します。詳細については、「イベント監視」をご参照ください。

2. パラメーターウィザードページで、dingtalk セクションを見つけ、enabled を true に設定し、次に token フィールドに DingTalk チャットボットの Webhook URL を指定します。詳細については、「アラート構成」の「[DingTalk アラート通知を構成する]」をご参照ください。

症状

Can't install release with errors: rpc error: code = Unknown desc = object is being deleted: customresourcedefinitions.apiextensions.k8s.io "xxxxxxxx.monitoring.coreos.com" already exists

ソリューション

kubectl delete crd prometheuses.monitoring.coreos.com
kubectl delete crd prometheusrules.monitoring.coreos.com
kubectl delete crd servicemonitors.monitoring.coreos.com
kubectl delete crd alertmanagers.monitoring.coreos.com

症状

オープンソース Prometheus をデプロイした後、構成したメールアラートがアラート通知を送信しません。

ソリューション

smtp_auth_password の値がメールアカウントのログインパスワードではなく、SMTP 認証コードであることを確認してください。SMTP サーバーのエンドポイントにポート番号が含まれていることを確認してください。

症状

オープンソース Prometheus をデプロイした後、[YAML の更新] をクリックすると、「現在のクラスターは一時的にアクセスできません。後でもう一度試すか、フィードバックのためにチケットを送信してください」というエラーメッセージが表示されます。

ソリューション

Tiller の構成ファイルが大きすぎると、クラスターにアクセスできなくなります。この問題を解決するには、構成ファイル内の一部の注釈を削除し、ファイルを ConfigMap として Pod にマウントします。ConfigMap の名前は、prometheus および alertmanager セクションの configMaps フィールドで指定できます。詳細については、「Prometheus への ConfigMap のマウント」の 2 番目の方法をご参照ください。

症状

オープンソース Prometheus をデプロイした後、その機能を有効にするためにさらに構成を行う必要がある場合があります。

ソリューション

prometheus-operator がデプロイされた後、次の手順を実行して prometheus-operator の機能を有効にできます。クラスターの詳細ページに移動し、左側のナビゲーションウィンドウで [アプリケーション] > [Helm] を選択します。[Helm] ページで [ack-prometheus-operator] を探し、[操作] 列の [更新] をクリックします。[リリース更新] パネルで、コードブロックを設定して機能を有効にします。次に、[OK] をクリックします。

症状

ストレージソリューションを選択する際、TSDB と Alibaba Cloud ディスクのどちらを選択し、データ保持ポリシーをどのように構成すればよいですか？

ソリューション

症状

オープンソース Prometheus をデプロイした後、Grafana ダッシュボードが正しく表示されません。

ソリューション

クラスターの詳細ページに移動し、左側のナビゲーションウィンドウで [アプリケーション] > [Helm] を選択します。 Helm ページで、[ack-prometheus-operator] を見つけ、アクション列の [更新] をクリックします。 Update Release パネルで、[clusterVersion] フィールドの値が正しいかどうかを確認します。 クラスターの Kubernetes バージョンが 1.16 より前の場合は、clusterVersion を 1.14.8-aliyun.1 に設定します。 クラスターの Kubernetes バージョンが 1.16 以降の場合は、clusterVersion を 1.16.6-aliyun.1 に設定します。

原因

ack-prometheus 名前空間を削除した後、関連するリソース構成が保持される場合があります。この場合、ack-prometheus を再度インストールできないことがあります。次の操作を実行して、関連するリソース構成を削除できます：

ソリューション

1. ロールベースのアクセス制御 (RBAC) 関連のリソース構成を削除します。

   1. 次のコマンドを実行して、関連する ClusterRole を削除します：

      kubectl delete ClusterRole ack-prometheus-operator-grafana-clusterrole
      kubectl delete ClusterRole ack-prometheus-operator-kube-state-metrics
      kubectl delete ClusterRole psp-ack-prometheus-operator-kube-state-metrics
      kubectl delete ClusterRole psp-ack-prometheus-operator-prometheus-node-exporter
      kubectl delete ClusterRole ack-prometheus-operator-operator
      kubectl delete ClusterRole ack-prometheus-operator-operator-psp
      kubectl delete ClusterRole ack-prometheus-operator-prometheus
      kubectl delete ClusterRole ack-prometheus-operator-prometheus-psp

   2. 次のコマンドを実行して、関連する ClusterRoleBinding を削除します：

      kubectl delete ClusterRoleBinding ack-prometheus-operator-grafana-clusterrolebinding
      kubectl delete ClusterRoleBinding ack-prometheus-operator-kube-state-metrics
      kubectl delete ClusterRoleBinding psp-ack-prometheus-operator-kube-state-metrics
      kubectl delete ClusterRoleBinding psp-ack-prometheus-operator-prometheus-node-exporter
      kubectl delete ClusterRoleBinding ack-prometheus-operator-operator
      kubectl delete ClusterRoleBinding ack-prometheus-operator-operator-psp
      kubectl delete ClusterRoleBinding ack-prometheus-operator-prometheus
      kubectl delete ClusterRoleBinding ack-prometheus-operator-prometheus-psp

2. 次のコマンドを実行して、関連する CRD オブジェクトを削除します：

   kubectl delete crd alertmanagerconfigs.monitoring.coreos.com
   kubectl delete crd alertmanagers.monitoring.coreos.com
   kubectl delete crd podmonitors.monitoring.coreos.com
   kubectl delete crd probes.monitoring.coreos.com
   kubectl delete crd prometheuses.monitoring.coreos.com
   kubectl delete crd prometheusrules.monitoring.coreos.com
   kubectl delete crd servicemonitors.monitoring.coreos.com
   kubectl delete crd thanosrulers.monitoring.coreos.com

症状

アラートセンターで、アラートルールの同期ステータスに The Project does not exist : k8s-log-xxx というメッセージが表示されます。

原因

SLS イベントセンターのリソースが作成されていません。

ソリューション

1. Simple Log Service コンソールで、クォータ制限に達しているかどうかを確認します。リソースの詳細については、「基本リソース制限」をご参照ください。

   1. クォータ制限に達した場合は、不要なプロジェクトを削除するか、チケットを送信してプロジェクトリソースのクォータ制限の引き上げを申請します。プロジェクトを削除する方法については、「プロジェクトの管理」をご参照ください。

   2. 制限に達していない場合は、次の手順に進みます。

2. ack-node-problem-detector コンポーネントを再インストールします。

   コンポーネントを再インストールすると、k8s-log-xxxxxx という名前のデフォルトプロジェクトが再作成されます。

   1. ack-node-problem-detector コンポーネントをアンインストールします。

      1. Container Service for Kubernetes コンソールの対象クラスターの管理ページで、左側のナビゲーションウィンドウから[O&M] > [コンポーネント管理]を選択します。

      2. [ログとモニタリング] タブをクリックします。次に、[ack-node-problem-detector] コンポーネントカード上の [アンインストール] をクリックし、ダイアログボックスで [確認] をクリックします。

   2. アンインストールが完了したら、ack-node-problem-detector コンポーネントをインストールします。

      1. 左側のナビゲーションウィンドウで、[運用保守] > [アラート] を選択します

      2. [アラートルール] ページで [インストールを開始] をクリックすると、コンソールによってプロジェクトが自動的に作成され、コンポーネントがインストールおよびアップグレードされます。

3. [アラート ルール] ページで対応するアラート ルール セットを無効にし、その [アラート ルール ステータス] が [ルール無効] に変わるまで待機してから、ルール セットを再度有効にしてリトライします。

症状

構成またはデプロイ中にアラートルールの同期に失敗し、this rule have no xxx contact groups reference などのエラーメッセージがシステムに表示されます。その結果、このアラートルールの通知は配信されません。

原因

アラートルールの同期に失敗し、this rule have no xxx contact groups reference のようなエラーメッセージが報告されます。

ソリューション

1. 連絡先を作成し、連絡先グループに追加していること。

2. 対象のアラートルールセットの右にある [通知ポリシーの編集] をクリックし、アラートルールセットをサブスクライブする連絡先グループを設定します。

kubectl top pod/node でデータが返されない理由

kubectl top pod/node で一部のデータが欠落する理由

HPA がメトリックデータを取得できない場合の対処法

ローリングデプロイ中に HPA が余分な Pod を作成する理由

--metric-resolution=15s
--enable-hpa-rolling-update-skipped=true