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

Container Service for Kubernetes:可観測性のよくある質問

最終更新日:Aug 21, 2026

カテゴリ

リンク

ログ収集

アプリケーションモニタリング

Managed Service for Prometheus

オープンソース Prometheus モニタリング (ack-prometheus-operator アドオン)

アラート管理

その他の問題

ログ収集

コンテナのログ収集エラーのトラブルシューティング方法

症状

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

事前準備

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

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

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

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

ステップ 1:収集設定の確認

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

コンソール

  1. ACK コンソールにログインします。

  2. クラスターリスト ページで、対象クラスターの名前をクリックします。左側のナビゲーションウィンドウで、ワークロード > カスタムリソース をクリックします。

  3. [リソースオブジェクトブラウザー] タブで、clusteraliyunpipelineconfig を検索し、ClusterAliyunPipelineConfig の結果をクリックします。

  4. [ClusterAliyunPipelineConfig] パネルで、ターゲットリソースを見つけ、[操作] 列の [YAML の編集] をクリックします。

kubectl

  1. 次のコマンドを実行して、AliyunPipelineConfig によって作成されたすべての Logtail 構成を表示します。

    kubectl get clusteraliyunpipelineconfigs
  2. AliyunPipelineConfig によって作成された Logtail 構成の詳細とステータスを表示します。

    次のコマンドを実行します。必要に応じて、<config_name> を AliyunPipelineConfig の名前に置き換えます。

    kubectl get clusteraliyunpipelineconfigs <config_name> -o yaml

設定項目の詳細については、「CRD パラメーター」をご参照ください。

設定項目

チェックポイントの概要

例

project

プロジェクト名が正しいかどうかを確認します。Simple Log Service コンソールにログインし、インストールされたログ収集コンポーネントによって生成されたプロジェクトの名前を見つけます。

k8s-log-<YOUR_CLUSTER_ID>

inputs.FilePaths

ログファイルパスが存在し、出力があるかどうかを確認します。詳細については、「コンテナファイルパスのマッピング」をご参照ください。

