カスタムログ形式

リモートログストリーミングの設定を使用する場合、Fastly のカスタムログ形式には 2 つのバージョンがあります。新規のログエンドポイントはデフォルトでバージョン2のログ形式となります。バージョン1のログエンドポイントをバージョン2のログ形式にアップグレードすることができます。また、連続性を考慮してバージョン2をバージョン1形式に見えるように作成することも可能です。下記のバージョン2のログ形式の主な利点についても説明しています。

バージョン2のログ形式

以下の表には Fastly のバージョン2のログ形式に関する詳細が記載されています。表に示されるように、すべての変数の先頭にパーセント記号 (%) を付ける必要があります。

バージョン1のログ形式

以下の表には Fastly のバージョン2のログ形式に関する詳細が記載されています。表に示されるように、すべての変数の先頭にパーセント記号 (%) を付ける必要があります。

バージョン2のログ形式へのアップグレード

ログエンドポイントをバージョン2のログ形式にアップグレードするには、以下の手順に従ってください。

1. Fastly コントロールパネルにログインします。
2. Home ページから、該当するサービスを選択します。検索ボックスを使用して ID、名前、またはドメインで検索することができます。
3. Edit configuration ボタンをクリックし、アクティブなバージョンをクローンするオプションを選択します。ドメインページが表示されます。

4. Logging リンクをクリックします。 Logging endpoints ページが表示されます。バージョン1のログ形式を使用するログエンドポイントがある場合は、それらがアップグレード可能であることを示すメッセージが表示されます。

   

5. ログエンドポイントの名前をクリックして編集します。Edit this endpoint ページが表示されます。

   

6. Convert to Log Format Version 2 ボタンをクリックします。Convert to log format version 2 ページが表示されます。

   

7. 出力形式を選択します。
   • Use compatible output を使用することを推奨します。この設定では、タイムスタンプの文字列は変更されませんが、ログの書式は変更されます。新しい形式は Apache のログ形式と互換性があります。
   • Maintain legacy output はバージョン2形式ですが、生成されるログ文字列は同じになります。つまり、%t が %{now}V に、%r が %{req.url}V に、%b が %{resp.http.Content-Length}V となることを意味します。
8. Select ボタンをクリックします。Edit this endpoint ページが表示されます。
9. Update ボタンをクリックして、 当該ログエンドポイントをバージョン2のログ形式にアップグレードします。
10. 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"}'

ログバージョンの判別

ご利用のサービスで現在使用されているログバージョンを判別するには、以下の 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