뉴렐릭 OTLP 속성 처리 업데이트

우리는 더 관대한 속성 처리를 위해 OTLP 수집 검증 로직을 조정하고 있습니다.

뉴웰릭 OTLP 엔드포인트는 속성에 대한 다양한 검증을 수행합니다. 키와 값의 길이와 같은 사항을 제한하는 속성 제한이 있으며, protobuf 메시지 정의를 통해 표현할 수 있지만 실제로는 일반적으로 발생하지 않는 이기종인(예: 문자열 및 정수와 같은 값 유형이 혼합된인), 중첩인(예:인의인) 등의 예외 사례에 대한 값 유형에 대한 추가 제약 조건이 있습니다.

현재 뉴렐릭 OTLP 엔드포인트는 검증이 엄격합니다. 어떤 경우에는 문제가 있는 속성을 자동으로 정리하지만 대부분의 유효성 검사 문제의 경우 단일 속성이 유효하지 않으면 전체 레코드를 삭제합니다.

이러한 엄격한 검증은 고객이 OTLP 데이터를 뉴럴릭으로 보낼 때 겪는 가장 일반적인 어려움 중 하나입니다. 다행히도 간단한 해결책이 있습니다.

우리는 관대한 속성 처리 자세를 취하고 있습니다. 속성이 유효하지 않으면 해당 속성을 정리하거나 수정하고 레코드를 보관합니다. 심각한 경우에는 직관적으로 보관할 방법이 없어 기록을 삭제할 수도 있습니다. 속성을 정리하거나 수정하거나 레코드를 삭제할 때마다 NrIntegrationError를 생성하여 소스에서 문제를 추적하고 해결하는 데 도움이 됩니다.

이 변경 사항은 2025년 6월 2일 에 적용됩니다.

이것이 나에게 어떤 영향을 미칠까요?

우리는 이것이 거의 모든 경우에 환영할만한 도움이 될 것이라고 믿습니다. 현재 우리가 엄격하게 검증하는 방식에서는 누락된 데이터가 자주 발생하는데, 특히 여러 개별 팀이 관리하는 많은 구현, 배포가 있는 환경에서는 이를 추적하고 진단하는 것이 힘들 수 있습니다. 이러한 변화로 뉴렐릭 OTLP저장은 "보낸 것을 저장한다"는 철학을 더 잘 구현하게 될 것입니다.

그러나 뉴렐릭의 사용 기반 가격 책정 모델을 고려할 때 이러한 변경은 이전에 삭제된 레코드가 이제 저장되어 계정의 데이터 사용량에 반영된다는 것을 의미합니다.

속성 제한 에 대한 OTLP 입체점 문서를 따르고 데이터 속성이 OpenTelemetry 표준 속성 정의를 준수하는 경우 에는 수행할 작업이 없습니다. 이러한 제약 조건을 준수한다는 것은 현재는 데이터가 삭제되지 않으며, 따라서 추가 데이터가 저장되지 않는다는 것을 의미합니다.

속성 검증으로 인해 현재 계정의 데이터가 삭제되는지 확인하려면 다음 NRQL 쿼리를 실행하세요.

FROM NrIntegrationError SELECT * WHERE message like 'One or more OTLP data point(s) was dropped%'

이 쿼리에서 결과가 반환되면 이러한 변경에 따라 사용량과 청구 방식이 변경될 수 있습니다. 정확한 금액은 기록이 한도를 위반하는 빈도에 따라 달라집니다. 구체적으로, 현재 다음의 사례는 기록이 삭제되는 결과를 가져오며 아래 설명된 대로 조정될 예정입니다.

• 속성 이름이 255자 길이 제한을 초과했습니다. 속성 이름이 잘리고 유지됩니다.
• 속성 문자열 값이 4095자 길이 제한을 초과했습니다. 속성 값은 잘리고 유지됩니다.
• 속성 바이트 포함이 바이트 제한인 128k를 초과했습니다. 해당 속성은 정리되고 레코드는 보존됩니다.
• 문자 길이가 64개 항목 제한을 초과했습니다. 해당 속성은 정리되고 레코드는 보존됩니다.

참고: 가장 일반적으로 발견되는 유효성 검사 문제는 속성 문자열 값이 4095자 제한을 초과하는 것입니다. 긴 속성 값이 있는 레코드를 삭제하는 것에서 긴 속성을 자르고 레코드를 유지하는 것으로 유효성 검사를 변경하면 데이터 사용량이 눈에 띄게 증가할 수 있습니다.

추가로 발생할 수 있는 데이터 사용량을 상쇄하는 방법에 대한 조언은 완화책을 참조하세요.

완화

OpenTelemetry의 핵심 가치 제안 중 하나는 텔레메트리 와이어 파이프라인을 제어할 수 있는 도구를 제공하는 것입니다. 이에 따라 데이터 사용의 변화를 완화하는 데 도움이 되는 다양한 도구를 사용할 수 있습니다. 자세한 내용은 OpenTelemetry 데이터 수집 볼륨 관리를 참조하세요. 여기서는 특히 관련성이 높은 몇 가지 전략이 있습니다.

• 긴 속성 잘라내기
• 문제가 되는 속성을 삭제합니다
• 샘플링을 사용하여 더 적은 레코드 보내기

긴 속성 잘라내기

여기에서 보여준 것처럼 수집기 변환 프로세서와 truncate_all 편집기를 활용해 모든 속성을 알려진 한도까지 잘라냅니다. 이번 변경 이후 뉴웰릭 OTLP 엔드포인트가 수행할 작업은 다음과 같습니다. 하지만 이 기술을 사용하면 한도보다 낮은 한도를 설정하여 사용량 변화를 상쇄할 수 있습니다. 예를 들어, 옵저버빌리티 사용 사례에 처음 1000자만 필요하다고 생각되면 1000자로 제한을 설정할 수 있습니다.

transform:
  trace_statements:
    - truncate_all(span.attributes, 4095)
    - truncate_all(resource.attributes, 4095)
  log_statements:
    - truncate_all(log.attributes, 4095)
    - truncate_all(resource.attributes, 4095)
  metric_statements:
    - truncate_all(datapoint.attributes, 4095)
    - truncate_all(resource.attributes, 4095)

문제가 되는 속성을 삭제합니다

수집기 변환 프로세서와 delete_key 편집기를 활용하여 가치가 없는 속성을 삭제합니다.

transform:
  trace_statements:
    - delete_key(span.attributes, "attribute.key.to.drop")
  log_statements:
    - delete_key(log.attributes, "attribute.key.to.drop")
  metric_statements:
    - delete_key(datapoint.attributes, "attribute.key.to.drop")

특히 길어서 사용에 큰 영향을 미치는 속성 키나, 짧지만 일반적으로 유용하지 않은 속성 키를 삭제하도록 선택할 수 있습니다. 참고로, 다음 목록은 속성 값 길이 제한을 위반하는 가장 흔한 10개 속성을 요약한 것입니다.

• exception.stactrace
• other - OpenTelemetry 의미 규칙에 정의되지 않은 사용자 정의 속성에 대한 포괄적인 용어
• db.statement
• process.command_line
• graphql.document
• db.operation
• db.query.text
• http.url
• exception.message
• http.target

샘플링을 사용하여 더 적은 레코드 보내기

여기에 설명된 전략 중 하나를 사용하여 샘플링 속도를 조정하여 추가 데이터를 오프셋합니다.