문제해결

이 페이지에서는 Cloud Logging에서 로그 기반 측정항목을 사용할 때 일반적으로 발생하는 상황에 대한 문제해결 정보를 제공합니다.

측정항목에 로그 데이터가 없음

로그 기반 측정항목에 데이터가 누락되는 이유로는 다음 몇 가지가 있습니다.

  • 새 로그 항목이 측정항목의 로그 쿼리와 일치하지 않을 수 있습니다. 로그 기반 측정항목은 측정항목이 생성된 후에 수신되는 일치 로그 항목에서 데이터를 가져옵니다. Logging은 이전 로그 항목에서 측정항목을 백필하지 않습니다.

  • 새 로그 항목에 올바른 필드가 포함되어 있지 않거나 데이터가 분산 측정항목의 추출에 맞는 올바른 형식으로 되어 있지 않을 수 있습니다. 필드 이름과 정규 표현식이 올바른지 확인하세요.

  • 측정항목 카운트가 지연될 수 있습니다. 로그 뷰어에 계수할 수 있는 로그 항목이 표시되더라도 Cloud Monitoring에 로그 기반 측정항목을 업데이트하는 데 최대 1분이 소요됩니다.

  • 표시된 로그 항목의 타임스탬프가 너무 먼 과거나 미래 시점으로 되어 있어서 늦게 계수되거나 아예 계수되지 않을 수 있습니다. 로그 항목이 Cloud Logging에 의해 24시간 이전 또는 10분 후에 수신되는 경우 로그 항목은 로그 기반 측정항목에 계산되지 않습니다.

    늦게 도착하는 항목의 수는 각 로그별로 시스템 로그 기반 측정항목인 logging.googleapis.com/logs_based_metrics_error_count에 기록됩니다.

    : 로그 기반 측정항목과 일치하는 로그 항목이 늦게 도착합니다. timestamp는 2020년 2월 20일 2:30 PM이고 receivedTimestamp는 2020년 2월 21일 2:45 PM입니다. 이 항목은 로그 기반 측정항목에 포함되지 않습니다.

트리거되지 않은 거짓양성 알림 또는 알림

경고의 정렬 기간이 너무 짧기 때문에 로그 기반 측정항목에서 트리거되지 않는 거짓양성 알림이나 알림을 받을 수 있습니다. 정렬 기간이 너무 짧아서 문제가 생기는 일반적인 상황은 알림이 less than 논리를 사용하거나, 알림이 분포 측정항목의 백분율 조건을 기반으로 하는 경우입니다.

로그 항목이 Logging으로 늦게 전송될 수 있으므로 거짓양성 알림이 발생할 수 있습니다. 예를 들어 로그 필드 timestampreceiveTimestamp는 어떤 경우에 분 단위의 델타 값을 가질 수 있습니다. 또한 Logging이 로그를 수집할 때 로그 항목이 생성될 때와 Logging이 로그 항목을 수신할 때까지 고유한 지연이 존재합니다. 즉, 로그 항목이 생성된 이후의 특정 시점까지 특정 로그 항목의 총 개수가 Logging에 없을 수 있습니다. 이것이 less than 논리를 사용하거나 배포 측정항목의 백분율 조건을 기반으로 하는 알림이 거짓양성 알림을 생성할 수 있는 이유입니다. 즉, 모든 로그 항목이 아직 계수되지 않은 것입니다.

하지만 로그 기반 측정항목은 결국에는 언제나 eventual consistency를 가집니다. 로그 기반 측정항목은 로그 기반 측정항목과 일치하는 로그 항목이 로그의 receiveTimestamp보다 훨씬 오래되거나 최신의 timestamp와 함께 Logging으로 전송되기 때문에 결국에는 eventual consistency를 가집니다.

즉, Logging이 동일한 타임 스탬프를 가진 기존 로그 항목을 수신한 후에 로그 기반 측정항목은 이전 타임 스탬프를 가진 로그 항목을 수신할 수 있습니다. 따라서 측정항목 값을 업데이트해야 합니다.

알림이 정시 데이터에 대해서도 정확함을 보장하려면 로그 기반 측정항목에 대한 알림 정책에서 정렬 기간이 2분 이상인 알림 조건을 사용해야 합니다. 분 단위 지연으로 Logging에 전송되는 로그 항목의 경우는 적시성과 정확성의 균형을 맞추기 위해 정렬 시간 10분을 사용하는 것을 권장합니다.

측정항목에 시계열이 너무 많음

측정항목 내 시계열의 개수는 여러 가지 라벨 값으로 구성된 조합의 개수에 따라 결정됩니다. 시계열 수는 측정항목의 카디널리티라고 하며 30,000을 초과해서는 안 됩니다.

모든 라벨 값 조합에 대해 시계열을 생성할 수 있으므로 값이 많은 라벨이 하나 이상이면 30,000개 시계열을 어렵지 않게 초과할 수 있습니다. 카디널리티가 높은 측정항목은 피하는 것이 좋습니다.

측정항목의 카디널리티가 증가하면 측정항목이 제한되고 일부 데이터 포인트가 측정항목에 기록되지 않을 수 있습니다. 차트가 처리해야 하는 시계열 수가 많아서 측정항목을 표시하는 차트의 로드 속도가 느려질 수 있습니다. 또한 시계열 데이터를 쿼리하는 API 호출 비용이 발생할 수 있습니다. 자세한 내용은 Cloud Monitoring 비용을 참조하세요.

카디널리티 측정항목이 많아지는 것을 피하려면 다음 안내를 따르세요.

  • 라벨 필드와 추출기 정규 표현식이 제한된 카디널리티가 있는 값과 일치하는지 확인하세요.

  • 경계가 없이 바뀔 수 있는 텍스트 메시지를 라벨 값으로 추출하지 마세요.

  • 무한한 카디널리티가 있는 숫자 값을 추출하는 일을 삼가세요.

  • 알려진 카디널리티 라벨(예: 일련의 알려진 값이 있는 상태 코드)에서만 값을 추출하세요.

이러한 두 시스템 로그 기반 측정항목을 사용하면 라벨 추가 또는 삭제가 측정항목의 카디널리티에 미치는 영향을 측정할 수 있습니다.

이러한 측정항목을 검사 할 때 측정항목 이름별로 결과를 더 필터링 할 수 있습니다. 자세한 내용은 측정항목 선택: 필터링을 참조하세요.

측정항목 이름이 잘못됨

카운터 또는 배포 측정항목을 만들 때 프로젝트의 로그 기반 측정항목 중에서 고유 한 측정항목 이름을 선택하세요.

측정항목 이름 문자열은 100자를 초과할 수 없으며 다음 문자만 포함할 수 있습니다.

  • A-Z
  • a-z
  • 0-9
  • 특수 문자 _-.,+!*',()%\/.

    슬래시 문자 /는 측정항목 이름 내 계층구조를 나타내며 이름의 첫 문자로 사용될 수 없습니다.

라벨 값이 잘림

사용자 정의 라벨 값은 1,024바이트를 초과하면 안 됩니다.