このドキュメントでは、Cloud Logging からサポートされている宛先に転送したログエントリを見つける方法について説明します。
| 発信先 | ルーティングの頻度 |
|---|---|
| Cloud Storage バケット | 1 時間ごとに一括 |
| BigQuery テーブル | ほぼリアルタイム |
| Pub/Sub トピック | ほぼリアルタイム |
| Cloud Logging バケット | ほぼリアルタイム |
| サードパーティの宛先（Splunk） | ほぼリアルタイム |
シンクのコンセプトについては、転送とストレージの概要: シンクをご覧ください。
ログを転送する方法については、シンクを構成するをご覧ください。
Cloud Storage
ルーティングしたログを Cloud Storage で表示する方法は次のとおりです。
Cloud Console の Cloud Storage ブラウザに移動してください。
転送先として使用する Cloud Storage バケットを選択します。
Cloud Storage バケットでログを整理する方法の詳細については、このドキュメントの Cloud Storage の構成をご覧ください。
ルーティングの頻度
Cloud Storage バケットへのログエントリの保存は 1 時間ごとに一括して行われます。最初のエントリが表示されるまでに 2～3 時間かかることがあります。
ログの構成
Cloud Storage バケットにログをルーティングすると、Logging は一連のファイルをバケットに書き込みます。
ファイルは、ログタイプと日時別にディレクトリ構造で構成されます。LogEntry リファレンスで [LOG_ID] として参照されるログタイプは、syslog のようなシンプルな名前、または appengine.googleapis.com/request_log のような複合名に設定できます。これらのログが my-gcs-bucket という名前のバケットに保存された場合は、次の例のようにディレクトリに名前が付けられます。
my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/
1 つの Cloud Storage バケットに複数のリソースタイプのログを格納できます。 各ファイルは約 3.5 GiB です。
Logging は、同一または重複するクエリを含むシンクからのログエントリの重複除去を保証しません。これらのシンクから取得したログエントリが複数回 Cloud Storage バケットに書き込まれる場合があります。
最下位ディレクトリ（DD/）には複数のファイルが含まれ、それぞれのファイルには、ファイル名で指定された期間のルーティングされたログエントリが含まれます。ファイルはシャーディングされ、ファイル名の末尾にシャード番号 Sn または An（ n=0、1、2、...）が付きます。たとえば、次の 2 つのファイルがディレクトリ my-gcs-bucket/syslog/2015/01/13/ に格納されます。
08:00:00_08:59:59_S0.json 08:00:00_08:59:59_S1.json
08:00:00 UTC から 08:59:59 UTC の 1 時間における、すべてのインスタンスの syslog ログエントリが、これらの 2 つのファイルで合わせて含まれています。ログエントリのタイムスタンプは UTC（協定世界時）で表されます。
60 分のアライメント ウィンドウの timestamp 内で到達する receiveTimestamp を持つログエントリは、メインのシャード ファイルに書き込まれます。たとえば、08:00:00 の timestamp と、08:10:00 の receiveTimestamp を持つログエントリは、メインのシャード ファイルに保存されます。
これらのファイルには、接尾辞 _Sn.json の番号付きメインシャードが含まれます。
60 分のアライメント ウィンドウの receiveTimestamp 以外の時間に到達する timestamp を持つログエントリは、付録のシャード ファイルに書き込まれます。たとえば、08:00:00 の timestamp と、09:10:00 の receiveTimestamp を持つログエントリは、付録のシャード ファイルに保存されます。
これらのファイルには、接尾辞 _An:Unix_timestamp.json の番号付き付録シャードが含まれます。
たとえば、08:00:00 から 08:59:59 の間の timestamp を持つ一方で、60 分以外のアライメント ウィンドウの receiveTimestamp を持つログエントリが _An:Unix_timestamp.json 接尾辞付きのファイルに書き込まれます。ここで、ファイルが Cloud Storage にルーティングされた時刻が UNIX タイムスタンプで識別されます。ログエントリが 08:50:00 の timestamp と、09:10:00 の receiveTimestamp を持ち、2021 年 3 月 25 日の 09:15:00 にルーティングされた場合、付録ファイルには次のように書き込まれます。
08:00:00_08:59:59_A0:1616681700.json
すべてのログエントリを取得するには、それぞれの期間のシャードをすべて読み取る必要があります。この例の場合はファイル シャード 0 と 1 です。書き込まれるファイル シャードの数は、ログエントリの量に応じて期間ごとに異なります。
個々のシャード ファイル内には、ログエントリが LogEntry オブジェクトのリストとして保存されます。syslog エントリの例については、このドキュメントの LogEntry 型をご覧ください。
ファイル内のログエントリの並べ替え順は一定ではなく、保証されないことに注意してください。
フィルタ
Cloud Storage へのログのルーティングに適用するフィルタの例については、サンプルクエリをご覧ください。
BigQuery
BigQuery でルーティングしたログを表示する方法は次のとおりです。
Cloud Console の BigQuery ページに移動します。
シンクのエクスポート先として使用するデータセットを選択します。
データセットのいずれかのテーブルを選択します。[詳細] タブにログエントリが表示されます。また、テーブルに対するクエリを行ってデータを返すこともできます。
テーブルの構成の詳細については、テーブルの構成をご覧ください。エクスポートされたログエントリ フィールドの名前の付け方の詳細については、ログのエクスポートと BigQuery スキーマをご覧ください。
ルーティングの頻度
Logging がログエントリを BigQuery にルーティングしているときに新しいテーブルを作成した場合、新しいテーブルに最初のログエントリが表示されるまで数分かかることがあります。その後のログエントリは通常 1 分以内に表示されます。
テーブルの構成
BigQuery データセットにログをルーティングすると、Logging はルーティングされたログエントリを保持する日付別テーブルを作成します。ログエントリは、エントリのログ名とタイムスタンプに基づく名前のテーブルに格納されます 1。次の表は、ログ名とタイムスタンプをテーブル名にマップする例を示しています。
| ログ名 | ログエントリのタイムスタンプ 1 | BigQuery テーブル名 |
|---|---|---|
| syslog | 2017-05-23T18:19:22.135Z | syslog_20170523 |
| apache-access | 2017-01-01T00:00:00.000Z | apache_access_20170101 |
| compute.googleapis.com/activity_log | 2017-12-31T23:59:59.999Z | compute_googleapis_com_activity_log_20171231 |
1 ログエントリのタイムスタンプは UTC（協定世界時）で表されます。
スキーマとフィールド
ルーティングされたログに対する BigQuery テーブル スキーマは、LogEntry タイプの構造とログのペイロードの内容に基づいています。テーブル スキーマを確認するには、BigQuery ウェブ UI でルーティングされたログエントリのテーブルを選択します。
複雑なログエントリのペイロードを表すために使用される BigQuery テーブル スキーマはわかりにくい場合があります。ルーティングされた監査ログの場合は、いくつかの特別な命名規則が使用されます。詳しくは、エクスポートしたログの BigQuery スキーマをご覧ください。
クエリ
ログを BigQuery にルーティングするクエリの例については、サンプルクエリをご覧ください。
BigQuery クエリ シンタックスの詳細については、クエリ リファレンスをご覧ください。複数のテーブルへのクエリが可能なテーブル ワイルドカード関数と、繰り返されるフィールドからデータを表示する Flatten 演算子は、特に便利です。
Compute Engine ログエントリのサンプル
次の BigQuery クエリは、複数の日付と複数のログタイプからログエントリを取得します。
このクエリは過去 3 日間の
syslogとapache-accessのログを検索します。このクエリは 2015 年 2 月 23 日に作成されたので、2 月 21 日と 2 月 22 日に受け取ったすべてのログエントリと、2 月 23 日のクエリ発行時刻までに受け取ったログエントリを対象とします。このクエリは、1 つの Compute Engine インスタンス
1554300700000000000の結果を取得します。
SELECT
timestamp AS Time,
logName as Log,
textPayload AS Message
FROM
(TABLE_DATE_RANGE(my_bq_dataset.syslog_,
DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP())),
(TABLE_DATE_RANGE(my_bq_dataset.apache_access_,
DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP()))
WHERE
resource.type == 'gce_instance'
AND resource.labels.instance_id == '1554300700000000000'
ORDER BY time;
出力行の例は次のようになります。
Row | Time | Log | Message --- | ----------------------- | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- 5 | 2015-02-21 03:40:14 UTC | projects/project-id/logs/syslog | Feb 21 03:40:14 my-gce-instance collectd[24281]: uc_update: Value too old: name = 15543007601548826368/df-tmpfs/df_complex-used; value time = 1424490014.269; last cache update = 1424490014.269; 6 | 2015-02-21 04:17:01 UTC | projects/project-id/logs/syslog | Feb 21 04:17:01 my-gce-instance /USR/SBIN/CRON[8082]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) 7 | 2015-02-21 04:49:58 UTC | projects/project-id/logs/apache-access | 128.61.240.66 - - [21/Feb/2015:04:49:58 +0000] "GET / HTTP/1.0" 200 536 "-" "masscan/1.0 (https://github.com/robertdavidgraham/masscan)" 8 | 2015-02-21 05:17:01 UTC | projects/project-id/logs/syslog | Feb 21 05:17:01 my-gce-instance /USR/SBIN/CRON[9104]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) 9 | 2015-02-21 05:30:50 UTC | projects/project-id/log/syslogapache-access | 92.254.50.61 - - [21/Feb/2015:05:30:50 +0000] "GET /tmUnblock.cgi HTTP/1.1" 400 541 "-" "-"
App Engine ログエントリのサンプル
次の BigQuery クエリは、過去 1 か月の失敗した App Engine リクエストを取得します。
SELECT
timestamp AS Time,
protoPayload.host AS Host,
protoPayload.status AS Status,
protoPayload.resource AS Path
FROM
(TABLE_DATE_RANGE(my_bq_dataset.appengine_googleapis_com_request_log_,
DATE_ADD(CURRENT_TIMESTAMP(), -1, 'MONTH'), CURRENT_TIMESTAMP()))
WHERE
protoPayload.status != 200
ORDER BY time
結果の例は次のようになります。
Row | Time | Host | Status | Path --- | ----------------------- | ------------------------------------- | ------ | ------ 6 | 2015-02-12 19:35:02 UTC | default.my-gcp-project-id.appspot.com | 404 | /foo?thud=3 7 | 2015-02-12 19:35:21 UTC | default.my-gcp-project-id.appspot.com | 404 | /foo 8 | 2015-02-16 20:17:19 UTC | my-gcp-project-id.appspot.com | 404 | /favicon.ico 9 | 2015-02-16 20:17:34 UTC | my-gcp-project-id.appspot.com | 404 | /foo?thud=%22what???%22
Pub/Sub
Pub/Sub を使用して Cloud Logging ログをサードパーティ ソフトウェアに統合することをおすすめします。
通常、Pub/Sub にルーティングされたログは数秒以内に使用可能になり、99% のログが 60 秒未満で使用可能になります。
Pub/Sub でストリーミングされるときにルーティングされたログを表示する方法は次のとおりです。
Cloud Console の [Pub/Sub] ページに移動します。
ログシンクで使用されているトピックのサブスクリプションを検索または作成して、そこからログエントリを pull します。新しいログエントリの公開には時間がかかる場合があります。
Pub/Sub でログを整理する方法の詳細については、このドキュメントのログの構成をご覧ください。
ルーティングの頻度
Pub/Sub トピックにログのルーティングを行うと、Logging は各ログエントリを受け取るとすぐに、そのログエントリを Pub/Sub メッセージとして公開します。
ログの構成
各メッセージの data フィールドは、Base64 エンコードの LogEntry オブジェクトです。たとえば、Pub/Sub サブスクライバーが、ログエントリを受け取るトピックから次のようなオブジェクトを pull したとします。ここで示すオブジェクトに含まれているリストにはメッセージが 1 つしかありませんが、複数のログエントリがある場合は、Pub/Sub が複数のメッセージを返すことがあります。この例では、見やすくするために data 値（約 600 字）と ackId 値（約 200 字）を短縮しています。
{
"receivedMessages": [
{
"ackId": "dR1JHlAbEGEIBERNK0EPKVgUWQYyODM...QlVWBwY9HFELH3cOAjYYFlcGICIjIg",
"message": {
"data": "eyJtZXRhZGF0YSI6eyJzZXZ0eSI6Il...Dk0OTU2G9nIjoiaGVsbG93b3JsZC5sb2cifQ==",
"attributes": {
"compute.googleapis.com/resource_type": "instance",
"compute.googleapis.com/resource_id": "123456"
},
"messageId": "43913662360"
}
}
]
}
data フィールドをデコードしてフォーマットすると、次のような LogEntry オブジェクトを取得できます。
{
"log": "helloworld.log",
"insertId": "2015-04-15|11:41:00.577447-07|10.52.166.198|-1694494956",
"textPayload": "Wed Apr 15 20:40:51 CEST 2015 Hello, world!",
"timestamp": "2015-04-15T18:40:56Z",
"labels": {
"compute.googleapis.com\/resource_type": "instance",
"compute.googleapis.com\/resource_id": "123456"
},
"severity": "WARNING"
}
}
サードパーティと Pub/Sub の統合
Logging では、Splunk などのサードパーティとロギングを統合できます。統合の最新リストについては、Google Cloud オペレーション スイートの統合のパートナーをご覧ください。
Pub/Sub トピックからログをルーティングすると、サードパーティは同じトピックにサブスクライブすることでログを受信できます。
統合を行うには、次の方法と同様のことをする必要があります。
Google Cloud プロジェクトから作成した Google Cloud サービス アカウント名をサードパーティから取得します。例:
12345-xyz@developer.gserviceaccount.comこの名前を使用して、ログを受け取る権限をサードパーティに付与します。ログを含むプロジェクトで、Pub/Sub API を有効にします。
-
Pub/Sub API を有効にします。
Pub/Sub トピックを作成します。トピックは、ログシンクを構成するか、次の手順で作成できます。
- Pub/Sub トピックリストを開きます。
[トピックの作成] を選択し、トピック名を入力します。例:
projects/my-project-id/topics/my-pubsub-topicこのトピックにログをルーティングします。トピックに送信される各メッセージは、Pub/Sub メッセージ
attributesでルーティングされたログエントリのタイムスタンプを含みます。例:"attributes": { "logging.googleapis.com/timestamp": "2018-10-01T00:00:00Z" }[作成] をクリックします。
Logging からそのトピックにログをルーティングすることを承認します。この手順については、Pub/Sub の権限の設定をご覧ください。
サードパーティがトピックをサブスクライブすることを承認します。
- Cloud Console で、プロジェクトの Pub/Sub トピックリストにとどまります。
- 新しいトピックを選択します。
- [権限] を選択します。
- サードパーティのサービス アカウント名を入力します。
- [役割を選択] メニューの [Pub/Sub サブスクライバー] を選択します。
- [追加] をクリックします。
サードパーティに Pub/Sub トピック名を知らせます。たとえば、
projects/my-project-number/topics/my-pubsub-topic。ルーティングを開始する前に、サードパーティでそのトピックをサブスクライブする必要があります。サードパーティがトピックをサブスクライブしたら、ログのルーティングを開始します。
- ルーティングするログを含むプロジェクトで、検索クエリボックスの上にある [エクスポートを作成] をクリックします。[エクスポートの編集] パネルが開きます。
- [シンク名] を入力します。
- [シンクサービス] メニューで、[Cloud Pub/Sub] を選択します。
- [シンクのエクスポート先] メニューで、サードパーティがサブスクライブしている Pub/Sub トピックを選択します。
- [シンクを作成] を選択します。
- シンクが作成されましたというメッセージを含むダイアログが表示されます。このメッセージは、シンクが、選択された宛先に今後一致するログを書き込む権限付きで正常に作成されたことを意味します。
直ちにサードパーティでのログエントリの受信が開始されます。
Pub/Sub を使用した一般的なログ ルーティング シナリオの詳細については、Cloud Logging にルーティングするための設計パターン: ロギング エクスポートのシナリオをご覧ください。
Cloud Logging
ログバケットは、ログデータを保持する Google Cloud プロジェクトの Cloud Logging ストレージ コンテナです。ログシンクを作成して、ログのすべてまたは一部を Cloud Logging の任意のバケットにルーティングできます。この柔軟性により、ログを保存する Cloud プロジェクトと、ログとともに保存する他のログを選択できます。
Cloud プロジェクトに関連付けられたログバケットを作成して一覧表示する手順については、バケットの管理をご覧ください。
ログエントリの構成
Logging のログエントリは、LogEntry 型のオブジェクトです。
LogEntry リファレンスで [LOG_ID] と呼ばれる同じログタイプのログエントリは、通常同じ形式です。次の表にログエントリの例を示します。
syslog
Compute Engine syslog は、仮想マシン インスタンスで実行されるロギング エージェント google-fluentd によって生成されるカスタム ログタイプです。
{
logName: "projects/my-gcp-project-id/logs/syslog",
timestamp: "2015-01-13T19:17:01Z",
resource: {
type: "gce_instance",
labels: {
instance_id: "12345",
zone: "us-central1-a",
project_id: "my-gcp-project-id"
}
},
insertId: "abcde12345",
textPayload: "Jan 13 19:17:01 my-gce-instance /USR/SBIN/CRON[29980]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)"
}
request_log
App Engine request_log のログエントリには、RequestLog 型のオブジェクトを持つ protoPayload フィールドがあります。
{
logName: "projects/my-gcp-project-id/logs/appengine.googleapis.com%2Frequest_log",
timestamp: "2015-01-13T19:00:39.796169Z",
resource: {
type: "gae_app",
labels: {
module_id: "default",
zone: "us6",
project_id: "my-gcp-project-id",
version_id: "20150925t173233"
}
}
httpRequest: {
status: 200
}
insertId: "abcde12345",
operation: {
id: "abc123",
producer: "appengine.googleapis.com/request_id",
first: true,
last: true
}
protoPayload: {
@type: "type.googleapis.com/google.appengine.logging.v1.RequestLog"
versionId: "20150925t173233",
status: 200,
startTime: "2017-01-13T19:00:39.796169Z",
# ...
appId: "s~my-gcp-project-id",
appEngineRelease: "1.9.17",
}
}
直接的に示す
activity ログは管理アクティビティの監査ログです。そのペイロードは、AuditLog 型の JSON 表現です。
{
logName: "projects/my-gcp-project-id/logs/cloudaudit.googleapis.com%2Factivity"
timestamp: "2017-04-22T13:41:32.245Z"
severity: "NOTICE"
resource: {
type: "gce_instance"
labels: {
instance_id: "2403273232180765234"
zone: "us-central1-b"
project_id: "my-gcp-project-id"
}
}
insertId: "54DC1882F4B49.A4996C2.6A02F4C1"
operation: {
id: "operation-1492868454262-54dc185e9a4f0-249fe233-f73d472a"
producer: "compute.googleapis.com"
last: true
}
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
principalEmail: "649517127304@cloudservices.gserviceaccount.com"
}
requestMetadata: {…}
serviceName: "compute.googleapis.com"
methodName: "v1.compute.instances.delete"
resourceName: "projects/my-gcp-project-id/zones/us-central1-b/instances/abc123"
}
}
Splunk
Logging は、Pub/Sub トピックを介してログをルーティングすることで Splunk との統合をサポートします。Pub/Sub トピックを作成し、Splunk がそのトピックをサブスクライブすることを承認する方法については、Pub/Sub とのサードパーティ統合をご覧ください。
遅れて到着するログエントリ
ルーティングしたログエントリは、1 時間ごとに一括して Cloud Storage バケットに保存されます。最初のエントリが表示されるまでに 2～3 時間を要する場合があります。ルーティングされたログのファイル シャードに An（「Append」）という接尾辞が付いている場合は、遅れて到着したログエントリが含まれています。
宛先に停電が発生した場合、Cloud Logging は停電が終わるまでデータを保護します。
シンクの宛先にログがない場合は、エクスポート システムの指標を確認します。エクスポート システムの指標には、転送されたログエントリの数と、エラーによってドロップされたログエントリの数が示されます。エクスポート システムの指標にログエントリが宛先に転送されていないことが示されている場合は、フィルタを調べて、フィルタに一致するログエントリが最近 Logging に届いていることを確認します。
App Engine のログエントリ
また、App Engine は、タイプ google.appengine.logging.v1.LogLine（AppLog または AppLogLine とも呼ばれる）の複数のサブエントリを、ログ アクティビティを発生させたリクエストを表すタイプ google.appengine.logging.v1.RequestLog のプライマリ ログエントリの下で結合します。各ログ行には、プライマリ エントリを識別するリクエスト ID が含まれます。ログ エクスプローラには、リクエスト ログエントリが含まれるログ行が表示されます。Logging は、タイムスタンプでは次のバッチに入る場合にも、すべてのログ行を元のリクエストとともにバッチに入れることを試みます。それができない場合、リクエスト ログエントリでいくつかのログ行が失われて、次のバッチにリクエストのない「孤立した」ログ行が存在することがあります。このような可能性を重くみる場合は、ログを処理するときにリクエストの各部分をつなぎ直せるように準備してください。
トラブルシューティング
シンクの宛先にログがないように見える場合は、logging.googleapis.com/exports/ 指標を表示して、シンクによって送信されたログエントリ数を確認できます。
exports/byte_count: ルーティングされたログエントリのバイト数。exports/log_entry_count: ルーティングされたログエントリの数。exports/error_count: エクスポートできなかったログエントリの数。
指標には、シンク名と宛先名でカウントを記録するラベルがあるため、シンクがログデータを正常にルーティングしているかどうかがわかります。指標の表示方法の詳細については、ログベースの指標の表示をご覧ください。
シンクがログを適切に転送していないと思われる場合は、ルーティングとシンクのトラブルシューティングをご覧ください。
料金
Cloud Logging ではログの転送は課金されませんが、転送先での請求が適用されることがあります。詳細については、該当するサービスの料金詳細をご覧ください。
Cloud Logging から Virtual Private Cloud フローログを送信して除外した場合は、エクスポート先料金に加え VPC フローログの生成料金が適用されることにもご注意ください。