コンテナ化された環境では、アプリケーションログが複数の Docker コンテナの標準出力およびログファイルに分散しており、管理および取得が困難になります。Simple Log Service (SLS) の LoongCollector を使用して、複数のノードからログを 1 つの Logstore に集約します。これにより、集中型ストレージ、構造化解析、データマスキング、フィルタリング、および効率的なクエリと分析が可能になります。
注意事項
権限要件：デプロイに使用する Alibaba Cloud アカウントまたは RAM ユーザーには、
AliyunLogFullAccess権限が必要です。Docker バージョンおよび LoongCollector の要件：
Docker Engine のバージョンが 29.0 以降、またはサポートされる最小 Docker API バージョンが 1.42 以降 の場合、LoongCollector 3.2.4 以降 を使用する必要があります。それ以外の場合、LoongCollector はコンテナの標準出力またはファイルログを収集できません。
LoongCollector のバージョン 3.2.4 以降 は、Docker API バージョン 1.24 ～ 1.48 をサポートします。
LoongCollector のバージョン 3.2.3 以前 は、Docker API バージョン 1.18 ～ 1.41 をサポートします。
標準出力の収集に関する制限：
Docker 設定ファイル daemon.json に、
"log-driver": "json-file"を追加する必要があります。CentOS 7.4 以降（CentOS 8.0 を除く）では、
fs.may_detach_mounts=1を設定する必要があります。
テキストログ収集の制限：overlay および overlay2 ストレージドライバーのみがサポートされています。その他のドライバータイプを使用する場合は、ログディレクトリを手動でマウントする必要があります。
収集設定の作成手順
事前準備：プロジェクトおよび Logstore を作成します。プロジェクトは、異なるアプリケーションのログを分離するために使用されるリソース管理単位であり、Logstore はログを格納するために使用されます。
マシングループの構成（LoongCollector のインストール）：ログを収集するサーバーに LoongCollector をインストールし、サーバーをマシングループに追加します。マシングループを使用すると、収集ノードを一元管理し、構成を配布し、サーバーのステータスを管理できます。
グローバルおよび入力構成：収集設定の名前、およびログ収集のソースと範囲を定義します。
ログ処理および構造化：ログ形式に基づいて処理ルールを構成します。
マルチラインログ：Java 例外スタックや Python トレースバックなど、複数行にわたる単一のログに該当します。各ログの開始行を特定するために正規表現を使用する必要があります。
構造化解析：正規表現、区切り文字、NGINX モードなどの解析プラグインを構成して、生の文字列を構造化されたキーと値のペアに抽出します。これにより、後続のクエリおよび分析が容易になります。
ログフィルタリング：収集ブラックリストおよびコンテンツフィルタリングルールを構成して、有効なログコンテンツをスクリーニングします。これにより、冗長なデータの送信およびストレージが削減されます。
ログ分類：トピックおよびログタグを構成して、異なるアプリケーション、コンテナ、またはパスソースからのログを柔軟に区別します。
クエリおよび分析の構成：システムはデフォルトでフルテキストインデックスを有効化しており、キーワード検索をサポートします。正確なクエリおよび構造化フィールドの分析を実現し、検索効率を向上させるために、フィールドインデックスの有効化を推奨します。
検証およびトラブルシューティング：構成の完了後、ログが正常に収集されていることを確認します。データが収集されない、ハートビートが失敗する、または解析エラーが発生するなどの問題が発生した場合は、「よくある質問」セクションをご参照ください。
事前準備
ログを収集する前に、ログの管理および保存のためのプロジェクトおよび Logstore を計画・作成する必要があります。必要なリソースが既に存在する場合は、この手順をスキップして、「ステップ 1：マシングループの構成（LoongCollector のインストール）」に進んでください。
プロジェクトの作成
Logstore の作成
プロジェクト名をクリックします。
左側のナビゲーションウィンドウで、
を選択し、＋ をクリックします。Logstore の作成ページで、以下のコアパラメーターを構成します。
Logstore 名：プロジェクト内で一意の名前を入力します。この名前は Logstore 作成後に変更できません。
Logstore タイプ：仕様を比較して、標準またはクエリを選択します。
課金モード：
機能ごとの課金：ストレージ、インデックス作成、読み書き操作などのリソースを個別に課金します。小規模なシナリオや機能の利用状況が不透明な場合に適しています。
取り込みデータ量による課金：書き込まれた生データ量に対してのみ課金されます。30 日間の無料ストレージおよびデータ変換、配信などの無料機能が提供されます。ストレージ期間が約 30 日間であるビジネスシナリオや、データ処理パイプラインが複雑な場合に適しています。
データ保持期間：ログを保持する日数を指定します。有効値は 1 ～ 3650 日です。3650 を指定すると永続保存となります。デフォルト値は 30 日です。
その他のパラメーターはデフォルト設定のままにして、OK をクリックします。「Logstore の管理」については、詳細をご参照ください。
ステップ 1：マシングループの構成（LoongCollector のインストール）
Docker ホスト上でコンテナとして LoongCollector をデプロイし、ホストをマシングループに追加します。マシングループを使用して、複数の収集ノードを一元管理し、構成を配布し、ステータスを監視します。
イメージをプルする
Docker がインストールされているホストで、以下のコマンドを実行して LoongCollector イメージをプルします。
${region_id}は、ホストまたは近隣のリージョン（例：cn-hangzhou）の リージョン ID に置き換え、ダウンロード速度および安定性を向上させます。# LoongCollector イメージアドレス docker pull aliyun-observability-release-registry.${region_id}.cr.aliyuncs.com/loongcollector/loongcollector:v3.0.12.0-25723a1-aliyun # Logtail イメージアドレス docker pull registry.${region_id}.aliyuncs.com/log-service/logtail:v2.1.11.0-aliyunLoongCollector コンテナの起動
以下のコマンドを実行してコンテナを起動します。ディレクトリのマウントおよび必要な環境変数の設定が正しく行われていることを確認してください。
docker run -d \ -v /:/logtail_host:ro \ -v /var/run/docker.sock:/var/run/docker.sock \ --env ALIYUN_LOGTAIL_CONFIG=/etc/ilogtail/conf/${sls_upload_channel}/ilogtail_config.json \ --env ALIYUN_LOGTAIL_USER_ID=${aliyun_account_id} \ --env ALIYUN_LOGTAIL_USER_DEFINED_ID=${user_defined_id} \ aliyun-observability-release-registry.${region_id}.cr.aliyuncs.com/loongcollector/loongcollector:v3.0.12.0-25723a1-aliyunパラメーターの説明：
${sls_upload_channel}：ログアップロードチャネル。形式は プロジェクト リージョン-ネットワーク転送タイプ です。例：転送タイプ
構成値の形式
例
シナリオ
内部ネットワーク転送
regionIdcn-hangzhouECS インスタンスとプロジェクトが同一リージョンにある場合。
インターネット転送
regionId-internetcn-hangzhou-internetECS インスタンスとプロジェクトが異なるリージョンにある場合。
サーバーが他のクラウドプロバイダーまたはオンプレミスのデータセンターから提供されている場合。
転送アクセラレーション
regionId-accelerationcn-hangzhou-acceleration中国内外でのクロスリージョン通信。
${aliyun_account_id}：Alibaba Cloud アカウント ID です。${user_defined_id}：マシングループのカスタム ID です。この ID はマシングループのバインドに使用されます。例：user-defined-docker-1。この ID はリージョン内で一意である必要があります。重要以下の起動条件を満たす必要があります。
3 つの主要な環境変数が正しく構成されていること：
ALIYUN_LOGTAIL_CONFIG、ALIYUN_LOGTAIL_USER_ID、およびALIYUN_LOGTAIL_USER_DEFINED_ID。/var/run/docker.sockディレクトリがマウントされていること。このディレクトリは、コンテナライフサイクルイベントをリッスンするために使用されます。ルートディレクトリ
/が/logtail_hostにマウントされていること。これはホストファイルシステムへのアクセスに使用されます。
コンテナの実行ステータスの確認
docker ps | grep loongcollector期待される出力例：
6ad510001753 aliyun-observability-release-registry.cn-beijing.cr.aliyuncs.com/loongcollector/loongcollector:v3.0.12.0-25723a1-aliyun "/usr/local/ilogtail…" 約 1 分前 Up 約 1 分前 recursing_shirleyマシングループの構成
左側のナビゲーションウィンドウで、
リソース > マシングループ を選択し、
> マシングループの作成 をクリックし、以下のパラメーターを構成して OK をクリックします。名前：マシングループのカスタム名（例：
docker-host-group）を入力します。マシングループ識別子：カスタム識別子 を選択します。
カスタム識別子：コンテナ起動時に設定した
${user_defined_id}を入力します。ID は完全に一致する必要があります。そうでないと関連付けが失敗します。
マシングループのハートビートステータスの確認
新しく作成したマシングループの名前をクリックして詳細ページに移動し、「」を確認します。
OK： LoongCollector が SLS に接続されていることを示します。
FAIL： 問題のトラブルシューティング方法については、「ハートビートエラーのトラブルシューティング」をご参照ください。
ステップ 2：ログ収集ルールの作成および構成
LoongCollector がどのログを収集するか、その構造をどのように解析するか、コンテンツをどのようにフィルタリングするか、および構成を登録済みのマシングループにどのようにバインドするかを定義します。
「
Logstores」ページで、対象の Logstore 名の横にある「
」アイコンをクリックします。[データ収集] の横にある
をクリックします。[クイックデータインポート] ダイアログボックスで、ログソースに基づいてテンプレートを選択し、[今すぐ統合] をクリックします。Docker 標準出力：「Docker 標準出力および標準エラー - 新バージョン」を選択します。
コンテナ標準出力の収集には、新バージョンおよび旧バージョンの 2 つのテンプレートがあります。新バージョンの使用を推奨します。「付録：コンテナ標準出力の新旧バージョンの比較」で、新バージョンと旧バージョンの違いについて詳しく説明しています。旧バージョンを使用して収集する場合は、「Docker コンテナの標準出力の収集（旧バージョン）」をご参照ください。
Docker ファイルログ：「Docker ファイル - コンテナ」を選択します。
マシングループ を構成し、「次へ」をクリックします。
シナリオ：「Docker コンテナ」を選択します。
「ステップ 1」で作成したマシングループを、ソースマシングループリストから適用マシングループリストに移動します。
「Logtail 構成」ページで、以下のパラメーターを構成し、「次へ」をクリックします。
1．グローバルおよび入力構成
開始する前に、データインポートテンプレートを選択し、マシングループをバインドしていることを確認してください。このステップでは、収集設定の名前、ログソース、および収集範囲を定義します。
Docker 標準出力の収集
グローバル構成
構成名：収集設定のカスタム名を入力します。この名前はプロジェクト内で一意である必要があり、構成作成後に変更できません。以下の規則に従う必要があります。
小文字、数字、ハイフン (-)、アンダースコア (_) のみを使用できます。
小文字または数字で始まり、小文字または数字で終わる必要があります。
入力構成
標準出力および標準エラー または 標準エラー のスイッチをオンにします。両方のスイッチはデフォルトでオンになっています。
重要収集されたログで混乱が生じる可能性があるため、標準出力と標準エラーを同時に有効化しないことを推奨します。
Docker コンテナテキストログの収集
グローバル構成：
構成名：収集設定のカスタム名を入力します。この名前はプロジェクト内で一意である必要があり、構成作成後に変更できません。以下の規則に従う必要があります。
小文字、数字、ハイフン (-)、アンダースコア (_) のみを使用できます。
小文字または数字で始まり、小文字または数字で終わる必要があります。
入力構成：
ファイルパスタイプ：
コンテナ内のパス：コンテナ内からログファイルを収集します。
ホストパス：ホスト上のローカルサービスからログを収集します。
ファイルパス：収集対象のログファイルの絶対パスです。
Linux：パスはスラッシュ (`/`) で始める必要があります。例：
/data/mylogs/**/*.logは、/data/mylogsディレクトリ内の `.log` 拡張子を持つすべてのファイルを意味します。Windows：パスはドライブ文字で始める必要があります。例：
C:\Program Files\Intel\**\*.Log。
最大ディレクトリ監視深度：ファイルパス 内のワイルドカード文字
**が一致できる最大ディレクトリ深度です。デフォルト値は 0（現在のディレクトリ）で、0 ～ 1000 の範囲で指定できます。このパラメーターは 0 に設定し、ファイルが含まれるディレクトリへのパスを構成することを推奨します。
2．ログ処理および構造化
未加工の非構造化ログを構造化されたデータに変換するログ処理ルールを構成します。これにより、ログのクエリおよび分析の効率が向上します。ルールを構成する前に、ログサンプルを追加することを推奨します。
「プロセッサ構成」セクションの「Logtail 構成」ページで、「ログサンプルの追加」をクリックし、収集対象のログの内容を入力します。システムはサンプルに基づいてログ形式を識別し、正規表現および解析ルールの生成を支援します。これにより、構成が簡素化されます。
シナリオ 1：マルチラインログ処理（Java スタックログなど）
Java 例外スタックや JSON オブジェクトなどのログは、多くの場合複数行にわたります。デフォルトの収集モードでは、これらのログは複数の不完全なレコードに分割され、コンテキストが失われます。この問題に対処するため、マルチライン収集モードを有効化し、各行の開始を識別する正規表現を構成して、同じログの連続する行を 1 つの完全なログエントリにマージします。
効果の例：
処理なしの生ログ | デフォルト収集モードでは、各行が独立したログとして扱われるため、スタック情報が分割され、コンテキストが失われる | マルチラインモードを有効化すると、各行の開始を識別する正規表現により、完全なログが識別され、完全な意味的構造が保持される |
|
|
|
構成：「プロセッサ構成」セクションの「Logtail 構成」ページで、「マルチラインモード」をオンにします。
タイプ：カスタム または マルチライン JSON を選択します。
カスタム：生ログの形式が固定されていない場合です。各ログエントリの開始行を識別するための 最初の行に一致する正規表現 を構成する必要があります。
最初の行に一致する正規表現：自動生成または手動入力が可能です。正規表現は完全な 1 行のデータに一致する必要があります。前述の例の一致正規表現は
\[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*です。自動生成：「生成」をクリックします。その後、「ログサンプル」テキストボックスで抽出対象のログコンテンツを選択し、「自動的に生成」をクリックします。
手動入力：「正規表現を手動で入力」をクリックします。式を入力した後、「検証」をクリックします。
マルチライン JSON：生ログがすべて標準 JSON 形式である場合、SLS は単一の JSON ログ内の改行を自動的に処理します。
分割失敗時の処理方法：
破棄：テキストの一部が行頭ルールに一致しない場合、そのテキストは破棄されます。
単一行を保持：一致しなかったテキストはチャンク化され、元の単一行モードで保持されます。
シナリオ 2：構造化ログ
生ログが NGINX アクセスログやアプリケーション出力ログなどの非構造化または半構造化テキストである場合、直接のクエリおよび分析は効率的でないことが多くあります。SLS は、さまざまなデータ解析プラグインを提供しており、異なる形式の生ログを自動的に構造化されたデータに変換できます。これにより、後続の分析、モニタリング、およびアラート機能のための堅固なデータ基盤が提供されます。
効果の例：
生ログ | 解析済みログ |
| |
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで：
解析プラグインの追加：「プロセッサの追加」をクリックし、ログ形式に一致する正規表現解析、区切り文字解析、JSON 解析などのプラグインを構成します。例：NGINX ログを収集する場合は、「」を選択します。
NGINX ログ構成：NGINX サーバー構成ファイル（nginx.conf）から完全な
log_format定義をコピーし、このテキストボックスに貼り付けます。例：
log_format main '$remote_addr - $remote_user [$time_local] "$request" ''$request_time $request_length ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent"';重要フォーマット定義は、サーバーでログを生成するために使用されるフォーマットと完全に一致している必要があります。そうでないと、ログ解析が失敗します。
共通パラメーター：複数のデータ解析プラグインで表示される以下のパラメーターは、その機能および使用法が一貫しています。
元のフィールド：解析対象のソースフィールドの名前です。デフォルト値は
contentで、収集されたログの全コンテンツを意味します。解析失敗時に元のフィールドを保持：このスイッチをオンにすることを推奨します。プラグインによる解析がフォーマット不一致で失敗した場合でも、このオプションにより元のログコンテンツが失われず、指定された生フィールドに保持されます。
解析成功時に元のフィールドを保持：このオプションを選択すると、ログが正常に解析された場合でも、元のログコンテンツが保持されます。
3．ログフィルタリング
ログ収集中に、DEBUG や INFO レベルなどの低価値または無関係なログを無差別に収集すると、ストレージリソースの浪費、コスト増加、クエリ効率の低下、データ侵害リスクの発生につながります。これらの問題に対処するため、効率的かつ安全なログ収集を実現するための細かいフィルタリング戦略を実装します。
コンテンツフィルタリングによるコスト削減
フィールドコンテンツに基づいてログをフィルタリングします。例：WARNING や ERROR レベルのログのみを収集します。
効果の例：
処理なしの生ログ |
|
| |
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで：
「プロセッサの追加」をクリックし、「」を選択します。
フィールド名：フィルタリングに使用するログフィールドです。
フィールド値：フィルタリングに使用する正規表現です。完全一致のみがサポートされ、部分キーワード一致はサポートされません。
ブラックリストによる収集範囲の制御
ブラックリストを使用して、指定されたディレクトリまたはファイルを除外します。これにより、無関係または機密性の高いログのアップロードを防止できます。
構成手順：「入力構成」セクションの「Logtail 構成」ページで、「収集ブラックリスト」を有効化し、「追加」をクリックします。
ディレクトリおよびファイル名には完全一致およびワイルドカード一致がサポートされています。サポートされるワイルドカード文字はアスタリスク (`*`) および疑問符 (`?`) です。
ファイルパスブラックリスト：無視するファイルパスです。例：
/home/admin/private*.log：「/home/admin/」ディレクトリ内において、「private」で始まり、「.log」で終わるすべてのファイルを収集から除外します。/home/admin/private*/*_inner.log：「/home/admin/」ディレクトリ下の「private」で始まるディレクトリ内において、「_inner.log」で終わるファイルを収集から除外します。
ファイルブラックリスト：収集時に無視するファイル名です。例：
app_inner.log：「app_inner.log」という名前のすべてのファイルを収集から除外します。
ディレクトリブラックリスト：ディレクトリパスはスラッシュ (`/`) で終わってはいけません。例：
/home/admin/dir1/：ディレクトリブラックリストは適用されません。/home/admin/dir*：コレクション時に、/home/admin/ディレクトリ配下の、「dir」で始まるすべてのサブディレクトリ内のファイルを無視します。/home/admin/*/dir：「/home/admin/」ディレクトリの第 2 レベルにある「dir」という名前のサブディレクトリ内のすべてのファイルを収集から除外します。例：「/home/admin/a/dir」ディレクトリ内のファイルは除外されますが、「/home/admin/a/b/dir」ディレクトリ内のファイルは収集されます。
コンテナフィルタリング
環境変数、Pod ラベル、名前空間、コンテナ名などのコンテナメタデータに基づいて収集条件を設定し、どのコンテナのログを収集するかを正確に制御します。
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで、「コンテナフィルタリング」を有効化し、「追加」をクリックします。
複数の条件は AND 論理演算子で結合されます。すべての正規表現一致は Go の RE2 正規表現エンジンに基づいており、PCRE などのエンジンと比較していくつかの制限があります。正規表現を作成する際は、「付録：正規表現の制限（コンテナフィルタリング）」で説明されている制限に従ってください。
環境変数ブラックリスト／許可リスト：ログを収集するコンテナの環境変数条件を指定します。
K8s Pod ラベルブラックリスト／許可リスト：ログを収集するコンテナが配置されている Pod のラベル条件を指定します。
K8s Pod 名の正規表現一致：Pod 名に基づいて収集するコンテナを指定します。
K8s 名前空間の正規表現一致：名前空間名に基づいて収集するコンテナを指定します。
K8s コンテナ名の正規表現一致：コンテナ名に基づいて収集するコンテナを指定します。
コンテナラベルブラックリスト／許可リスト：指定された条件を満たすラベルを持つコンテナからログを収集します。このパラメーターは Docker シナリオで使用され、Kubernetes シナリオでは推奨されません。
4．ログ分類
複数のアプリケーションまたはインスタンスが同じログ形式を共有する場合、ログソースを区別することが難しくなり、クエリ時にコンテキストが欠如し、分析効率が低下します。この問題に対処するため、トピックおよびログタグを構成して、自動化されたコンテキスト関連付けおよび論理的分類を実現します。
トピックの構成
複数のアプリケーションまたはインスタンスが同じログ形式だが異なるパス（例：/apps/app-A/run.log および /apps/app-B/run.log）を持つ場合、収集されたログのソースを区別することが困難になります。マシングループ、カスタム名、またはファイルパス抽出に基づいてトピックを生成することで、異なるアプリケーションまたはパスソースからのログを柔軟に区別できます。
構成手順： ：トピック生成方法を選択します。以下の 3 種類がサポートされています。
マシングループトピック：収集構成が複数のマシングループに適用される場合、LoongCollector はサーバーが属するマシングループの名前を
__topic__フィールドの値として自動的に使用してアップロードします。これは、ホストクラスターごとにログが分割されるシナリオに適しています。カスタム：形式は
customized://<custom_topic_name>です。例：customized://app-login。これは、固定されたビジネス識別子を持つ静的なトピックシナリオに適しています。ファイルパス抽出：ログファイルの完全なパスから重要な情報を抽出して、ログソースを動的にマークします。これは、複数のユーザーまたはアプリケーションが同じログファイル名を共有しているが、パスが異なる場合に適しています。
複数のユーザーまたはサービスが異なる最上位ディレクトリにログを書き込むが、サブパスおよびファイル名が同じである場合、ファイル名のみではソースを区別できません。例：
/data/logs ├── userA │ └── serviceA │ └── service.log ├── userB │ └── serviceA │ └── service.log └── userC └── serviceA └── service.log「ファイルパス抽出」を構成し、完全なパスから重要な情報を抽出する正規表現を使用します。一致した結果はトピックとして Logstore にアップロードされます。
抽出ルール：正規表現キャプチャグループに基づく
正規表現を構成する際、システムはキャプチャグループの数および命名に基づいて自動的に出力フィールド形式を決定します。ルールは以下のとおりです。
ファイルパスの正規表現では、スラッシュ (/) をエスケープする必要があります。
キャプチャグループの種類
シナリオ
生成されるフィールド
正規表現の例
一致するパスの例
生成されるフィールド
単一のキャプチャグループ（
(.*?)が 1 つだけ）ソースを区別するために必要なのは 1 つの次元のみ（例：ユーザー名、環境）
__topic__フィールドが生成される\/logs\/(.*?)\/app\.log/logs/userA/app.log__topic__:userA複数のキャプチャグループ（名前なし）（
(.*?)が複数）複数の次元が必要だが、意味的なラベルは不要
__tag__:__topic_{i}__というタグフィールドが生成される。ここで{i}はキャプチャグループの序数\/logs\/(.*?)\/(.*?)\/app\.log/logs/userA/svcA/app.log__tag__:__topic_1__userA；__tag__:__topic_2__svcA複数のキャプチャグループ（名前付き）（
(?P<name>.*？)を使用）複数の次元が必要で、フィールドの意味を明確にしてクエリおよび分析を容易にしたい
__tag__:{name}というタグフィールドが生成される\/logs\/(?P<user>.*?)\/(?P<service>.*?)\/app\.log/logs/userA/svcA/app.log__tag__:user:userA；__tag__:service:svcA
ログタグ付け
ログタグの強化機能を有効化して、コンテナの環境変数または Kubernetes Pod ラベルから重要な情報を抽出し、それをタグとして添付します。これにより、ログの細かいグルーピングが実現されます。
構成手順：「入力構成」セクションの「Logtail 構成」ページで、「ログタグの強化」を有効化し、「追加」をクリックします。
環境変数：環境変数名およびタグ名を構成します。環境変数の値はタグ名に格納されます。
環境変数名：抽出対象の環境変数の名前を指定します。
タグ名：環境変数タグの名前です。
Pod ラベル：Pod ラベル名およびタグ名を構成します。Pod ラベルの値はタグ名に格納されます。
Pod ラベル名：抽出対象の Kubernetes Pod ラベルの名前です。
タグ名：タグの名前です。
5．出力構成
デフォルトでは、すべてのログが lz4 圧縮で現在の Logstore に送信されます。同じソースからのログを異なる Logstore に送信するには、以下の手順に従います。
複数のターゲットへの動的配信
-
複数のターゲットへのログ送信は、LoongCollector 3.0.0 以降でのみ利用可能です。Logtail ではサポートされていません。
-
最大 5 個の出力ターゲットを構成できます。
-
複数の出力ターゲットを構成した後、収集構成は現在の Logstore の収集構成リストには表示されなくなります。マルチターゲット配信構成を表示、変更、または削除するには、「マルチターゲット配信構成の管理方法」をご参照ください。
手順：「出力構成」セクションの「Logtail 構成」ページで
-
「
」をクリックして出力構成を展開します。 -
出力先の追加 をクリックし、以下の設定を構成します。
-
Logstore：ターゲット Logstore を選択します。
-
圧縮方法：lz4 または zstd を選択します。
-
ルート設定：タグフィールドに基づいてログをルーティングします。ルーティングルールに一致するログはターゲット Logstore に送信されます。この構成が空の場合、収集されたすべてのログがターゲット Logstore に送信されます。
-
タグ名：ルーティングに使用するタグフィールドの名前です。例：
__path__のように、フィールド名を直接入力します。__tag__:接頭辞は不要です。タグフィールドには以下の 2 種類があります。タグの詳細については、「LoongCollector 収集タグの管理」をご参照ください。
-
エージェント関連：収集エージェントに関連するタグで、プラグインとは無関係です。例：
__hostname__および__user_defined_id__。 -
入力プラグイン関連：入力プラグインに依存するタグで、関連する情報をログに追加および強化します。例：ファイル収集の
__path__、Kubernetes 収集の_pod_name_および_container_name_。
-
-
タグ値：ログのタグ値がこの値と一致する場合、そのログはこのターゲット Logstore に送信されます。
-
このタグフィールドを破棄するかどうか：このオプションを有効化すると、アップロードされたログからこのタグフィールドが削除されます。
-
-
ステップ 3：クエリおよび分析の構成
ログ処理およびプラグイン構成を完了した後、「次へ」をクリックして「クエリおよび分析の構成」ページに移動します。
システムはデフォルトで フルテキストインデックス を有効化しており、元のログコンテンツに対するキーワード検索をサポートします。
フィールドごとの正確なクエリを実行するには、ページ上の「プレビュー データ」が読み込まれた後、「自動インデックス生成」をクリックします。SLS はプレビュー データの最初のエントリに基づいて フィールドインデックス を生成します。
構成を完了した後、「次へ」をクリックして、収集プロセス全体の設定を完了します。
ステップ 4：検証およびトラブルシューティング
収集構成が完了し、マシングループに適用されると、システムは自動的に構成を配布し、増分ログの収集を開始します。
アップロードされたログの表示
ログファイルに新しいコンテンツがあることを確認：LoongCollector は増分ログのみを収集します。
tail -f /path/to/your/log/fileを実行し、ビジネス操作をトリガーして、新しいログが書き込まれていることを確認します。ログのクエリ：対象 Logstore のクエリおよび分析ページに移動し、「検索および分析」（デフォルトの時間範囲は過去 15 分）をクリックし、新しいログが流入しているかどうかを確認します。収集された各 Docker コンテナテキストログには、デフォルトで以下のフィールドが含まれます。
フィールド名
説明
__source__
LoongCollector（Logtail）コンテナの IP アドレス。
_container_ip_
アプリケーションコンテナの IP アドレス。
__tag__:__hostname__
LoongCollector（Logtail）が配置されている Docker ホストの名前。
__tag__:__path__
ログ収集パス。
__tag__:__receive_time__
ログがサーバーに到着した時刻。
__tag__:__user_defined_id__
マシングループのカスタム ID。
よくある質問
マシングループのハートビート接続が FAIL になる
ユーザー ID を確認します：サーバータイプが ECS でない場合、または ECS インスタンスとプロジェクトが異なる Alibaba Cloud アカウントに属している場合、以下の表に基づいて、指定されたディレクトリに正しいユーザー ID が存在するかどうかを確認します。
Linux：コマンド
cd /etc/ilogtail/users/ && touch <uid>を実行してユーザー ID ファイルを作成します。Windows：「
C:\LogtailData\users\」ディレクトリに、「<uid>」という名前の空のファイルを作成します。
指定されたパスに現在のプロジェクトの Alibaba Cloud アカウント ID を名前に持つファイルが存在する場合、ユーザー ID は正しく構成されています。
マシングループ ID を確認します：マシングループにカスタム ID を使用している場合、指定されたディレクトリに
user_defined_idファイルが存在するかどうかを確認します。存在する場合、そのファイルの内容がマシングループに構成されたカスタム ID と一致するかどうかを確認します。システム
指定ディレクトリ
解決策
Linux
/etc/ilogtail/user_defined_id# カスタム ID を構成します。ディレクトリが存在しない場合は、手動で作成します。 echo "user-defined-1" > /etc/ilogtail/user_defined_idWindows
C:\LogtailData\user_defined_id「
user_defined_id」ファイルを「C:\LogtailData」ディレクトリに新しく作成し、カスタム ID を書き込みます。（ディレクトリが存在しない場合は、手動で作成します。）ユーザー ID およびマシングループ ID の両方が正しく構成されている場合、「LoongCollector（Logtail）マシングループの問題のトラブルシューティング」を参照して、さらにトラブルシューティングを行ってください。
ログが収集されない
増分ログの有無を確認：LoongCollector（Logtail）の収集を構成した後、収集対象のログファイルに新しいログがない場合、LoongCollector（Logtail）はそのファイルからログを収集しません。
マシングループのハートビートステータスを確認：「
リソース > マシングループ」ページに移動し、対象のマシングループの名前をクリックし、「」セクションで「ハートビート」ステータスを確認します。ハートビートが OK の場合、マシングループは SLS プロジェクトに接続されています。
ハートビートが FAIL の場合：問題のトラブルシューティング方法については、「マシングループのハートビート接続が FAIL になる」をご参照ください。
LoongCollector（Logtail）収集構成がマシングループに適用されているかどうかを確認：LoongCollector（Logtail）収集構成が作成されていても、その構成がマシングループに適用されていない場合、ログは収集されません。
「
リソース > マシングループ」ページに移動し、対象のマシングループの名前をクリックして「マシングループ構成」ページに移動します。ページで「構成の管理」を確認します。左側には「すべての Logtail 構成」、右側には「適用済みの Logtail 構成」が表示されます。対象の LoongCollector（Logtail）収集構成の名前が右側の適用済み領域に移動されている場合、その構成は対象のマシングループに正常に適用されています。
対象の LoongCollector（Logtail）収集構成の名前が右側の適用済み領域に移動されていない場合、「編集」をクリックします。左側の「すべての Logtail 構成」リストで、対象の LoongCollector（Logtail）構成の名前を選択し、「
」をクリックして右側の適用済み領域に移動し、「保存」をクリックします。
ログ収集エラーまたは不正なフォーマット
トラブルシューティングのアプローチ：この状況は、ネットワーク接続および基本構成が正常であることを示しています。問題は主にログコンテンツと解析ルールの不一致に起因します。具体的なエラーメッセージを確認して問題を特定する必要があります。
「Logtail 構成」ページで、収集エラーが発生している LoongCollector（Logtail）構成の名前をクリックします。「ログ収集エラー」タブで、「時間範囲の選択」をクリックしてクエリ時間を設定します。
「」セクションで、エラーログのアラームメトリクスを確認し、「データ収集における一般的なエラーの種類」で対応する解決策を確認します。
次のステップ
データ可視化：可視化ダッシュボードを使用して、主要なメトリクスの傾向をモニタリングします。
データ異常の自動アラート：アラートポリシーを設定して、システムの異常をリアルタイムで把握します。
一般的なコマンド
LoongCollector（Logtail）の実行ステータスの表示
docker exec ${logtail_container_id} /etc/init.d/ilogtaild statusLoongCollector（Logtail）のバージョン番号、IP アドレス、起動時間などの情報の表示
docker exec ${logtail_container_id} cat /usr/local/ilogtail/app_info.jsonLoongCollector（Logtail）の実行ログの表示
LoongCollector（Logtail）の実行ログは、コンテナ内の /usr/local/ilogtail/ ディレクトリに保存されます。ファイル名は ilogtail.LOG で、ローテーションされたファイルは ilogtail.LOG.x.gz として圧縮保存されます。例：
# LoongCollector の実行ログを表示
docker exec a287de895e40 tail -n 5 /usr/local/ilogtail/loongcollector.LOG
# Logtail の実行ログを表示
docker exec a287de895e40 tail -n 5 /usr/local/ilogtail/ilogtail.LOG出力例：
[2025-08-25 09:17:44.610496] [info] [22] /build/loongcollector/file_server/polling/PollingModify.cpp:75 polling modify resume:succeeded
[2025-08-25 09:17:44.610497] [info] [22] /build/loongcollector/file_server/polling/PollingDirFile.cpp:100 polling discovery resume:starts
[2025-08-25 09:17:44.610498] [info] [22] /build/loongcollector/file_server/polling/PollingDirFile.cpp:103 polling discovery resume:succeeded
[2025-08-25 09:17:44.610499] [info] [22] /build/loongcollector/file_server/FileServer.cpp:117 file server resume:succeeded
[2025-08-25 09:17:44.610500] [info] [22] /build/loongcollector/file_server/EventDispatcher.cpp:1019 checkpoint dump:succeededLoongCollector（Logtail）の再起動
# loongcollector を停止
docker exec a287de895e40 /etc/init.d/ilogtaild stop
# loongcollector を起動
docker exec a287de895e40 /etc/init.d/ilogtaild startよくある質問
一般的なエラーメッセージ
エラー現象 | 原因 | 解決策 |
| プロジェクトのリージョンと LoongCollector（Logtail）コンテナのリージョンが一致していない。 |
|
| ファイルパス構成が正しくない。 | アプリケーションコンテナ内のログパスが収集構成と一致していることを確認します。 |
エラーログ：パラメーターが無効です : uuid=none
問題の説明： LoongCollector（Logtail）ログ（/usr/local/ilogtail/ilogtail.LOG）に、エラーログ パラメーターが無効です : uuid=none が含まれています。
解決策：ホスト上で product_uuid ファイルを作成し、任意の有効な UUID（例：169E98C9-ABC0-4A92-B1D2-AA6239C0D261）を入力し、このファイルを LoongCollector（Logtail）コンテナの /sys/class/dmi/id/product_uuid ディレクトリにマウントします。
同じログファイルまたはコンテナ標準出力を複数の収集構成で同時に収集することは可能ですか？
デフォルトでは、データの重複を防ぐため、SLS は各ログソースを 1 つの収集構成のみで収集することを制限しています。
テキストログファイルは、1 つの Logtail 構成のみと一致できます。
コンテナ標準出力（stdout）：
標準出力テンプレートの新バージョンを使用している場合、デフォルトで 1 つの標準出力収集構成でのみ収集できます。
標準出力テンプレートの旧バージョンを使用している場合、追加の構成は不要で、デフォルトで複数のコピーの収集がサポートされます。
「Simple Log Service コンソール」にログインし、対象のプロジェクトに移動します。
左側のナビゲーションウィンドウで、「
Logstores」を選択し、対象の Logstore を探します。その名前の横にある「
」アイコンをクリックして Logstore を展開します。Logtail 構成 をクリックします。構成リストで対象の Logtail 構成を探し、アクション列の「Logtail 構成の管理」をクリックします。
Logtail 構成ページで、「編集」をクリックし、下にスクロールして「入力構成」セクションに移動します。
テキストファイルログの収集：「ファイルを複数回収集可能にする」を有効化します。
コンテナ標準出力の収集：「異なる Logtail 構成による収集を許可」をオンにします。
マルチターゲット配信構成の管理方法
マルチターゲット配信構成は複数の Logstore に関連付けられています。これらの構成は、プロジェクトレベルの管理ページから管理します。
-
「Simple Log Service コンソール」にログインし、対象のプロジェクト名をクリックします。
-
プロジェクトページで、左側のナビゲーションウィンドウから「
を選択します。説明このページでは、関連付けられた Logstore が誤って削除された後でも残る構成を含む、プロジェクト内のすべての収集構成を一元管理できます。
付録：ネイティブ解析プラグインの詳細説明
「処理構成」セクションの「Logtail 構成」ページで、処理プラグインを追加して、生ログの構造化処理を構成します。既存の収集構成に処理プラグインを追加するには、以下の手順に従います。
左側のナビゲーションウィンドウで、「
Logstores」を選択し、対象の Logstore を探します。その名前の横にある「
」アイコンをクリックして Logstore を展開します。Logtail 構成 をクリックします。構成リストで対象の Logtail 構成を探し、アクション列の「Logtail 構成の管理」をクリックします。
Logtail 構成ページで、「編集」をクリックします。
このセクションでは、一般的なログ処理シナリオをカバーする、よく使用される処理プラグインのみを紹介します。その他の機能については、「拡張処理プラグイン」をご参照ください。
プラグインの組み合わせルール（LoongCollector／Logtail 2.0 以降で適用）：
ネイティブ処理プラグインおよび拡張処理プラグインは、必要に応じて個別または組み合わせて使用できます。
パフォーマンスおよび安定性が高いため、ネイティブ処理プラグインを優先して使用することを推奨します。
ネイティブ機能ではビジネス要件を満たせない場合、構成済みのネイティブ処理プラグインの後に拡張処理プラグインを追加して、補足的な処理を実行します。
順序制約：
すべてのプラグインは、構成された順序で逐次実行され、処理チェーンを形成します。注意点として、すべてのネイティブ処理プラグインは、拡張処理プラグインより前に配置する必要があります。拡張処理プラグインを追加した後は、ネイティブ処理プラグインを追加できません。
正規表現解析
正規表現を使用してログフィールドを抽出し、ログをキーと値のペアに解析します。各フィールドは個別にクエリおよび分析できます。
効果の例：
処理なしの生ログ | 正規表現解析プラグインの使用 |
| |
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで、「プロセッサの追加」をクリックし、「」を選択します。
正規表現：ログに一致させるために使用します。自動生成または手動入力が可能です。
自動生成：
「生成」をクリックします。
「ログサンプル」で、抽出するログコンテンツをハイライトします。
「正規表現の生成」をクリックします。
手動入力：「正規表現を手動で入力」をクリックし、ログ形式に基づいて入力します。
構成が完了したら、「検証」をクリックして、正規表現がログコンテンツを正しく解析できるかテストします。
抽出されたフィールド：抽出されたログコンテンツ（値）に対応するフィールド名（キー）を設定します。
その他のパラメーターについては、「シナリオ 2：構造化ログ」の共通構成パラメーターの説明をご参照ください。
区切り文字解析
区切り文字を使用してログコンテンツを構造化し、複数のキーと値のペアに解析します。単一文字および複数文字の区切り文字がサポートされています。
効果の例：
処理なしの生ログ | 指定された文字 |
| |
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで、「プロセッサの追加」をクリックし、「」を選択します。
区切り文字：ログコンテンツを分割するために使用する文字を指定します。
例：CSV 形式のファイルの場合、「カスタム」を選択し、カンマ（,）を入力します。
引用符：フィールド値に区切り文字が含まれる場合、誤った分割を防ぐためにフィールドを囲む引用符を指定する必要があります。
抽出されたフィールド：各列に対応するフィールド名（キー）を分割順に設定します。ルールは以下のとおりです。
フィールド名には、英字、数字、アンダースコア (_) のみを使用できます。
英字またはアンダースコア (_) で始まる必要があります。
最大長は 128 バイトです。
その他のパラメーターについては、「シナリオ 2：構造化ログ」の共通構成パラメーターの説明をご参照ください。
標準 JSON 解析
オブジェクト型の JSON ログをキーと値のペアに解析して構造化します。
効果の例：
処理なしの生ログ | 標準 JSON のキーと値の自動抽出 |
| |
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで、「プロセッサの追加」をクリックし、「」を選択します。
元のフィールド：デフォルト値は content です。このフィールドは、解析対象の生ログコンテンツを格納するために使用されます。
その他のパラメーターについては、「シナリオ 2：構造化ログ」の共通構成パラメーターの説明をご参照ください。
ネストされた JSON 解析
展開深度を指定して、ネストされた JSON ログをキーと値のペアに解析します。
効果の例：
処理なしの生ログ | 展開深度：0、展開深度をプレフィックスとして使用 | 展開深度：1、展開深度をプレフィックスとして使用 |
| | |
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで、「プロセッサの追加」をクリックし、「」を選択します。
元のフィールド：展開対象の生フィールド名（例：
content）。JSON 展開深度：JSON オブジェクトの展開レベル。値 0 は完全展開（デフォルト値）、値 1 は現在のレベルを示します。
展開されたキーを連結する文字：JSON 展開時のフィールド名の連結文字。デフォルトの連結文字はアンダースコア (_) です。
展開されたキーの名前プレフィックス：JSON 展開後のフィールド名のプレフィックスを指定します。
配列の展開：このスイッチをオンにすると、配列がインデックス付きのキーと値のペアに展開されます。
例：
{"k":["a","b"]}は{"k[0]":"a","k[1]":"b"}に展開されます。展開されたフィールドの名前を変更する場合（例：prefix_s_key_k1 を new_field_name に変更）、フィールド名の変更 プラグインを追加してマッピングを完了します。
その他のパラメーターについては、「シナリオ 2：構造化ログ」の共通構成パラメーターの説明をご参照ください。
JSON 配列解析
json_extract 関数を使用して、JSON 配列から JSON オブジェクトを抽出します。
効果の例：
処理なしの生ログ | JSON 配列構造の抽出 |
| |
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで、「処理方法」を「SPL」に切り替え、「SPL 文」を構成し、json_extract 関数を使用して JSON 配列から JSON オブジェクトを抽出します。
例：ログフィールド content の JSON 配列から要素を抽出し、結果を新しいフィールド json1 および json2 に格納します。
* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')Apache ログ解析
Apache ログ構成ファイルの定義に基づいてログコンテンツを構造化し、複数のキーと値のペアに解析します。
効果の例：
処理なしの生ログ | Apache 共通ログ形式 |
| |
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで、「プロセッサの追加」をクリックし、「」を選択します。
ログ形式：combined
APACHE LogFormat 構成：システムは「ログ形式」に基づいて構成を自動的に入力します。
重要自動入力された内容が、サーバーの Apache 構成ファイルで定義されている LogFormat と完全に一致していることを確認してください。このファイルは通常、/etc/apache2/apache2.conf にあります。
その他のパラメーターについては、「シナリオ 2：構造化ログ」の共通構成パラメーターの説明をご参照ください。
データマスキング
ログ内の機密データをマスクします。
効果の例：
処理なしの生ログ | マスキング結果 |
| |
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで、「プロセッサの追加」をクリックし、「」を選択します。
時間解析
ログ内の時間フィールドを解析し、解析結果をログの __time__ フィールドの値として設定します。
効果の例：
処理なしの生ログ | 時間解析 |
|
|
構成手順：「プロセッサ構成」セクションの「Logtail 構成」ページで、「プロセッサの追加」をクリックし、「」を選択します。
元のフィールド：解析前のログコンテンツを含む生フィールド。
時間形式：ログ内の時間コンテンツに基づいて、対応する時間形式を設定します。
タイムゾーン：ログ時間フィールドのタイムゾーンを選択します。デフォルトでは、LoongCollector（Logtail）プロセスが実行されている環境のタイムゾーンであるマシンタイムゾーンが使用されます。
付録：正規表現の制限（コンテナフィルタリング）
コンテナフィルタリングに使用される正規表現は、Go の RE2 エンジンに基づいており、PCRE などの他のエンジンと比較していくつかの構文上の制限があります。正規表現を作成する際には、以下の点にご注意ください。
1. 名前付きグループ構文の違い
Go は名前付きグループを定義するために (?P<name>...) 構文を使用し、PCRE の (?<name>...) 構文はサポートしていません。
正しい例：
(?P<year>\d{4})不正な構文：
(?<year>\d{4})
2. サポートされていない正規表現機能
以下の一般的だが複雑な正規表現機能は RE2 では利用できません。これらは使用しないでください。
アサーション：
(?=...)、(?!...)、(?<=...)、（?<!...)条件式：
(?(condition)true|false)再帰マッチング：
(?R)、(?0)サブルーチン参照：
(?&name)、(?P>name)アトミックグループ：
(?>...)
3. 使用上の推奨事項
正規表現のデバッグには、Regex101 などのツールを使用することを推奨します。互換性を確保するために、Golang（RE2）モードを選択して検証してください。上記で述べたサポートされていない構文を使用すると、プラグインは正しく解析またはマッチングを行いません。
付録：コンテナ標準出力の新旧バージョンの比較
ログストレージの効率と収集の一貫性を向上させるため、コンテナ標準出力のログメタデータ形式がアップグレードされました。新しい形式では、メタデータが __tag__ フィールドに統合され、ストレージの最適化とフォーマットの標準化が実現されています。
新しい標準出力バージョンの主な利点
大幅なパフォーマンス向上
C++ で再構築され、古い Go 実装と比較してパフォーマンスが 180% ～ 300% 向上しました。
データ処理のためのネイティブプラグインとマルチスレッド並列処理をサポートし、システムリソースを最大限に活用します。
ネイティブプラグインと Go プラグインを柔軟に組み合わせて、複雑なシナリオ要件に対応します。
信頼性の向上
標準出力ログローテーションキューをサポートします。ログ収集メカニズムはファイル収集メカニズムと統一されており、標準出力ログの高速なローテーションシナリオで高い信頼性を提供します。
リソース消費の低減
CPU 使用率が 20% ～ 25% 削減されます。
メモリ使用量が 20% ～ 25% 削減されます。
運用保守の一貫性の向上
統一されたパラメーター構成：新しい標準出力収集プラグインの構成パラメーターは、ファイル収集プラグインと一貫しています。
統一されたメタデータ管理：コンテナメタデータフィールドの命名とタグログのストレージ場所は、ファイル収集シナリオと統一されています。コンシューマー側は 1 つの処理ロジックのみを維持すれば済みます。
新旧バージョンの機能比較
機能の次元
旧バージョンの特徴
新バージョンの特徴
ストレージ方法
メタデータは通常フィールドとしてログコンテンツに直接埋め込まれます。
メタデータは
__tag__タグに一元的に格納されます。ストレージ効率
各ログが完全なメタデータを繰り返し保持するため、より多くのストレージスペースを消費します。
同じコンテキスト内の複数のログがメタデータを再利用できるため、ストレージコストが節約されます。
フォーマットの一貫性
コンテナファイル収集フォーマットと一貫性がありません。
フィールドの命名とストレージ構造は、コンテナファイル収集と完全に整合しており、統一されたエクスペリエンスを提供します。
クエリアクセス方法
フィールド名で直接クエリできます。例：
_container_name_。__tag__を介して対応するキーと値にアクセスする必要があります。例：__tag__: _container_name_。コンテナメタデータフィールドマッピングテーブル
旧バージョンのフィールド名
新バージョンのフィールド名
_container_ip_
__tag__:_container_ip_
_container_name_
__tag__:_container_name_
_image_name_
__tag__:_image_name_
_namespace_
__tag__:_namespace_
_pod_name_
__tag__:_pod_name_
_pod_uid_
__tag__:_pod_uid_
新バージョンでは、すべてのメタデータフィールドはログのタグ領域に
__tag__:<key>の形式で格納され、ログコンテンツに埋め込まれることはありません。新バージョン変更のユーザーへの影響
コンシューマー側の適応：ストレージ場所が「コンテンツ」から「タグ」に変更されたため、ユーザーのログ消費ロジックを適宜調整する必要があります。例：クエリ時に __tag__ を介してフィールドにアクセスする必要があります。
SQL 互換性：クエリ SQL は自動的に互換性が確保されるように調整されているため、ユーザーは新旧両バージョンのログを同時に処理するためにクエリ文を変更する必要はありません。
詳細情報
グローバル構成パラメーター
入力構成パラメーター
処理構成パラメーター
リージョン
「Simple Log Service コンソール」にログインします。プロジェクトリストで、対象のプロジェクトをクリックします。
プロジェクト名の横にある「
」アイコンをクリックして、プロジェクトの概要ページに移動します。「基本情報」セクションで、現在のプロジェクトのリージョン名を確認できます。リージョン名とリージョン ID のマッピングについては、以下の表をご参照ください。
リージョンとは、クラウドサービスがホストされている物理データセンターの地理的な場所です。リージョン ID は、クラウドサービスリージョンの一意の識別子です。
リージョン名
リージョン ID
中国 (青島)
cn-qingdao
中国 (北京)
cn-beijing
中国 (張家口)
cn-zhangjiakou
中国 (フフホト)
cn-huhehaote
中国 (ウランチャブ)
cn-wulanchabu
中国 (杭州)
cn-hangzhou
中国 (上海)
cn-shanghai
中国 (南京 - ローカルリージョン - 提供終了)
cn-nanjing
中国 (福州 - ローカルリージョン - 提供終了)
cn-fuzhou
中国 (深セン)
cn-shenzhen
中国 (河源)
cn-heyuan
中国 (広州)
cn-guangzhou
フィリピン (マニラ)
ap-southeast-6
韓国 (ソウル)
ap-northeast-2
マレーシア (クアラルンプール)
ap-southeast-3
日本 (東京)
ap-northeast-1
タイ (バンコク)
ap-southeast-7
中国 (成都)
cn-chengdu
シンガポール
ap-southeast-1
インドネシア (ジャカルタ)
ap-southeast-5
中国 (香港)
cn-hongkong
ドイツ (フランクフルト)
eu-central-1
米国 (バージニア)
us-east-1
米国 (シリコンバレー)
us-west-1
イギリス (ロンドン)
eu-west-1
UAE (ドバイ)
me-east-1
SAU (Riyadh - パートナーリージョン)
me-central-1