カスタムログ形式
最終更新日 2021-08-16
リモートログストリーミングの設定を使用する場合、Fastly のカスタムログ形式には 2 つのバージョンがあります。新規のログエンドポイントはデフォルトでバージョン2のログ形式となります。バージョン1のログエンドポイントをバージョン2のログ形式にアップグレードすることができます。また、連続性を考慮してバージョン2をバージョン1形式に見えるように作成することも可能です。下記のバージョン2のログ形式の主な利点についても説明しています。
バージョン2のログ形式
以下の表には Fastly のバージョン2のログ形式に関する詳細が記載されています。表に示されるように、すべての変数の先頭にパーセント記号 (%
) を付ける必要があります。
書式 | 説明 |
---|---|
%% |
パーセント記号 |
%a |
リクエストのクライアント IP アドレス。req.http.Fastly-Client-IP に相当します。 |
%A |
ローカル IP アドレス。server-ip に相当します。 |
%B |
HTTP ヘッダーを除く、レスポンスサイズ (バイト)resp.body_bytes_written に相当します。 |
%b |
HTTP ヘッダーを除く、レスポンスサイズ (バイト)Common Log Format(CLF)では、送信データがないときは「0 」ではなく「"-" 」となります。 |
%{Foobar}C |
サーバーに送信されたリクエストの Cookie Foobar の内容 |
%D |
リクエストを処理するのにかかった時間 (マイクロ秒)time.elapsed.usec に相当します。 |
%{FOOBAR}e |
サポートされていません。常に 「"-" 」 を返します。 |
%f |
ファイル名Varnish にはファイル配信中の概念がないため、クエリ文字列が削除された場合、req.url に相当します。 |
%h |
リモート IP アドレスreq.http.Fastly-Client-IP に相当します。 |
%H |
リクエストのプロトコルreq.proto に相当します。 |
%{Foobar}i |
サーバーに送信されたリクエストヘッダー Foobar: の内容 |
%I |
リクエストとヘッダーを含む受信バイト数。ゼロになることはありません。req.bytes_read に相当します。 |
%k |
この接続で処理されたキープアライブリクエストの数。常に 0 を返します。 |
%l |
サポートされていません。常に 「"-" 」 を返します。 |
%m |
リクエストメソッドreq.request に相当します。 |
%{Foobar}n |
サポートされていません。常に 「"-" 」 を返します。 |
%{Foobar}o |
レスポンスの Foobar: ヘッダー行の内容 |
%O |
ヘッダーを含む送信バイト数。ゼロになることはありません。resp.bytes_written に相当します。 |
%p |
リクエストを処理するサーバーの正規のポート。常に 80 を返します。server.port に相当します。 |
%{format}p |
リクエストを処理するサーバーの正規のポート。有効な形式は canonical 、local 、remote です。HTTP リクエストの場合は 80 、HTTPS リクエストの場合は 443 を返します。 |
%P |
サポートされていません。常に 「"-" 」 を返します。 |
%{format}P |
サポートされていません。常に 「"-" 」 を返します。 |
%q |
クエリ文字列 (クエリ文字列が存在する場合は前に ? が追加され、存在しない場合は空文字列となります)req.url に相当します。 |
%r |
リクエストの最初の行 |
%R |
サポートされていません。常に "-" を返します。 |
%s |
ステータス。内部的にリダイレクトされたリクエストの場合、これは元のリクエストのステータスです。最終ステータスには %>s を使用します。resp.status に相当します。 |
%t |
リクエストが受信された時刻。標準の英語形式で表されます (01/Jan/1970:00:00:00 -0700 など)。最後の数字は GMT からのタイムゾーンオフセットを示します。 |
%{format}t |
format で与えられた形式の時刻。strftime(3) 形式でなければなりません (ローカライズされている可能性があります)。書式が begin: (デフォルト) で始まる場合、リクエスト処理の開始時に時間が取得されます。end: で始まる場合は、ログエントリーが書き込まれた時間で、リクエスト処理の終了時刻に近くなります。strftime(3) でサポートされている形式に加えて、以下のフォーマットトークンもサポートされています。 sec (エポックからの秒数)、msec (エポックからのミリ秒数)、usec (エポックからのマイクロ秒数)、msec_frac (ミリ秒数部分)、usec_frac (マイクロ秒数部分)。time.start に相当します。 |
%T |
リクエストを処理するのにかかった時間 (秒)time.elapsed.sec に相当します。 |
%u |
サポートされていません。常に 「"-" 」 を返します。 |
%U |
リクエストの URL パス。クエリ文字列は含まれません。req.url に相当します。 |
%v |
リクエストのドメイン名。req.http.host に相当します。 |
%V |
%v と同じです。req.http.host に相当します。 |
%{vcl}V |
引用符なしでインクルードするリテラル VCL。VCL 変数をログに書き込むために使用できます (%{client.geo.country_code}V または %{tls.client.cipher}V など)。この % のディレクティブは Fastly の拡張機能であり、Apache では存在しません。 |
%X |
応答が完了したときの接続ステータス。常に + を設定します (レスポンスが送信された後に接続が維持されます)。 |
バージョン1のログ形式
以下の表には Fastly のバージョン2のログ形式に関する詳細が記載されています。表に示されるように、すべての変数の先頭にパーセント記号 (%
) を付ける必要があります。
書式 | 説明 |
---|---|
%b |
レスポンスのコンテンツのサイズ。実際にレスポンスの長さをチェックするのではなく、Content-Length ヘッダーを使用して算出されます (そのため、正確でない可能性があります)。 |
%h |
リモート IP アドレス |
%l |
リモートログ名。常に 「"-" 」 を返します。 |
%r |
HTTP 動詞とリクエストパス (GET /index.html など)。Apache およびバージョン2のログ形式とは異なり、プロトコルのバージョンは含まれません。 |
%>s |
最後のリクエストのステータス |
%t |
リクエストを受信した時刻。Unix の ctime 形式 (例:Thu, 01 Jan 1970 00:00:00 GMT ) で、Apache の標準英語形式ではありません (例:01/Jan/1970:00:00:00 -0700 )。 |
%u |
常に 「"-" 」 を返します。 |
バージョン2のログ形式へのアップグレード
アップグレードは恒久的な変更です。version 2 formatting を実施したログオブジェクトは、バージョン 1 にダウングレードすることはできません。
ログエンドポイントをバージョン2のログ形式にアップグレードするには、以下の手順に従ってください。
- Fastly コントロールパネルにログインします。
- Home ページから、該当するサービスを選択します。検索ボックスを使用して ID、名前、またはドメインで検索することができます。
- Edit configuration ボタンをクリックし、アクティブなバージョンをクローンするオプションを選択します。ドメインページが表示されます。
-
Logging リンクをクリックします。 Logging endpoints ページが表示されます。バージョン1のログ形式を使用するログエンドポイントがある場合は、それらがアップグレード可能であることを示すメッセージが表示されます。
-
ログエンドポイントの名前をクリックして編集します。Edit this endpoint ページが表示されます。
-
Convert to Log Format Version 2 ボタンをクリックします。Convert to log format version 2 ページが表示されます。
- 出力形式を選択します。
- Use compatible output を使用することを推奨します。この設定では、タイムスタンプの文字列は変更されませんが、ログの書式は変更されます。新しい形式は Apache のログ形式と互換性があります。
- Maintain legacy output はバージョン2形式ですが、生成されるログ文字列は同じになります。つまり、
%t
が%{now}V
に、%r
が%{req.url}V
に、%b
が%{resp.http.Content-Length}V
となることを意味します。
- Select ボタンをクリックします。Edit this endpoint ページが表示されます。
- Update ボタンをクリックして、 当該ログエンドポイントをバージョン2のログ形式にアップグレードします。
- Activate ボタンをクリックして設定変更をデプロイします。
APIでアップグレードする
Fastly API を使用してログエンドポイントをアップグレードするには、アップグレードが必要なサービスのアクティブなバージョンをクローンしたバージョンか、ロックされていない非アクティブバージョンに対して、以下のコマンドを実行します。
1
$ curl -X PUT -H 'Fastly-Key: FASTLY_API_TOKEN' -H 'Content-Type: application/json' 'https://api.fastly.com/service/<your Fastly service ID>/version/<version number>/logging/<logging endpoint>/<log name>' --data-binary '{"format_version":"2"}'
format_version
フィールドはオブジェクトごとのフィールドであることに留意してください。ある1つのログオブジェクトで変更しても、他のオブジェクトには影響ありません。
例えば、「GCS Test」という名前の Google Cloud Storage エンドポイントをアップグレードする場合、curl コマンドは以下のようになります。
1
$ curl -X PUT -H 'Fastly-Key: FASTLY_API_TOKEN' -H 'Content-Type: application/json' 'https://api.fastly.com/service/SU1Z0isxPaozGVKXdv0eY/version/1/logging/gcs/GCS%20Test' --data-binary '{"format_version":"2"}'
log name
には、URL エンコードが必要なスペースが含まれています。(%20
のスペース)。
ログバージョンの判別
ご利用のサービスで現在使用されているログバージョンを判別するには、以下の curl コマンドを実行します。
1
$ curl -X GET -H 'Fastly-Key: FASTLY_API_TOKEN' 'https://api.fastly.com/service/<your Fastly service ID>/version/<version number>/logging/<logging endpoint>/<log name>'
curl コマンドによって、当該バージョンの設定内容の詳細が JSON 形式で出力されます。例えば、次のようにします。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"address": "logs.papertrailapp.com",
"created_at": "2016-04-01T15:37:30+00:00",
"deleted_at": null,
"format": "time.start.msec time.to_first_byte time.elapsed req.body_bytes_read req.bytes_read resp.http.content-length server.region client.ip %>s \"req.method req.url req.proto\" \"req.http.referer\" \"req.http.user-agent\"",
"format_version": "2",
"hostname": "logs.papertrailapp.com",
"name": "fastly",
"port": "11111",
"public_key": null,
"response_condition": "LOG /",
"service_id": "1a2b3c4d5e6f7g8h9j0k",
"updated_at": "2016-04-01T19:47:47+00:00",
"version": "123"
}
format_version
フィールドは、使用されているログ形式に応じて 1
または 2
のいずれかを表示します。
バージョン2のログ形式のメリット
バージョン2のログ形式を使用する主なメリットは以下のとおりです。
- ログは
vcl_deliver
ではなくvcl_log
で生成され、vcl_log
はオブジェクトがブラウザに渡された後に実行されるので、さまざまなサイズ変数を正確に設定することができます。 %t
ディレクティブは Apache のログ形式と互換性があります。バージョン 1 では、非標準の時刻形式を使用していました。%r
「first line of request」ディレクティブは、Apache のログ形式と互換性があります。バージョン1では、このプロトコルを不適切に残していました。- HTTP ヘッダーを除いたレスポンスサイズをバイト単位で表す
%b
ディレクティブを使用することで、より正確な情報を取得できます。バージョン1では、オリジンサーバから送られる Content-Lengthを使用していましたが、これは不正確な場合があります (特に ESI を利用している場合)。 - 意味のあるすべての Apache ログディレクティブを追加しました。バージョン1では、より小さなサブセットを使用していました。
バージョン2のログをバージョン1のように表示する
バージョン1のデフォルトのログ形式は以下のとおりです。
1
%h %l %u %t %r %>s
バージョン2のほとんどのディレクティブはまったく同じで、%t
と %r
だけが異なります。バージョン2のログ形式にアップグレードした後、新しい %{...}V
ディレクティブを使用して、バージョン1のログ形式と同じ出力を実現することができます。この場合、ログディレクティブに VCL を含むことが可能です。
1
%h %l %u %{now}V %{req.method}V %{req.url}V %>s
また、バージョン1で %b
ディレクティブを使用している場合、代わりに以下のディレクティブを使用できます。
1
%{resp.http.Content-Length}V