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

Microservices Engine:クラウドネイティブゲートウェイのログ配布の有効化

最終更新日:Aug 08, 2026

ログ配布機能により、MSE クラウドネイティブゲートウェイを Alibaba Cloud Simple Log Service (SLS) と統合し、ゲートウェイのアクセスログを分析してクライアントの動作を把握したり、ユーザーの地理的ディストリビューションをマッピングしたり、問題をトラブルシューティングしたりできます。本トピックでは、MSE クラウドネイティブゲートウェイでログ配布を有効にする方法について説明します。

前提条件

説明

ログ配布機能自体は無料ですが、使用量に基づいて Simple Log Service (SLS) の標準料金が適用されます。SLS の課金に関する詳細については、「従量課金」をご参照ください。

ログ配布の有効化

  1. [MSE コンソール] にログインします。上部ナビゲーションバーでリージョンを選択します。

  2. 左側のナビゲーションウィンドウで、[Cloud-Native Gateway] > [ゲートウェイリスト] を選択します。「Gateways」ページで、対象のゲートウェイ ID をクリックします。

  3. 左側のナビゲーションウィンドウで、パラメーターの設定 をクリックします。オブザーバビリティパラメーター セクションで、ログシッピング の横にある編集アイコン 2 をクリックします。[ログ送信設定] ダイアログボックスで、ログ配信の有効化 (有効にすると、ゲートウェイのアクセスログが Simple Log Service に配信されます) スイッチをオンにします。

    説明
    • ログ配布を有効にすると、Simple Log Service によってデフォルトの SLS プロジェクトが作成されます。既存の SLS プロジェクトを選択することも可能です。

    • トレーシング分析を有効にすると、[Tracing Analysis] コンソールでゲートウェイのモニタリングデータを確認できます。詳細については、「ゲートウェイのトレーシング分析の有効化」をご参照ください。

    ログ配布を有効にした後、[オブザーバビリティパラメーター] セクションの [Project] 横にあるリンクをクリックすると、ゲートウェイの Logstore にリダイレクトされます。詳細については、「ログのクエリと分析のクイックスタート」をご参照ください。

トラブルシューティング:プラグインログに内容がない場合

ログ配布が有効になっているにもかかわらず、プラグインログをクエリしても内容が表示されない場合は、以下の順序でトラブルシューティングを行ってください。

  1. クエリのタイムウィンドウを広げる:リクエストが発生した時刻をタイムウィンドウが確実にカバーしていることを確認します。Simple Log Service (SLS) のログ配布には数秒から数分の遅延があるため、必要に応じてタイムウィンドウを拡張してください。

  2. リクエストがプラグインを呼び出していることを確認する:ゲートウェイのアクセスログで該当のリクエストレコードを探します。そのようなレコードが存在しない場合、リクエストはプラグインに到達していません。ルート構成を確認してください。

  3. プラグインコード内のログ出力ロジックを確認する:ビジネスリクエストが実際にログ出力文に到達していることを検証します。ログ配布が正しく機能していても、プラグインコード内の条件付きブランチによってリクエストがログ出力文に到達しなければ、プラグインログには内容が含まれません。

ログ配布フィールド

フィールド名

タイプ

説明

__time__

long

ログエントリが生成された時刻。

cluster_id

string

ゲートウェイインスタンスの ID。

consumer

string

リクエストのコンシューマー。このフィールドは、コンシューマー認証が有効になっている場合にのみ設定されます。

custom_log

json

ユーザー定義のログフィールドを格納します。カスタムプラグインと併用できます。

authority

string

リクエスト内の Host ヘッダーの値。

bytes_received

long

ヘッダーを除くリクエスト本文のサイズ(バイト単位)。

bytes_sent

long

ヘッダーを除くレスポンス本文のサイズ(バイト単位)。

downstream_local_address

string

ゲートウェイ Pod のアドレス。

downstream_remote_address

string

ゲートウェイに接続しているクライアントのアドレス。

downstream_transport_failure_reason

string

ダウンストリームトランスポートの失敗理由。

duration

long

クライアントから最初のバイトを受信してからレスポンスの最後のバイトを送信するまでの、リクエスト処理時間の合計(ミリ秒単位)。

method

string

HTTP メソッド。

path

string

HTTP リクエスト内のパス。

protocol

string

HTTP プロトコルバージョン。

request_id

string

ゲートウェイは各リクエストに対して ID を生成し、x-request-id ヘッダーに含めます。バックエンドサービスはこの ID をログに記録して、トラブルシューティングに活用できます。

requested_server_name

string

SSL 接続に使用されたサーバー名。

request_duration

long

ゲートウェイがダウンストリームリクエストの最初のバイトから最後のバイトを受信するまでの時間(ミリ秒単位)。

response_code

long

HTTP レスポンスの状態コード。

response_code_details

string

レスポンスコードに関する追加情報。たとえば、via_upstream はバックエンドサービスがレスポンスコードを返したことを示し、route_not_found はリクエストに一致するルートが見つからなかったことを示します。

response_flags

string

