OTLP 로그 수집 개요

이 문서에서는 OTLP 형식 로그를 Cloud Logging으로 수집하는 데 사용되는 Telemetry (OTLP) API telemetry.googleapis.com에 대해 소개합니다. 수집된 로그는 로그 항목으로 저장됩니다. 예시를 보려면 Telemetry API에 OTLP 형식 로그 쓰기를 참조하세요.

SDK를 사용하는 애플리케이션 또는 OpenTelemetry Collector를 사용하여 Telemetry API로 로그를 보낼 수도 있습니다.

로그, 측정항목, trace를 위한 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 로그 항목이 됩니다. 다음 두 가지가 모두 참인 경우 your Google Cloud project 의 스토리지 및 결제에 가장 큰 변화가 발생합니다.

  • 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 수에 비례하여 증가합니다.

저장되는 추가 정보를 최소화하려면 요청당 하나의 logRecord 항목을 보내는 것이 좋습니다.

한도 및 할당량

로깅을 위해 Telemetry API 사용과 관련된 한도 및 할당량에 대한 자세한 내용은 로그 수집 한도 및 할당량을 참조하세요.

로그 수집을 위해 Cloud Logging 할당량 및 한도를 사용할 때도 적용됩니다.