このドキュメントでは、ルーティングとストレージに関する一般的な問題と、Google Cloud コンソールを使用して構成の誤りや予期しない結果を表示する方法、トラブルシューティングする方法について説明します。
シンクの宛先でログを使用する場合の一般的な情報については、シンクの宛先でログを表示するをご覧ください。
ログのルーティングのトラブルシューティング
このセクションでは、ログのルーティング時に発生する一般的な問題のトラブルシューティング方法について説明します。
宛先に不要なログが含まれている
宛先にルーティングされたログを表示したところ、宛先に不要なログが含まれていることが確認された。
この状態を解決するには、ログを宛先に転送するシンクの除外フィルタを更新します。除外フィルタを使用すると、選択したログが宛先へ転送されなくなります。
たとえば、組織内のログを宛先に転送する集約シンクを作成するとします。特定のプロジェクトのログを宛先にルーティングしない場合は、次の除外フィルタをシンクに追加します。
logName:projects/PROJECT_ID
論理 OR 演算子を使用して logName 句を結合すれば、複数のプロジェクトからログを除外することもできます。
エクスポート先にログがない
シンク関連の最もよくある問題は、シンクの宛先でログが欠落しているように見えることです。
エラーが生成されていないものの、宛先でログにアクセスしようとすると使用できないことがあります。シンクがログを正しくルーティングしていない可能性がある場合は、シンクのシステム ログベースの指標を確認します。
exports/byte_count: ルーティングされたログエントリのバイト数。exports/log_entry_count: ルーティングされたログエントリの数。exports/error_count: エクスポートできなかったログエントリの数。
指標には、シンク名と宛先名でカウントを記録するラベルがあるため、シンクがログデータを正常にルーティングしているかどうかがわかります。 指標の表示方法の詳細については、ログベースの指標を表示するをご覧ください。
シンクの指標が、シンクが想定どおりに機能していないことを示している場合、考えられる理由と対処方法は次のとおりです。
レイテンシ
シンクを作成または更新してから一致するログエントリが受信されていません。新しいログエントリのみがルーティングされます。
1 時間ほど待ってから、もう一度宛先を確認してください。
一致するログエントリの到着が遅れています。
エクスポート先でログが表示されるまでに時間がかかることがあります。 遅れて到着するログは、Cloud Storage バケットをエクスポート先として構成したシンクで特によく見られます。 数時間後にもう一度エクスポート先を確認してください。
スコープやフィルタが正しく表示されない
Logging バケットの宛先のログの表示に使用しているスコープが間違っている。
次のように、検索の範囲を 1 つ以上のストレージ ビューに絞り込みます。
ログ エクスプローラを使用している場合、[範囲を絞り込む] ボタンを使用します。
gcloud CLI を使用している場合は、
gcloud logging readコマンドを使用して--view=AllLogsフラグを追加します。
シンクのエクスポート先でデータを選択して表示するために使用する期間が短すぎる。
シンクのエクスポート先のデータを選択する際に使用する期間を広げてみてください。
シンクフィルタのエラー
シンクのフィルタが間違っていて、エクスポート先に表示されるはずのログをキャプチャしていません。
- Google Cloud コンソールで、[ログルーター] を使用してシンクのフィルタを編集します。正しいフィルタが入力されていることを確認するには、[シンクを編集] パネルで [ログをプレビュー] を選択します。フィルタが事前に入力された状態で、ログ エクスプローラが新しいタブで開きます。シンクの表示と管理の手順については、シンクを管理するをご覧ください。
その他のエラーを確認
サポートされているシンクの宛先ごとに、Logging は不適切な構成のシンクのエラー メッセージを返します。
シンク関連のエラーを表示するには、いくつかの方法があります。これらの方法については、次のセクションで説明します。
- シンク用に生成されたエラーログを表示する。
- シンクエラー通知をメールで受信する。
エラーログ
シンク関連のエラーを詳細に検査する場合、シンクによって生成されたエラー ログエントリを表示することをおすすめします。ログの表示の詳細については、ログ エクスプローラを使用してログを表示するをご覧ください。
ログ エクスプローラのクエリエディタ ペインで次のクエリを使用して、シンクのエラーログを確認できます。Logging API と gcloud CLI でも同じクエリが機能します。
クエリをコピーする前に、変数 SINK_NAME をトラブルシューティングするシンクの名前に置き換えます。シンクの名前は、Google Cloud コンソールの [ログルーター] ページで確認できます。
logName:"logging.googleapis.com%2Fsink_error"
resource.type="logging_sink"
resource.labels.name="SINK_NAME"
たとえば、シンクの名前が my-sink-123 の場合、ログエントリは次のようになります。
{
errorGroups: [
0: {
id: "COXu96aNws6BiQE"
}]
insertId: "170up6jan"
labels: {
activity_type_name: "LoggingSinkConfigErrorV2"
destination: "pubsub.googleapis.com/projects/my-project/topics/my-topic"
error_code: "topic_not_found"
error_detail: ""
sink_id: "my-sink-123"
}
logName: "projects/my-project/logs/logging.googleapis.com%2Fsink_error"
receiveTimestamp: "2024-07-11T14:41:42.578823830Z"
resource: {
labels: {
destination: "pubsub.googleapis.com/projects/my-project/topics/my-topic"
name: "my-sink-123"
project_id: "my-project"
}
type: "logging_sink"
}
severity: "ERROR"
textPayload: "Cloud Logging sink configuration error in my-project, sink my-sink-123: topic_not_found ()"
timestamp: "2024-07-11T14:41:41.296157014Z"
}
LogEntry フィールド labels とそのネストされた Key-Value 情報は、シンクのエラーソースの特定に役立ちます。これには、影響を受けるリソース、影響を受けるシンク、エラーコードが含まれます。labels.error_code フィールドにはエラーの簡単な説明が含まれているので、シンクのどのコンポーネントを再構成する必要があるかがわかります。
この問題を解決するには、シンクを編集します。たとえば、[ログルーター] ページを使用してシンクを編集できます。
メール通知
Technical Essentials Contact として Google Cloud プロジェクトまたはその親リソースに登録している場合は、シンク構成のエラーメール通知が送信されます。リソースに対して Technical Essential Contacts が構成されていない場合、そのリソースの IAM プロジェクト オーナー roles/owner として一覧表示されているユーザーがメール通知を受け取ります。
このメール メッセージには次の情報が含まれます。
- リソース ID: シンクが構成されている Google Cloud プロジェクトまたは他の Google Cloud リソースの名前。
- シンク名: 構成エラーを含むシンクの名前。
- シンクの宛先: シンクのルーティング先のフルパス。例:
pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID - エラーコード: エラーカテゴリの簡単な説明。例:
topic_not_found - エラーの詳細: 根底のエラーのトラブルシューティングに関する推奨事項など、エラーに関する詳細情報。
シンクを表示して管理するには、[ログルーター] ページを使用します。
リソースに適用されるシンク構成エラーが、Cloud Logging sink configuration error としてリストに表示されます。各エラーには、障害のあるシンクによって生成されたいずれかのログエントリへのリンクが含まれます。根本的なエラーを詳しく調べるには、エラーログをご覧ください。
シンクエラーの種類
以下のセクションでは、シンク関連のエラーのさまざまなカテゴリとそのトラブルシューティング方法について説明します。
正しくない宛先
シンクを設定した後、Logging がログをルーティングしようとしたときに宛先が見つからないという構成エラーが表示される場合は、次の理由が考えられます。
シンクの構成に、指定したシンクの宛先でのスペルミスやその他のフォーマット エラーが含まれています。
既存の宛先を適切に指定するには、シンクの構成を更新する必要があります。
指定した宛先が削除された可能性があります。
別の既存の宛先を使用するか、同じ名前で宛先を再作成するようにシンクの構成を変更できます。
このような種類の問題を解決するには、シンクを編集します。たとえば、[ログルーター] ページを使用してシンクを編集できます。
シンクは、宛先が検出されるとログのルーティングを開始し、フィルタに一致する新しいログが Logging で受信されます。
シンクの問題の管理
シンクを無効にして、ログバケットへのログの保存を停止してもログが転送されている場合は、シンクへの変更が適用されるまで数分待ちます。
権限に関する問題
シンクがログエントリをルーティングしようとしたが、シンクの宛先に適切な IAM 権限がない場合、シンクはログエントリを表示してスキップできるエラーを報告します。
シンクを作成するときは、シンクのサービス アカウントに適切なエクスポート先の権限が付与されている必要があります。Google Cloud コンソールで同じ Google Cloud プロジェクトにシンクを作成すると、通常、Google Cloud コンソールによってこれらの権限が自動的に割り当てられます。別の Google Cloud プロジェクトでシンクを作成するか、gcloud CLI や Logging API を使用してシンクを作成する場合は、権限を手動で構成する必要があります。
シンクの権限関連のエラーが発生した場合は、必要な権限を追加するか、別の宛先を使用するようにシンクを更新します。これらの権限を更新する方法については、宛先の権限をご覧ください。
シンクを作成してから、シンクの新しいサービス アカウントを使用してエクスポート先への書き込みを許可するまで、わずかな遅延が発生します。権限が修正され、フィルタに一致する新しいログが Logging によって受信されると、シンクはログのルーティングを開始します。
組織のポリシーに関する問題
ログエントリをルーティングしようとしたときに、Logging がシンクの宛先への書き込みを制限する組織のポリシーが存在する場合、シンクは選択した宛先にルーティングできず、エラーを報告します。
組織のポリシーに関連するエラーが表示された場合は、次の手順を実行します。
宛先の組織のポリシーを更新して、シンクによるログエントリの転送をブロックする制約を削除します。これには、組織のポリシーを更新するために適切な権限があることを前提とします。手順については、ポリシーの作成と編集をご覧ください。
組織のポリシーを更新できない場合は、[ログルーター] ページでシンクを更新して、ポリシーに準拠した宛先を使用します。
組織ポリシーがシンクによる宛先への書き込みをブロックしなくなると、シンクはログのルーティングを開始し、Logging がフィルタに一致する新しいログを受信します。
暗号鍵に関する問題
Cloud Key Management Service で管理されている、またはユーザーによって管理されている鍵を使用してシンクの宛先でデータを暗号化している場合は、関連するエラーが表示される可能性があります。以下で、考えられる問題と解決方法について説明します。
Cloud KMS 鍵を含む Google Cloud プロジェクトに対して課金が有効になっていない。
正しい宛先でシンクが正常に作成された場合でも、このエラー メッセージは、鍵を含む Google Cloud プロジェクトに関連付けられた有効な請求先アカウントがない場合に表示されます。
鍵を含む Google Cloud プロジェクトにリンクされた有効な請求先アカウントがあることを確認してください。請求先アカウントが Google Cloud プロジェクトにリンクされていない場合は、その Google Cloud プロジェクトの課金を有効にするか、有効な請求先アカウントがリンクされている Google Cloud プロジェクトに含まれる Cloud KMS 鍵を使用します。
Cloud KMS 鍵が見つからない。
データを暗号化するように構成された Cloud KMS 鍵を含む Google Cloud プロジェクトが見つかりません。
既存の Google Cloud プロジェクトに含まれている有効な Cloud KMS 鍵を使用してください。
Cloud KMS 鍵のロケーションが、宛先のロケーションと一致しない。
Cloud KMS 鍵を含む Google Cloud プロジェクトが宛先のリージョンとは異なるリージョンにある場合、暗号化は失敗し、シンクの宛先にデータはルーティングされません。
リージョンがシンクの宛先と一致する Google Cloud プロジェクトに含まれる Cloud KMS 鍵を使用します。
暗号鍵によるシンクのサービス アカウントへのアクセスが拒否された。
シンクが正常に正しいサービス アカウント権限を指定して作成された場合でも、シンクの宛先がサービス アカウントにデータの暗号化または復号を行うための十分な権限を付与しない暗号鍵を使用している場合に、このエラー メッセージが表示されます。
宛先で使用される鍵について、シンクの
writerIdentityフィールドで指定されたサービス アカウントに Cloud KMS 暗号鍵の暗号化 / 復号のロールを付与します。また、Cloud KMS API が有効になっていることを確認してください。
割り当ての問題
シンクがログを書き込むと、宛先に固有の割り当てが、シンクが作成された Google Cloud プロジェクトに適用されます。割り当ての上限に達すると、シンクは宛先へのログのルーティングを停止します。
たとえば、BigQuery にデータをルーティングする際に、データセット内の特定のテーブルに対してテーブルごとのストリーミング挿入の割り当てを超過したことを示すエラーが表示されることがあります。この場合、シンクが多すぎるログエントリを短時間でルーティングしている可能性があります。この考えは、Pub/Sub トピックなどのサポートされている他のシンクの宛先にも適用されます。
割り当ての上限に達した問題を解決するには、シンクのフィルタを更新してログエントリの数を減らすことで、ルーティングされるログデータの量を減らします。その場合、フィルタの sample 関数を使用して、ログエントリの総数の割合を選択します。
ログエントリを減らしてシンクを更新するか、割り当てが更新されると、シンクは宛先へのログのルーティングを開始します。
ログをルーティングする際に適用される上限の詳細については、適切な宛先の割り当て情報をご覧ください。
一般的なシンクエラーのタイプに加えて、宛先に固有の最も一般的なエラータイプとその修正方法は次のとおりです。
Cloud Storage へのルーティングのエラー
ログを Cloud Storage にルーティングする際に最もよくあるエラーは次のとおりです。
遅れて到着するログエントリ:
ルーティングしたログエントリは、1 時間ごとに一括して Cloud Storage バケットに保存されます。最初のエントリが表示されるまでに 2～3 時間かかることがあります。
ルーティングされたログのファイル シャードに
An（「Append」）という接尾辞が付いている場合は、遅れて到着したログエントリが含まれています。Cloud Storage の宛先に停電が発生した場合、Cloud Logging は停電が終わるまでデータを保護します。
宛先に適切な権限を付与できません。
正しいサービス アカウント権限でシンクが正常に作成されている場合でも、バケットの作成時に Cloud Storage バケットのアクセス制御モデルが均一なアクセスに設定された場合は、このエラー メッセージが表示されます。
既存の Cloud Storage バケットの場合、バケットの作成後 90 日以内に [権限] タブを使用してアクセス制御モデルを変更できます。新しいバケットの場合は、バケットの作成中に [きめ細かい管理] アクセス制御モデルを選択します。詳細については、Cloud Storage バケットの作成をご覧ください。
BigQuery へのルーティング エラー
ログを BigQuery にルーティングする際に最もよくあるエラーは次のとおりです。
無効なテーブル スキーマ:
BigQuery データセット内のテーブルにストリーミングされたログが、現在のテーブルのスキーマと一致しません。一般的な問題としては、異なるデータ型のログエントリを転送して、スキーマの不一致が発生することがあります。たとえば、ログエントリのフィールドの 1 つが整数値で、スキーマで対応する列が文字列型になっている場合があります。
ログエントリがテーブル スキーマと一致することを確認します。エラーの原因を修正したら、現在のテーブルの名前を変更して、Logging で再度テーブルを作成します。
注: BigQuery は、テーブルへのネストされたデータの読み込みをサポートしています。ただし、Logging からデータを読み込む場合、列のネストの深さは最大 13 レベルに制限されます。
BigQuery はスキーマの不一致を識別すると、対応するデータセット内にテーブルを作成し、エラー情報を保存します。 テーブルの種類によってテーブル名が決まります。日付別テーブルの場合、命名形式は
export_errors_YYYYMMDDです。パーティション分割テーブルの場合、命名形式はexport_errorsです。エラーテーブルのスキーマと、今後のフィールド タイプの不一致を防ぐ方法については、スキーマの不一致をご覧ください。ログエントリが、許可されている期間に含まれていない。
分割された BigQuery テーブルにストリーミングされたログが、許可されている期間に含まれていません。BigQuery では、許容された期間とかけ離れているログを受け入れません。
それらのログを Cloud Storage にルーティングし、BigQuery 読み込みジョブを使用するようにシンクを更新できます。詳細については、BigQuery のドキュメントをご覧ください。
データセットは、ログシンクに関連するサービス アカウントによる書き込みを許可していません。
正しいサービス アカウント権限でシンクが正常に作成されている場合でも、シンクの宛先を含む Google Cloud プロジェクトに関連付けられた有効な請求先アカウントがないと、このエラー メッセージが表示されます。
Google Cloud プロジェクトにリンクされている請求先アカウントがあることを確認します。請求先アカウントがシンクの宛先 Google Cloud プロジェクトにリンクされていない場合は、その Google Cloud プロジェクトの課金を有効にするか、シンクの宛先を更新して、有効な請求先アカウントがリンクされた Google Cloud プロジェクトに宛先があるようにします。
データセットに重複するログエントリが含まれています。
再試行や構成ミスなどにより、BigQuery へのログのストリーミングに失敗すると、ログエントリが重複することがあります。Cloud Logging は、クエリ時に、同じ
timestampとinsertIdを持つログエントリの重複排除を行います。BigQuery では、重複するログエントリが除外されません。BigQuery で重複するログエントリを無視するには、クエリに
SELECT DISTINCT句を含めます。次に例を示します。
SELECT DISTINCT insertId, timestamp FROM TABLE_NAME
Cloud Logging バケットへのルーティング エラー
シンクで除外したログがログエクスプローラで表示されることがあります。次のいずれかの条件が満たされている場合、これらのログが引き続き表示されます。
ログが生成された Google Cloud プロジェクトでクエリを実行している。
これを修正するには、正しい Google Cloud プロジェクトでクエリを実行していることを確認します。
除外されたログが複数のログバケットに送信された。除外するつもりだった同じログのコピーが表示される。
この問題を修正するには、[ログルーター] ページでシンクを調べて、他のシンクのフィルタにログが含まれていないことを確認します。
ログが送信されたログバケット内のビューへのアクセス権がある。この場合、デフォルトでそれらのログが表示されます。
ログ エクスプローラにこれらのログが表示されないようにするには、ソースの Google Cloud プロジェクトまたはバケットに検索範囲を絞り込みます。
ログの保存に関するトラブルシューティング
このバケットを削除できないのはなぜですか？
バケットを削除する場合は、次の操作を行います。
バケットを削除するための適切な権限があることを確認します。必要な権限のリストについては、IAM によるアクセス制御をご覧ください。
バケットの属性を一覧表示して、バケットがロックされているかどうかを確認します。バケットがロックされている場合は、バケットの保持期間を確認します。ロックされたバケットを削除するには、そのバケット内のすべてのログがバケットの保持期間を満たす必要があります。
ログバケットにリンクされた BigQuery データセットがないことを確認します。リンクされたデータセットがあるログバケットは削除できません。
リンクされたデータセットがあるログバケットに対して
deleteコマンドを実行すると、次のエラーが表示されます。FAILED_PRECONDITION: This bucket is used for advanced analytics and has an active link. The link must be deleted first before deleting the bucket
ログバケットに関連付けられたリンクを一覧表示するには、[
gcloud logging links list][link-list] コマンドを実行するか、projects.locations.buckets.links.listAPI メソッドを実行します。
どのサービス アカウントがバケットにログを転送するのですか？
ログをバケットに転送する IAM 権限がサービス アカウントにあるかどうかを確認するには、次の操作を行います。
-
Google Cloud コンソールの [IAM] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。
[権限] タブで、[ロール] ごとに表示します。Google Cloud プロジェクトに関連付けられたすべての IAM のロールとプリンシパルを含む表が表示されます。
テーブルの [フィルタ] テキスト ボックス filter_list に「ログバケット書き込み」と入力します。
ログバケット書き込みのロールを持つプリンシパルが表示されます。プリンシパルがサービス アカウントの場合、その ID には文字列
gserviceaccount.comが含まれます。省略可: Google Cloud プロジェクトにログをルーティングできないようにサービスアカウントを削除する場合は、サービスアカウントのチェックボックス check_box_outline_blankをオンにして、[削除] をクリックします。
ログが _Default シンクから除外されていても Google Cloud プロジェクトのログが表示されるのはなぜですか？
組織全体からのログを集約する一元型の Google Cloud プロジェクトのログバケットでログを表示している可能性があります。
ログ エクスプローラを使用してこれらのログにアクセスしていて、_Default シンクから除外したログが表示される場合は、ビューが Google Cloud プロジェクト レベルに設定されている可能性があります。
この問題を解決するには、[範囲を絞り込む] パネルで [ストレージによるスコープ] を選択してから、Google Cloud プロジェクトの _Default バケットを選択します。これで、除外されたログが表示されなくなります。