/var/log/nginx/*.log など

inputs.EnableContainerDiscovery

コンテナ検出機能が有効になっています。

true

flushers.Endpoint

Simple Log Service エンドポイントが正しいです。

cn-hangzhou.log.aliyuncs.com

flushers.Region

リージョン情報が正しいです。

cn-hangzhou

CRD-AliyunPipelineConfig 構成のサンプル YAML ファイル

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. [プロジェクト] セクションで、目的のプロジェクトをクリックします。

      image

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

    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 デプロイメントのステータスと情報を表示します。

    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 の管理」をご参照ください。プロジェクトの削除に失敗した場合は、「プロジェクトの削除時に「操作が拒否されました、権限が不十分です」というエラーメッセージが返された場合の対処法」をご参照ください。

Simple Log Service でのデータ収集における一般的なエラータイプ

エラータイプ

説明

ソリューション

LOG_GROUP_WAIT_TOO_LONG_ALARM

データパケットが生成された後、送信されるまでの待機時間が長すぎます。

パケットが期待どおりに送信されているか確認してください。このエラーは、データ量がデフォルト設定を超えている、クォータが不足している、またはネットワークの問題が原因で発生する可能性があります。

LOGFILE_PERMISSION_ALARM

Logtail に指定されたファイルを読み取る権限がありません。

サーバー上の Logtail 起動アカウントを確認してください。Logtail を root ユーザーとして起動することで解決します。

SPLIT_LOG_FAIL_ALARM

行の開始を示す正規表現がログの内容と一致しないため、Logtail がログを個別の行に分割できません。

正規表現が正しいか確認してください。

単一行のログの場合、正規表現を .* に設定します。

MULTI_CONFIG_MATCH_ALARM

デフォルトでは、1 つのログファイルは 1 つの Logtail 構成にしか一致しません。複数の Logtail 構成が同じファイルに一致する場合、1 つだけが有効になります。

注

Docker からの標準出力を収集するために、複数の Logtail 構成を使用できます。

REGEX_MATCH_ALARM

完全正規表現モードでは、ログの内容が指定された正規表現と一致しません。

エラーメッセージからログサンプルをコピーして、新しい正規表現を生成します。

PARSE_LOG_FAIL_ALARM

JSON やデリミタなどのモードで、ログ形式が定義された形式に準拠していないため、解析に失敗します。

エラーメッセージをクリックして、詳細なエラーレポートを表示します。

CATEGORY_CONFIG_ALARM

Logtail の収集設定が無効です。

一般的な原因は、正規表現がファイルパスをトピックとして抽出できなかったことです。

LOGTAIL_CRASH_ALARM

Logtail がサーバーのリソース使用量制限を超えたため、クラッシュしました。

CPU とメモリの使用量制限を増やします。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および構成」をご参照ください。

REGISTER_INOTIFY_FAIL_ALARM

Logtail が Linux でログリスナーを登録できませんでした。このエラーは、Logtail がフォルダにアクセスする権限がないか、フォルダが削除されたために発生する可能性があります。

Logtail がフォルダにアクセスする権限があるか、またはフォルダが削除されたかを確認してください。

DISCARD_DATA_ALARM

Logtail に設定された CPU リソースが不足しているか、ネットワーク経由でデータを送信する際にスロットリングがトリガーされます。

CPU 使用量制限またはネットワーク送信同時実行数制限を増やします。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および構成」をご参照ください。

SEND_DATA_FAIL_ALARM

  • Alibaba Cloud アカウントに AccessKey ペアが作成されていません。

  • Logtail クライアントが配置されているサーバーが Simple Log Service に接続できないか、ネットワーク品質が低いです。

  • Simple Log Service サーバーの書き込みクォータが不足しています。

  • Alibaba Cloud アカウントに AccessKey ペアを作成します。

  • /usr/local/ilogtail/ilogtail_config.json にあるローカル設定ファイルを確認します。次に、curl <サーバーアドレス> コマンドを実行して、応答が返されるかどうかを確認します。

  • Logstore のシャード数を増やして、より高いデータ書き込み量をサポートします。

REGISTER_INOTIFY_FAIL_ALARM

Logtail がログディレクトリの inotify ウォッチャーを登録できませんでした。

ディレクトリが存在するかどうか、およびその権限設定を確認してください。

SEND_QUOTA_EXCEED_ALARM

ログの書き込みトラフィックが設定された制限を超えています。

コンソールでシャード数を増やします。詳細については、「シャードの管理」をご参照ください。

READ_LOG_DELAY_ALARM

ログ収集が遅延し、ログ生成に追いついていません。このエラーは通常、Logtail の CPU リソース不足またはネットワーク送信スロットリングが原因で発生します。

CPU 使用量制限またはネットワーク送信同時実行数制限を増やします。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および構成」をご参照ください。

既存データをインポートしている場合、短時間で大量のデータが収集されます。このエラーは無視できます。

DROP_LOG_ALARM

ログ収集が遅延し、未処理のローテーションされたログファイルの数が 20 を超えています。このエラーは通常、Logtail の CPU リソース不足またはネットワーク送信スロットリングが原因で発生します。

CPU 使用量制限またはネットワーク送信同時実行数制限を増やします。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および構成」をご参照ください。

LOGDIR_PERMISSION_ALARM

Logtail にログ監視ディレクトリを読み取る権限がありません。

ログ監視ディレクトリが存在するかどうかを確認します。存在する場合は、その権限設定を確認してください。

ENCODING_CONVERT_ALARM

エンコーディング変換に失敗しました。

設定されたエンコード形式がログの実際のエンコード形式と一致していることを確認してください。

OUTDATED_LOG_ALARM

ログのタイムスタンプが収集時間より 12 時間以上古いため、ログは古くなっています。考えられる原因は次のとおりです。

  • ログの解析が 12 時間以上遅延しています。

  • カスタム時間フィールドが正しく設定されていません。

  • ログ記録プログラムからの時間出力が異常です。

  • READ_LOG_DELAY_ALARM エラーも報告されているかどうかを確認します。

    報告されている場合は、まずそのエラーを解決します。そうでない場合は、時間フィールドの設定を確認してください。

  • 時間フィールドの設定を確認します。設定が正しい場合は、ログ記録プログラムからの時間出力が正常であることを確認してください。

STAT_LIMIT_ALARM

収集設定で指定されたディレクトリ内のファイル数が制限を超えています。

対象の収集ディレクトリに多数のファイルとサブディレクトリが含まれていないか確認してください。監視に適したルートディレクトリを設定し、サブディレクトリの最大監視深度を指定します。

mem_usage_limit パラメーターを変更することもできます。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および構成」をご参照ください。

DROP_DATA_ALARM

プロセス終了時にローカルディスクへのログ保存がタイムアウトしました。保存されなかったログは破棄されます。

このエラーは通常、収集プロセスが深刻にブロックされているために発生します。CPU 使用量制限またはネットワーク送信同時実行数制限を増やします。詳細については、「Logtail のネットワークタイプ、起動パラメーター、および構成」をご参照ください。

INPUT_COLLECT_ALARM

入力ソースからの収集中にエラーが発生しました。

エラーメッセージの詳細に基づいてエラーを解決してください。

HTTP_LOAD_ADDRESS_ALARM

HTTP データ収集設定で指定された Addresses パラメーターが無効です。

Addresses パラメーターが有効かどうかを確認してください。

HTTP_COLLECT_ALARM

HTTP データ収集中にエラーが発生しました。

エラーメッセージの詳細に基づいて問題をトラブルシューティングしてください。このエラーは通常、タイムアウトが原因で発生します。

FILTER_INIT_ALARM

フィルターの初期化中にエラーが発生しました。

このエラーは通常、フィルター内の無効な正規表現が原因で発生します。エラーメッセージの詳細に基づいて式を修正してください。

INPUT_CANAL_ALARM

MySQL バイナリロギングで実行時エラーが発生しました。

エラーメッセージの詳細に基づいて問題をトラブルシューティングしてください。

設定が更新されると、canal サービスが再起動することがあります。サービスの再起動によって引き起こされるエラーは無視してください。

CANAL_INVALID_ALARM

MySQL バイナリロギングの内部ステータスが異常です。

このエラーは通常、実行時のテーブルスキーマの変更がメタデータの不整合を引き起こす場合に発生します。エラーが報告された時点でテーブルスキーマが変更されたかどうかを確認してください。

MYSQL_INIT_ALARM

MySQL の初期化中にエラーが発生しました。

エラーメッセージの詳細に基づいてエラーを解決してください。

MYSQL_CHECKPOINT_ALARM

MySQL のチェックポイント形式が異常です。

この構成のチェックポイント関連の設定が変更されたかどうかを確認してください。

MYSQL_TIMEOUT_ALARM

MySQL クエリがタイムアウトしました。

MySQL サーバーとネットワークが正常に機能していることを確認してください。

MYSQL_PARSE_ALARM

MySQL クエリ結果の解析に失敗しました。

MySQL 構成のチェックポイント形式が対応するフィールドの形式と一致していることを確認してください。

AGGREGATOR_ADD_ALARM

キューへのデータの追加に失敗しました。

このエラーは、データの送信が速すぎることを示します。実際のデータ量が大きい場合は、このエラーを無視してください。

ANCHOR_FIND_ALARM

processor_anchor プラグインでエラーが発生しました。これは、不正な構成または構成に準拠しないログが原因である可能性があります。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。特定のサブタイプの詳細に基づいて構成を確認してください。

  • anchor cannot find key:構成で SourceKey パラメーターが指定されていますが、対応するフィールドがログに見つかりません。

  • anchor no start:SourceKey フィールドの値に Start パラメーターの一致が見つかりません。

  • anchor no stop:SourceKey フィールドの値に Stop パラメーターの一致が見つかりません。

ANCHOR_JSON_ALARM

processor_anchor プラグインで、Start および Stop パラメーターで定義された JSON コンテンツを展開する際にエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。処理中のコンテンツと関連する構成を確認して、構成エラーを特定するか、無効なログを見つけます。

CANAL_RUNTIME_ALARM

バイナリロギングプラグインで実行時エラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示し、問題をトラブルシューティングします。このエラーは通常、接続されているプライマリ MySQL インスタンスに関連しています。

CHECKPOINT_INVALID_ALARM

チェックポイントの解析に失敗しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。チェックポイントキー、チェックポイントコンテンツ (最初の 1024 バイト)、および特定のエラーメッセージに基づいて問題をトラブルシューティングします。

DIR_EXCEED_LIMIT_ALARM

Logtail が同時にリッスンしているディレクトリの数が制限を超えています。

現在の Logstore の収集設定および Logtail に適用されている他の設定が多くのディレクトリを含んでいないか確認してください。監視に適したルートディレクトリを設定し、サブディレクトリの最大監視深度を指定します。

DOCKER_FILE_MAPPING_ALARM

Logtail がコマンドを実行して Docker ファイルマッピングを追加できませんでした。

エラーリンクをクリックして詳細なエラーメッセージを表示します。コマンドと特定のエラーメッセージに基づいて問題をトラブルシューティングします。

DOCKER_FILE_MATCH_ALARM

Docker コンテナ内で指定されたファイルが見つかりません。

エラーリンクをクリックして詳細なエラーメッセージを表示します。コンテナ情報と検索中のファイルパスに基づいて問題をトラブルシューティングします。

DOCKER_REGEX_COMPILE_ALARM

service_docker_stdout プラグインでエラーが発生しました。プラグインが構成から BeginLineRegex をコンパイルできませんでした。

エラーリンクをクリックして詳細なエラーメッセージを表示します。正規表現が正しいかどうかを確認してください。

DOCKER_STDOUT_INIT_ALARM

service_docker_stdout プラグインの初期化に失敗しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。

  • host...version...error:構成で指定された Docker Engine にアクセスできるかどうかを確認してください。

  • load checkpoint error:プラグインがチェックポイントファイルのロードに失敗しました。ビジネス運用に影響がない場合は、このエラーを無視できます。

  • container...:指定された `container` の `label` `value` が無効です。有効な値は `stdout` と `stderr` です。詳細については、エラーメッセージをご参照ください。

DOCKER_STDOUT_START_ALARM

service_docker_stdout プラグインによる収集中に stdout サイズが制限を超えました。

このエラーは通常、最初の収集中に stdout データが既に存在する場合に発生します。このエラーは無視してください。

DOCKER_STDOUT_STAT_ALARM

service_docker_stdout プラグインが stdout を検出できません。

このエラーは通常、コンテナが終了するときに stdout にアクセスできないために発生します。このエラーは無視してください。

FILE_READER_EXCEED_ALARM

Logtail が同時に開いているファイルオブジェクトの数が制限を超えています。

このエラーは通常、同時に収集されているファイルが多すぎるために発生します。収集設定が妥当かどうかを確認してください。

GEOIP_ALARM

processor_geoip プラグインでエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。

  • invalid ip...:プラグインが IP アドレスを取得できませんでした。構成の SourceKey が正しいか、または無効なログが存在するかどうかを確認してください。

  • parse ip...:プラグインが IP アドレスから都市を解決できませんでした。詳細なエラーメッセージを確認して問題をトラブルシューティングしてください。

  • cannot find key...:指定された SourceKey がログに見つかりません。構成が正しいか、または無効なログが存在するかどうかを確認してください。

HTTP_INIT_ALARM

metric_http プラグインでエラーが発生しました。構成で指定された ResponseStringMatch 正規表現のコンパイルに失敗しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。正規表現が正しいかどうかを確認してください。

HTTP_PARSE_ALARM

metric_http プラグインでエラーが発生しました。プラグインが HTTP 応答を取得できませんでした。

エラーリンクをクリックして詳細なエラーメッセージを表示します。特定のエラーメッセージに基づいて、構成内容または要求された HTTP サーバーを確認してください。

INIT_CHECKPOINT_ALARM

バイナリロギングプラグインでエラーが発生しました。プラグインがチェックポイントファイルのロードに失敗しました。プラグインはチェックポイントを無視し、最初から処理を開始します。

エラーリンクをクリックして詳細なエラーメッセージを表示します。特定のエラー情報に基づいて、このエラーを無視するかどうかを判断します。

LOAD_LOCAL_EVENT_ALARM

Logtail はローカルイベントを処理しています。

この警告はまれです。手動操作によって引き起こされたものでない場合は、問題をトラブルシューティングする必要があります。エラーリンクをクリックして詳細なエラーメッセージを表示します。ファイル名、構成名、プロジェクト、および Logstore に基づいて問題をトラブルシューティングします。

LOG_REGEX_FIND_ALARM

processor_split_log_regex および processor_split_log_string プラグインでエラーが発生しました。構成で指定された SplitKey がログに見つかりません。

エラーリンクをクリックして詳細なエラーメッセージを表示し、構成エラーを確認します。

LUMBER_CONNECTION_ALARM

service_lumberjack プラグインでエラーが発生しました。プラグインの停止中にサーバーがシャットダウンされました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。特定のエラー情報に基づいて問題をトラブルシューティングします。通常、このエラーは無視できます。

LUMBER_LISTEN_ALARM

service_lumberjack プラグインでリスナーの初期化中にエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。

  • init tls error...:特定のエラーメッセージに基づいて、TLS 関連の構成が正しいかどうかを確認してください。

  • listen init error...:特定のエラーメッセージに基づいて、アドレス関連の構成が正しいかどうかを確認してください。

LZ4_COMPRESS_FAIL_ALARM

Logtail が LZ4 圧縮を実行中にエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。ログ行、プロジェクト、カテゴリ、およびリージョンの値に基づいて問題をトラブルシューティングします。

MYSQL_CHECKPOINT_ALARM

チェックポイントに関連する MySQL プラグインでエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。

  • init checkpoint error...:プラグインがチェックポイントの初期化に失敗しました。エラーメッセージに基づいて、構成で指定されたチェックポイント列と取得された値を確認してください。

  • not matched checkpoint...:チェックポイント情報が一致しません。構成の更新などの手動操作によってエラーが引き起こされたかどうかを確認してください。その場合は、エラーを無視してください。

NGINX_STATUS_COLLECT_ALARM

nginx_status プラグインでステータスの取得中にエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。URL と特定のエラー情報に基づいて問題をトラブルシューティングします。

NGINX_STATUS_INIT_ALARM

nginx_status プラグインでエラーが発生しました。プラグインの初期化と構成で指定された URL の解析に失敗しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。URL が正しく構成されているかどうかを確認してください。

OPEN_FILE_LIMIT_ALARM

Logtail によって開かれたファイルの数が制限を超え、新しいファイルを開くことができません。

エラーリンクをクリックして詳細なエラーメッセージを表示します。ログファイルパス、プロジェクト、および Logstore に基づいて問題をトラブルシューティングします。

OPEN_LOGFILE_FAIL_ALARM

Logtail がファイルを開こうとしたときにエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。ログファイルパス、プロジェクト、および Logstore に基づいて問題をトラブルシューティングします。

PARSE_DOCKER_LINE_ALARM

service_docker_stdout プラグインでエラーが発生しました。プラグインがログの解析に失敗しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。

  • parse docker line error: empty line:ログ行が空です。

  • parse json docker line error...:プラグインが JSON 形式のログの解析に失敗しました。エラーメッセージとログの最初の 512 バイトに基づいて問題をトラブルシューティングします。

  • parse cri docker line error...:プラグインが CRI 形式のログの解析に失敗しました。エラーメッセージとログの最初の 512 バイトに基づいて問題をトラブルシューティングします。

PLUGIN_ALARM

プラグインの初期化および関連する呼び出し中にエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。特定のエラー詳細に基づいて問題をトラブルシューティングします。

  • init plugin error...:プラグインの初期化に失敗しました。

  • hold on error...:プラグインの一時停止に失敗しました。

  • resume error...:プラグインの再開に失敗しました。

  • start service error...:サービス入力タイプのプラグインの開始に失敗しました。

  • stop service error...:サービス入力タイプのプラグインの停止に失敗しました。

PROCESSOR_INIT_ALARM

processor_regex プラグインでエラーが発生しました。プラグインが構成で指定された Regex 正規表現のコンパイルに失敗しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。正規表現が正しいかどうかを確認してください。

PROCESS_TOO_SLOW_ALARM

Logtail がログを解析する速度が遅すぎます。

  1. エラーリンクをクリックして詳細なエラーメッセージを表示します。ログ量、バッファーサイズ、および解析時間を確認して、速度が正常かどうかを判断します。

  2. 速度が遅すぎる場合は、Logtail ノード上の他のプロセスが過剰な CPU リソースを消費していないか、または非効率な正規表現などの非効率な解析構成がないかを確認してください。

REDIS_PARSE_ADDRESS_ALARM

Redis プラグインでエラーが発生しました。プラグインが構成で提供された ServerUrls の解析に失敗しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーが報告された URL を確認してください。

REGEX_FIND_ALARM

processor_regex プラグインでエラーが発生しました。プラグインが構成で SourceKey によって指定されたフィールドを見つけることができません。

エラーリンクをクリックして詳細なエラーメッセージを表示します。不正な SourceKey 構成または無効なログを確認してください。

REGEX_UNMATCHED_ALARM

processor_regex プラグインでエラーが発生しました。一致に失敗しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。特定のエラー情報に基づいて問題をトラブルシューティングします。

  • unmatch this log content...:ログの内容が構成の正規表現と一致しません。

  • match result count less...:一致した結果の数が、構成された Keys の数より少ないです。

SAME_CONFIG_ALARM

Logstore に同じ名前の構成が既に存在します。後で検出された構成は破棄されます。

エラーリンクをクリックして詳細なエラーメッセージを表示します。構成パスやその他の情報に基づいて構成エラーを確認してください。

SPLIT_FIND_ALARM

split_char および split_string プラグインでエラーが発生しました。プラグインが構成で SourceKey によって指定されたフィールドを見つけることができません。

エラーリンクをクリックして詳細なエラーメッセージを表示します。不正な SourceKey 構成または無効なログを確認してください。

SPLIT_LOG_ALARM

processor_split_char および processor_split_string プラグインでエラーが発生しました。解析されたフィールドの数が SplitKeys で指定された数と異なります。

エラーリンクをクリックして詳細なエラーメッセージを表示します。不正な SourceKey 構成または無効なログを確認してください。

STAT_FILE_ALARM

LogFileReader オブジェクトを使用してファイルからデータを収集する際にエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。ファイルパスとエラー情報に基づいて問題をトラブルシューティングします。

SERVICE_SYSLOG_INIT_ALARM

service_syslog プラグインでエラーが発生しました。プラグインの初期化に失敗しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。構成の Address パラメーターが正しいかどうかを確認してください。

SERVICE_SYSLOG_STREAM_ALARM

service_syslog プラグインで TCP 経由のデータ収集中にエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。特定のエラー詳細に基づいて問題をトラブルシューティングします。

  • accept error...:Accept コマンドの実行中にエラーが発生しました。プラグインは一定期間待機してから操作を再試行します。

  • setKeepAlive error...:プラグインが Keep-Alive の設定に失敗しました。プラグインはこのエラーをスキップして続行します。

  • connection i/o timeout...:TCP 読み取り操作がタイムアウトしました。プラグインはタイムアウト期間をリセットしてデータの読み取りを続行します。

  • scan error...:TCP 読み取りエラーが発生しました。プラグインは一定期間待機してから操作を再試行します。

SERVICE_SYSLOG_PACKET_ALARM

service_syslog プラグインで UDP 経由のデータ収集中にエラーが発生しました。

エラーリンクをクリックして詳細なエラーメッセージを表示します。エラーには次のサブタイプがあります。特定のエラー詳細に基づいて問題をトラブルシューティングします。

  • connection i/o timeout...:UDP 読み取り操作がタイムアウトしました。プラグインはタイムアウト期間をリセットしてデータの読み取りを続行します。

  • read from error...:UDP 読み取りエラーが発生しました。プラグインは一定期間待機してから操作を再試行します。

PARSE_TIME_FAIL_ALARM

プラグインがログ時間の解析に失敗しました。

次のいずれかの方法で問題を特定し、解決します。

  • 正規表現によって抽出された時間フィールドが正しいかどうかを確認します。

  • 指定された時間フィールドの内容が構成の時間式と一致するかどうかを確認します。

アプリケーションモニタリング

ACK クラスター内のアプリケーションにプローブをインストールした後、モニタリングデータが利用できない理由

原因

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

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

ソリューション

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

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

    2. [アプリケーションリスト] ページで、上部でリージョンを選択し、アプリケーションの名前をクリックします。

      アプリケーションが見つからない場合は、ステップ 2 に進みます。

    3. 新しいコンソールの場合:上部のナビゲーションバーで、アプリケーション設定 > カスタム設定 を選択します。[プローブスイッチ設定] セクションで、[アプリケーション監視を一時停止] スイッチの状態を確認します。

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

      • [アプリケーション監視を一時停止] スイッチがオフの場合は、ステップ 2 に進みます。

    4. 古いコンソールの場合:左側のナビゲーションウィンドウで [アプリケーション設定] をクリックし、[カスタム設定] タブをクリックします。[エージェントスイッチ設定] セクションで、[エージェントマスタースイッチ] がオンになっているかどうかを確認します。

      • [エージェントマスタースイッチ] がオフの場合は、オンにしてページ下部の [保存] をクリックします。

      • [エージェントマスタースイッチ] がオンの場合は、ステップ 2 に進みます。

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

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

    2. 左側のナビゲーションウィンドウで、ワークロード > Pod を選択します。

    3. [Pods] ページで、お使いのアプリケーションの名前空間を選択します。対象の Pod を見つけ、[操作] 列の [YAML の編集] をクリックします。

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

      state:
                running:
                  startedAt: '2023-01-13T08:50:46Z'
        hostIP: xxx.xxx.xx.196
        initContainerStatuses:
          - containerID: >-
              containerd://5d6cff441916ea146f6c9568e86e749817a64f212405349b5edc580991fb3195
            image: >-
              registry-vpc.cn-hangzhou.aliyuncs.com/ack-onepilot/ack-onepilot-init:3.0.6
            imageID: >-
              registry-vpc.cn-hangzhou.aliyuncs.com/ack-onepilot/ack-onepilot-init@sha256:93fe036b4c3dda4d4db3bc90de1e00972199a371ada31d1818b3395ecae8a145
            lastState: {}
            name: one-pilot-initcontainer
            ready: true
            restartCount: 0
            state:
              terminated:
                containerID: >-
                  containerd://5d6cff441916ea146f6c9568e86e749817a64f212405349b5edc580991fb3195
                exitCode: 0
                finishedAt: '2023-01-13T08:50:45Z'
                reason: Completed
                startedAt: '2023-01-13T08:50:31Z'
        phase: Running
        podIP: xxx.xxx.xx.241
        podIPs:
          - ip: xxx.xxx.xx.241
        qosClass: Guaranteed
        startTime: '2023-01-13T08:50:30Z'
      • 存在しない場合、one-pilot-initcontainer はインジェクトされていません。ステップ 5 に進みます。

      • 存在する場合、one-pilot-initcontainer はインジェクトされています。ステップ 8 に進みます。

    5. [ワークロード] > [Pod] ページで、ack-onepilot 名前空間を選択します。ack-onepilot というプレフィックスを持つ Pod が存在し、すべての ack-onepilot Pod がローリングアップデートを完了していることを確認します。

    6. [ワークロード] ページで、[デプロイメント] または [StatefulSet] ページに移動します。アプリケーションを見つけ、[操作] 列で image > [YAML の編集] を選択します。[YAML の編集] ダイアログボックスで、spec.template.metadata の下に次のラベルがあるかどうかを確認します。

      labels:
        armsPilotAutoEnable: "on"
        armsPilotCreateAppName: "<your-deployment-name>"    # <your-deployment-name> を実際のアプリケーション名に置き換えます。
        armsSecAutoEnable: "on"    # アプリケーションをアプリケーションセキュリティに接続する場合は、このパラメーターを設定する必要があります。
      • ラベルが存在する場合は、ステップ 7 に進みます。

      • ラベルが存在しない場合は、[YAML の編集] ダイアログボックスの spec.template.metadata パスにラベルを追加し、[更新] をクリックします。

    7. [ワークロード] > [Pod] ページで、ack-onepilot 名前空間を選択します。ack-onepilot プレフィックスを持つ Pod を見つけ、[操作] 列で [その他] > [ログ] を選択します。ログに STS エラー ("Message":"STS error" というメッセージで示される) がないか確認します。

      • STS エラーが報告された場合は、アプリケーションのクラスターを承認し、アプリケーション Pod を再起動します。手順については、「Container Service for Kubernetes の承認」をご参照ください。

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

    8. [ワークロード] > [Pod] ページで、ターゲット Pod を見つけ、[操作] 列の [YAML の編集] をクリックします。[YAML の編集] ダイアログボックスで、YAML ファイルに次の javaagent パラメーターが含まれているかどうかを確認します。

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

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

      • 利用可能な場合は、[Pod] ページで、右側にある [ターミナル] をクリックして [コマンドライン] ページを開き、次のコマンドを実行して .log ファイルを確認し、その後 チケットを送信します。

        cd /home/admin/.opt/ArmsAgent/logs
      • パラメーターが存在しない場合は、して、チケットを送信してください。

クラスターに ARMS アドオントークンが存在しない

症状

ターゲットクラスターに ARMS アドオントークンが存在しません。

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

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

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

    ARMS Addon Token

ソリューション

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

権限ポリシーを手動で追加する

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

  2. [クラスター情報] ページの [基本情報] タブで、[クラスターリソース] セクションの [ワーカー RAM ロール] の横にあるリンクをクリックします。

  3. 表示されたページの [権限] タブで、[権限を付与] をクリックします。

  4. [権限付与] パネルで、次のポリシーを追加し、[権限を付与] をクリックします。

    • AliyunTracingAnalysisFullAccess:Managed Service for OpenTelemetryへのフルアクセス。

    • AliyunARMSFullAccess:ARMS へのフルアクセス。

アプリケーションを別のクラスターまたは名前空間に移動した後、モニタリングデータが異常になる理由

現象

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

    image.png

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

考えられる原因

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

ソリューション

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

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

  • チケットを送信してください。

Java プローブのマウントパスをカスタマイズする方法

背景情報

通常、ack-onepilot アドオンは、環境変数 JAVA_TOOL_OPTIONS をインジェクトすることで、Java 用の Application Real-Time Monitoring Service (ARMS) エージェントのマウントパスを指定します。ただし、次のようなシナリオでは、このパスをカスタマイズする必要がある場合があります。

  • 構成管理の一元化

    Kubernetes ConfigMap を介してマウントパスを管理し、環境の一貫性を確保します。

  • 永続ストレージ

    企業のセキュリティまたは O&M 要件を満たすために、エージェントファイルをカスタムの永続ボリューム要求 (PVC) に保存します。

ソリューション

Java 用の ARMS エージェントのマウントパスをカスタマイズするには、次のバージョン要件を満たす必要があります。

重要

この構成は、共有の ack-onepilot 統合のため、Microservice Engine (MSE) にも適用されます。

  1. カスタムマウントパスが必要なデプロイメントなどの Kubernetes ワークロードに disableJavaToolOptionsInjection アノテーションを追加します。

    ack-onepilot アドオンは、環境変数 JAVA_TOOL_OPTIONS を使用してマウントパスやその他の Java 仮想マシン (JVM) パラメーターを自動的に設定しません。

    1. デプロイメントの YAML ファイルを表示するには、次のコマンドを実行します。

      kubectl get deployment {Deployment name} -o yaml
      説明

      デプロイメント名がわからない場合は、次のコマンドを実行してすべてのデプロイメントを一覧表示します。

      kubectl get deployments --all-namespace

      次に、結果から目的のデプロイメントを見つけ、その YAML ファイルを表示します。

    2. 次のコマンドを実行して YAML ファイルを編集します。

      kubectl edit deployment {Deployment name} -o yaml
    3. YAML ファイルで、spec.template.metadata に次のラベルを追加します。

      labels:
        armsPilotAutoEnable: "on"
        armsPilotCreateAppName: "<your-deployment-name>"    # ご利用のデプロイメントの名前。
        disableJavaToolOptionsInjection: "true" # Java 用 ARMS エージェントのマウントパスをカスタマイズする場合は、このパラメーターを true に設定します。
  2. Java 起動スクリプトまたはコマンドのデフォルトのマウントパス /home/admin/.opt/AliyunJavaAgent/aliyun-java-agent.jar をカスタムパスに置き換えます。

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

    レポートリージョンやライセンスキーなどのその他の情報は、ack-onepilot によって環境変数を介して提供されます。

ACK クラスターからリージョンをまたいでデータをレポートする方法

現象

リージョン 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 をインストールする方法

背景情報

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

ソリューション

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

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

    image

Managed Service for Prometheus

Prometheus モニタリングページに「関連するダッシュボードが見つかりません」と表示される

症状

Prometheus モニタリングを有効にした後、操作 > Prometheus 監視 ページに [関連するモニタリングダッシュボードが見つかりません] というプロンプトが表示される場合は、次の手順に従って問題を解決してください。

ソリューション

  1. Prometheus モニタリングアドオンを再インストールします。

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

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

      1. コンポーネントがアンインストールされたことを確認した後、インストール をクリックします。確認ダイアログボックスで、OK をクリックします。

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

        問題が解決しない場合は、次の手順に進みます。

  2. Prometheus インスタンスの統合を確認します。

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

    2. [連携] タブで、[コンテナサービス] リストに、お客様のクラスターと同じ名前のコンテナ環境があるか確認します。

      • そのようなコンテナ環境が存在しない場合は、「ARMS または Prometheus コンソールでサービスを統合する」をご参照ください。

      • そのようなコンテナ環境が存在する場合は、ターゲットコンテナ環境の 操作 列の [設定] をクリックして、[設定] ページに移動します。

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

Managed Service for Prometheus でデータが表示されない理由

原因

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

ソリューション

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

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

    2. クラスターリスト ページで、対象クラスターの名前をクリックします。左側のナビゲーションウィンドウで、ワークロード > ジョブ をクリックします。

    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. [統合] タブで、[Container Service] リストにクラスターと同じ名前のコンテナ環境があるかどうかを確認します。

      • そのようなコンテナ環境が存在しない場合は、「ARMS または Prometheus コンソールでサービスを統合する」をご参照ください。

      • そのようなコンテナ環境が存在する場合は、ターゲットコンテナ環境の 操作 列の [設定] をクリックして、[設定] ページに移動します。

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

Managed Service for Prometheus の再インストールに失敗し、「rendered manifests contain a resource that already exists」というエラーメッセージが報告される

症状

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
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 アドオンのバージョンを確認する方法

背景情報

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

ソリューション

    GPU モニタリングをデプロイできない理由

    原因

    ソリューション

      再インストール失敗を避けるために ARMS-Prometheus を完全にアンインストールする方法

      背景情報

      ソリューション

        ack-arms-prometheus アドオンのインストール時に「xxx in use」エラーが発生する

        原因

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

        ソリューション

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

        2. Helm ページで、ack-arms-prometheus が存在するかどうかを確認します。

        「コンポーネントがインストールされていません」というメッセージが表示された後、ack-arms-prometheus アドオンのインストールに失敗する

        症状

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

        ソリューション

        • ack-arms-prometheus アドオンがインストールされているかどうかを確認します。

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

          2. Helm ページで、ack-arms-prometheus が存在するかどうかを確認します。

        • ack-arms-prometheus のログでエラーを確認します。

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

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

          3. ログ タブをクリックして、ログにエラーがないか確認します。

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

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

          2. [統合] タブで、[Container Service] リストを確認します。ターゲットコンテナ環境の 操作 列で、[設定] をクリックして [設定] ページに移動します。

        オープンソース Prometheus モニタリング

        DingTalk のアラート通知を設定する方法

        現象

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

        ソリューション

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

        2. dingtalk フィールドを見つけ、enabled を true に設定し、Token フィールドに DingTalk の Webhook URL を入力します。「アラート設定」の [DingTalk アラートの設定] をご参照ください。

        prometheus-operator のデプロイ時にエラーが発生する

        症状

        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

        ソリューション

        このエラーは、以前のデプロイメントからの CRD がクリーンアップされなかったために発生します。CRD を削除してコンポーネントを再デプロイします。

        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 サーバーアドレスにはポート番号を含める必要があります。

        YAML の更新をクリックすると「クラスターにアクセスできません。後でもう一度試すか、チケットを送信してください。」というエラーメッセージが表示される

        症状

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

        ソリューション

        これは、Tiller 設定ファイルが大きすぎてクラスターにアクセスできなくなる場合に発生します。コメントを削除してファイルサイズを小さくし、ConfigMap としてマウントします。prometheus-operator は、prometheus および alertmanager Pod の ConfigMap マウントのみをサポートします。「カスタム ConfigMap を Prometheus にマウントする」をご参照ください。

        prometheus-operator をデプロイした後に機能を有効にする方法

        症状

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

        ソリューション

        prometheus-operator をデプロイした後に機能を有効にします。クラスター詳細ページで、アプリケーション > Helm を選択します。ack-prometheus-operator を見つけ、[操作] 列の 更新 をクリックします。有効にする機能を見つけて設定し、OK をクリックします。

        TSDB と Alibaba Cloud ディスクのどちらを選択すべきか

        現象

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

        ソリューション

        TSDB は Alibaba Cloud ディスクよりも利用可能なリージョンが少ないです。データ保持ポリシー:

        ## メトリクスを保持する期間
        ##
        retention: 10d

        Grafana ダッシュボードが正しく表示されない

        現象

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

        ソリューション

        クラスター詳細ページで、アプリケーション > Helm を選択します。ack-prometheus-operator を見つけ、[操作] 列の 更新 をクリックします。clusterVersion がクラスターのバージョンと一致していることを確認します。v1.16 より前のクラスターの場合は 1.14.8-aliyun.1 を入力します。v1.16 以降の場合は 1.16.6-aliyun.1 を入力します。

        名前空間を削除した後、ack-prometheus-operator の再インストールに失敗する

        原因

        名前空間のみを削除すると、残存構成が残る可能性があります。次のリソースをクリーンアップします。

        ソリューション

        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」というエラーメッセージが報告される

        症状

        アラートセンターで、アラートルールの同期ステータスに 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. 左側のナビゲーションウィンドウで、O&M > アラート を選択します

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

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

        アラートルールの同期に失敗し、「this rule have no xxx contact groups reference」というエラーメッセージが報告される

        現象

        設定またはデプロイ中にアラートルールの同期に失敗し、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 または kubectl top node を実行すると、データが返されません。

        ソリューション

        1. 次のコマンドを実行して、metrics-server API サービスが正常かどうかを確認します。

          kubectl get apiservices | grep metrics-server
          
          v1beta1.flowcontrol.apiserver.k8s.io          Local                     True        24d
          v1beta1.metrics.k8s.io                        kube-system/metrics-server   True        24d
          v1beta1.networking.k8s.io                     Local                     True        24d
          v1beta1.node.k8s.io                           Local                     True        24d

          v1beta1.metrics.k8s.io の返された結果が True を示している場合、metrics-server API サービスは正常です。

        2. オプション: metrics-server API サービスが正常でない場合は、クラスターノードで次のコマンドを実行して、metrics-server のポート 443 および 8082 がクラスター内で正常にアクセスできるかどうかを確認します。

          curl -v <metrics-server_Pod_IP>:8082/apis/metrics/v1alpha1/nodes
          
          curl -v <metrics-server_Pod_IP>:443/apis/metrics/v1alpha1/nodes

          コマンドが正常にデータを返す場合、metrics-server のポート 443 および 8082 はクラスター内で正常にアクセスできます。

        3. オプション: metrics-server のポート 443 および 8082 がクラスター内で正常にアクセスできない場合は、metrics-server を再起動します。

          metrics-server は、その Pod を削除することで再起動できます。

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

          2. クラスターリスト ページで、対象クラスターの名前をクリックします。左側のナビゲーションウィンドウで、ワークロード > デプロイメント をクリックします。

          3. [ステートレス] ページの上部で、[名前空間] を `kube-system` に設定し、`metrics-server` をクリックします。

          4. [Pods] タブで、metrics-server Pod の [アクション] 列にある [その他] > [削除] を選択し、表示されたダイアログボックスで [OK] をクリックします。

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

        症状

        kubectl top pod または kubectl top node を実行すると、一部のデータが欠落しています。

        ソリューション

        次の事前チェックを実行します。

        • 特定のノード上のすべての Pod にデータがないか、または特定の Pod にデータがないかを確認します。特定のノード上のすべての Pod にデータがない場合は、ノードにタイムゾーンのずれがあるかどうかを確認します。NTP サーバーで date コマンドを使用してタイムゾーンを確認できます。

        • metrics-server Pod から特定のノードのポート 10255 へのネットワーク接続を確認します。

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

        症状

        Kubernetes Horizontal Pod Autoscaler (HPA) を使用していると、メトリクスデータを取得できない状況が発生することがあります。

        ソリューション

        次の事前チェックを実行します。

        対応する Pod に対して kubectl top pod を実行した結果を確認します。データが異常な場合は、「kubectl top pod/node でデータが返されない理由」および「kubectl top pod/node で一部のデータが欠落している理由」のチェック方法をご参照ください。

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

        現象

        Kubernetes のローリングアップデート中に、Horizontal Pod Autoscaler (HPA) が予期せず余分な Pod を起動することがあります。

        ソリューション

        次の事前チェックを実行します。

        metrics-server が最新バージョンにアップグレードされているかどうかを確認します。バージョンが正しい場合は、kubectl edit deployments -n kube-system metrics-server コマンドを使用して、command セクションに次の起動パラメーターを追加します。

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