ログ配布機能により、MSE クラウドネイティブゲートウェイを Alibaba Cloud Simple Log Service (SLS) と統合し、ゲートウェイのアクセスログを分析してクライアントの動作を把握したり、ユーザーの地理的ディストリビューションをマッピングしたり、問題をトラブルシューティングしたりできます。本トピックでは、MSE クラウドネイティブゲートウェイでログ配布を有効にする方法について説明します。
前提条件
-
MSE クラウドネイティブゲートウェイインスタンスを作成済みである必要があります。詳細については、「クラウドネイティブゲートウェイの作成」をご参照ください。
-
Simple Log Service が有効になっている必要があります。まだ有効になっていない場合は、Alibaba Cloud アカウントで Simple Log Service コンソール にログインして有効化してください。詳細については、「Simple Log Service とは」をご参照ください。
ログ配布機能自体は無料ですが、使用量に基づいて Simple Log Service (SLS) の標準料金が適用されます。SLS の課金に関する詳細については、「従量課金」をご参照ください。
ログ配布の有効化
-
[MSE コンソール] にログインします。上部ナビゲーションバーでリージョンを選択します。
-
左側のナビゲーションウィンドウで、[Cloud-Native Gateway] > [ゲートウェイリスト] を選択します。「Gateways」ページで、対象のゲートウェイ ID をクリックします。
-
左側のナビゲーションウィンドウで、パラメーターの設定 をクリックします。オブザーバビリティパラメーター セクションで、ログシッピング の横にある編集アイコン
をクリックします。[ログ送信設定] ダイアログボックスで、ログ配信の有効化 (有効にすると、ゲートウェイのアクセスログが Simple Log Service に配信されます) スイッチをオンにします。説明-
ログ配布を有効にすると、Simple Log Service によってデフォルトの SLS プロジェクトが作成されます。既存の SLS プロジェクトを選択することも可能です。
-
トレーシング分析を有効にすると、[Tracing Analysis] コンソールでゲートウェイのモニタリングデータを確認できます。詳細については、「ゲートウェイのトレーシング分析の有効化」をご参照ください。
ログ配布を有効にした後、[オブザーバビリティパラメーター] セクションの [Project] 横にあるリンクをクリックすると、ゲートウェイの Logstore にリダイレクトされます。詳細については、「ログのクエリと分析のクイックスタート」をご参照ください。
-
トラブルシューティング:プラグインログに内容がない場合
ログ配布が有効になっているにもかかわらず、プラグインログをクエリしても内容が表示されない場合は、以下の順序でトラブルシューティングを行ってください。
-
クエリのタイムウィンドウを広げる:リクエストが発生した時刻をタイムウィンドウが確実にカバーしていることを確認します。Simple Log Service (SLS) のログ配布には数秒から数分の遅延があるため、必要に応じてタイムウィンドウを拡張してください。
-
リクエストがプラグインを呼び出していることを確認する:ゲートウェイのアクセスログで該当のリクエストレコードを探します。そのようなレコードが存在しない場合、リクエストはプラグインに到達していません。ルート構成を確認してください。
-
プラグインコード内のログ出力ロジックを確認する:ビジネスリクエストが実際にログ出力文に到達していることを検証します。ログ配布が正しく機能していても、プラグインコード内の条件付きブランチによってリクエストがログ出力文に到達しなければ、プラグインログには内容が含まれません。
ログ配布フィールド
|
フィールド名 |
タイプ |
説明 |
|
__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 を生成し、 |
|
requested_server_name |
string |
SSL 接続に使用されたサーバー名。 |
|
request_duration |
long |
ゲートウェイがダウンストリームリクエストの最初のバイトから最後のバイトを受信するまでの時間(ミリ秒単位)。 |
|
response_code |
long |
HTTP レスポンスの状態コード。 |
|
response_code_details |
string |
レスポンスコードに関する追加情報。たとえば、 |
|
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 |
|
|
ext_authz_status_code |
long |
カスタム権限付与サービスからのレスポンスコード。 |
|
ext_authz_duration |
long |
カスタム権限付与サービスの応答時間。 |
アクセスログへのカスタムフィールドの追加
アクセスログに Referer などのカスタムフィールドを記録するには、ログフォーマット調整機能を使用してカスタムログフォーマットを構成します。
-
ゲートウェイ詳細ページで、左側のナビゲーションウィンドウの [パラメーターの設定] をクリックします。
-
[Observability Parameters] セクションで、[Log Shipping] の下にある [Log Format Adjustment] を探します。
-
[Default Format (Click to Customize)] をクリックします。表示されるダイアログボックスで、[Add] をクリックします。
-
[Field Type] を [Request Header] に設定し、フィールド値(例:
Referer)を入力します。 -
[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_codeは404となり、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 解決の失敗によりリクエストが終了された。