レスポンスの失敗理由。

response_tx_duration

long

ゲートウェイがアップストリームサービスから最初のバイトを受信してから、ダウンストリームクライアントに最後のバイトを送信するまでの時間(ミリ秒単位)。

route_name

string

ルートの名前。

start_time

string

UTC 形式でのリクエスト開始時刻。

trace_id

string

トレース ID。

upstream_cluster

string

アップストリームクラスター。

upstream_host

string

アップストリームサービスの IP アドレス。

upstream_local_address

string

アップストリームサービスへの接続に使用されたローカルアドレス。

upstream_protocol

string

バックエンドサービスへのリクエストに使用されたプロトコル。

upstream_service_time

long

アップストリームサービスがリクエストを処理するのに要する時間(ミリ秒単位)。この期間にはネットワーク遅延とサービス自身の処理時間が含まれます。

upstream_transport_failure_reason

string

アップストリーム接続の失敗理由。

user_agent

string

HTTP リクエスト内の User-Agent ヘッダー。

x_forwarded_for

string

x-forwarded-for HTTP ヘッダーの値。このヘッダーは通常、クライアントの実際の IP アドレスを示します。

ext_authz_status_code

long

カスタム権限付与サービスからのレスポンスコード。

ext_authz_duration

long

カスタム権限付与サービスの応答時間。

アクセスログへのカスタムフィールドの追加

アクセスログに Referer などのカスタムフィールドを記録するには、ログフォーマット調整機能を使用してカスタムログフォーマットを構成します。

  1. ゲートウェイ詳細ページで、左側のナビゲーションウィンドウの [パラメーターの設定] をクリックします。

  2. [Observability Parameters] セクションで、[Log Shipping] の下にある [Log Format Adjustment] を探します。

  3. [Default Format (Click to Customize)] をクリックします。表示されるダイアログボックスで、[Add] をクリックします。

  4. [Field Type] を [Request Header] に設定し、フィールド値(例:Referer)を入力します。

  5. [OK] をクリックして構成を保存します。ステータスが [Custom Format (Click to Edit)] に変更されます。

構成が適用されると、Referer リクエストヘッダーを含むリクエストが記録され、アクセスログの request_headers フィールドに Referer 値が含まれるようになります。

ログフォーマット調整では、以下のフィールドタイプがサポートされています:リクエストヘッダー、レスポンスヘッダー、リクエスト動的メタデータ、レスポンス動的メタデータ。

レスポンスフラグ

リクエストの失敗理由は、主にログ内の Response_Flag の値によって判断されます。以下に、Response_Flag のさまざまな値について説明します。

説明

ここでの「ダウンストリーム」とはクライアントを、「アップストリーム」とはバックエンドサービスを指します。

  • UH:クラスター内で正常なアップストリームホストが利用できない。

  • UF:アップストリーム接続に失敗した。

  • NR:リクエストに一致する構成済みのルートがない。リクエストがどのルートにも一致しない場合(response_flags=NR かつ response_code_details=route_not_found)、response_code404 となり、route_name および upstream_cluster はどちらも - と表示されます。この場合、リクエストはゲートウェイルレイヤーで拒否され、バックエンドサービスには到達しません。そのため、upstream_cluster およびすべての upstream_* フィールドが空になるのは期待される動作であり、アップストリームクラスターの構成に問題があるわけではありません。この問題をトラブルシューティングするには、リクエストパスに対してルートが構成されているかどうかを確認してください。

  • URX:アップストリームのリトライ制限(HTTP)または最大接続試行回数(TCP)に達したため、リクエストが拒否された。

  • NC:アップストリームクラスターが見つからない。

  • DT:リクエストまたは接続が max_connection_duration または max_downstream_connection_duration を超過した。

  • DC:ダウンストリーム接続が終了された。

  • LH:ローカルサービスがヘルスチェックリクエストに失敗した。

  • UT:アップストリームリクエストがタイムアウトした。

  • LR:接続がローカルでリセットされた。

  • UR:アップストリーム接続がリモートでリセットされた。

  • UC:アップストリーム接続が終了された。

  • DI:障害注入によって指定された期間、リクエスト処理が遅延された。

  • FI:障害注入によって指定されたレスポンスコードでリクエストが中止された。

  • RL:HTTP レート制限フィルターによってローカルでリクエストが制限された(429 レスポンスを除く)。

  • UAEX:外部権限付与サービスによってリクエストが拒否された。

  • RLSE:レート制限サービスのエラーによりリクエストが拒否された。

  • IH:厳密にチェックされたヘッダーに無効な値が含まれていたため、リクエストが拒否された。

  • SI:ストリームのアイドルタイムアウトに達した。

  • DPE:ダウンストリームリクエストで HTTP プロトコルエラーが発生した。

  • UPE:アップストリームレスポンスで HTTP プロトコルエラーが発生した。

  • UMSDR:アップストリームリクエストが最大持続時間に達した。

  • OM:オーバーロードマネージャーによってリクエストが終了された。

  • DF:DNS 解決の失敗によりリクエストが終了された。