OTLP ログの取り込みの概要

このドキュメントでは、OTLP 形式のログを Cloud Logging に取り込むために Telemetry（OTLP）API telemetry.googleapis.com を使用する方法について説明します。取り込まれたログはログエントリとして保存されます。例については、 Telemetry API に OTLP 形式のログを書き込むをご覧ください。

SDK を使用するアプリケーションから、または OpenTelemetry Collector を使用して、Telemetry API にログを送信することもできます。

ログ、指標、トレースの Telemetry API については、 Telemetry（OTLP）API リファレンスをご覧ください。

プロトコルサポート

OTLP エンドポイントは、http/protobuf、http/json、grpc など、すべての OTLP プロトコルをサポートしています。OpenTelemetry Collector からエクスポートする場合は、任意のプロトコルを使用できます。ただし、ほとんどの SDK エクスポータでは動的トークンの更新がサポートされていないため、SDK から直接エクスポートする場合は、HTTP エクスポータではなく gRPC OTLP エクスポータのみを使用することをおすすめします。

課金

Telemetry API を使用してログを取り込むと、Cloud Logging のストレージと課金の値が変更されることがあります。JSON の OTLP 形式のログリクエストの一般的な構造は次のとおりです。

"resourceLogs": [
    {
      "resource": {
        "attributes": [...]
      },
      "scopeLogs": [
        {
          "scope": { ...}
          "logRecords": [...]
        }
      ]
    }
]

各 logRecords 配列の各項目は、単一の Cloud Logging ログエントリになります。プロジェクトのストレージと課金が最も大きく変化するのは、次の両方が当てはまる場合です。 Google Cloud

resource フィールドに、キーと値に必要な属性が多数含まれている。これらのリソース属性は、結果の LogEntry でモニタリング対象リソースを特定するために使用されます。

モニタリング対象リソースは、Cloud Logging モニタリング対象リソースタイプと、関連するラベルの値で構成されます。モニタリング対象リソースタイプにはラベルがほとんどないものもありますが、リソースタイプには多くのラベルがあります。 OTLP 形式のログの取り込みに必要な属性の詳細については、OTLP 属性とリソースタイプのマッピングをご覧ください。
scopeLogs フィールドの logRecords 配列に多数の項目が含まれている。

OTLP 形式のログの取り込みをサポートするため、Cloud Logging LogEntry 構造には追加のフィールド otelが含まれています。OTLP と Cloud Logging のデータモデルは完全に一致しないため、otel フィールドには、受信した OTLP リクエストの OTLP リソース、スコープ、エンティティのコピーが含まれています。

たとえば、次のような OTLP resourceLog を Telemetry API に送信すると、結果のログエントリには、resource フィールド（モニタリング対象リソース用）と otel フィールドが含まれます。

`resourceLog`

{
  "resourceLogs": [
    {
      "resource": {
        "attributes": [
          {
            "key": "gcp.project_id",
            "value": { "stringValue": "PROJECT_ID" }
          },
          {
            "key": "gcp.resource_type",
            "value": { "stringValue": "global" }
          }
        ]
      },
      "scopeLogs": [
        {
          "scope": {
            "name": "my.library",
            "version": "1.0.0",
            "attributes": [
              {
                "key": "my.scope.attribute",
                "value": { "stringValue": "some scope attribute" }
              }
            ]
          },
          "logRecords": [ ... ]
         }
       ]
     }
   ]
}

`resource`

  {
    ...
    "resource": {
      "labels": {
        "project_id": "PROJECT_ID"
      },
      "type": "global"
    },
    ...
}

`otel`

  {
    ...
    "otel": {
      "resource": {
        "attributes": {
          "gcp.project_id": "PROJECT_ID",
          "gcp.resource_type": "global"
        }
      },
      "scope": {
        "attributes": {
          "my.scope.attribute": "some scope attribute"
        },
        "name": "my.library",
        "version": "1.0.0"
      }
    },
   ...
  }

Cloud Logging では他のリソースをログエントリにリンクする方法がないため、OTLP リソース、スコープ、エンティティに関するすべての情報を各ログエントリにコピーする必要があります。

この重複により、元のリクエストからできるだけ多くの情報が結果のログエントリに保持されます。ただし、重複は、otel フィールドがログエントリのモニタリング対象リソース（resource）フィールドでも使用されるリソース情報を繰り返すことも意味します。ログエントリのresourceフィールドは課金対象ですが、otelフィールドに重複するリソース情報は課金対象ではありません。

OTLP リクエストに多数のログレコードを含めると、OTLP 情報は、結果の各ログエントリの resource フィールドと otel フィールドの両方にコピーされます。otel フィールドのコピーのストレージは課金対象ではありませんが、resource フィールドの追加コピーのストレージは課金対象です。リクエストに多数の OTLP logRecords を含めると、ログエントリの課金対象の resource フィールドの数は、リクエストあたりの resource あたりの OTLP logRecords の数に比例して増加します。

保存される追加情報を最小限に抑えるには、リクエストごとに 1 つの logRecord 項目を送信することをおすすめします。

制限と割り当て

ロギングに Telemetry API を使用する場合の制限と割り当てについては、ログの取り込みの制限と割り当てをご覧ください。

ログの取り込みに Telemetry API を使用する場合にも、Cloud Logging の割り当てと上限が適用されます。

OTLP ログの取り込みの概要 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

プロトコル サポート

課金

resourceLog

resource

otel