본문 바로가기
WIKI 기술 지식 베이스

로그 트러블슈팅(Logs Troubleshooting)

원문 보기 위키 갱신

Datadog 로그에서 흔한 수집·처리 문제(누락 로그, 데이터 접근 문제, 타임스탬프 불일치)를 해결해요.

출처: 문서

본문

Datadog Logs에서 예기치 않은 동작이 발생하면 조사할 수 있는 흔한 문제가 몇 가지 있는데, 이 가이드가 문제를 빠르게 해결하는 데 도움이 될 수 있어요. 계속 문제가 있다면 추가 지원을 위해 Datadog 지원에 문의하세요.

누락 로그 - 데이터 접근 제한

로그 탐색기 또는 라이브 테일에서 로그가 하나도 보이지 않아요. 역할이 제한 쿼리(restriction query)의 일부이기 때문일 수 있어요.

Datadog에서 제한 쿼리에 접근할 수 없다면 Datadog 관리자에게 문의해 역할이 영향을 받는지 확인하세요.

로그 RBAC 데이터 접근 제어 구성에 대한 자세한 내용은 제한 쿼리 확인을 참고하세요.

레거시 권한도 특히 로그 탐색기에서 로그 접근을 제한할 수 있어요. 구성에 따라 접근이 특정 인덱스 또는 한 번에 단일 인덱스로 제한될 수 있어요. 역할 및 조직 수준에서 레거시 권한이 적용되는 방식에 대한 자세한 내용은 레거시 권한을 참고하세요.

누락 로그 - 일일 쿼터 도달

로그 구성을 변경하지 않았는데 로그 탐색기에서 오늘 날짜의 로그가 누락된 것으로 표시돼요. 일일 쿼터에 도달했기 때문일 수 있어요.

쿼터 설정·업데이트·제거에 대한 자세한 내용은 일일 쿼터 설정을 참고하세요.

과거에 일일 쿼터에 도달했는지 확인하려면 datadog_index:{index_name} 태그로 이벤트 탐색기에서 검색할 수 있어요.

누락 로그 - 수집 창 밖의 타임스탬프

18시간 이상 과거인 타임스탬프가 있는 로그는 수집 시점에 버려져요. datadog.estimated_usage.logs.drop_count 메트릭으로 영향을 받는 service와 source를 확인해 소스에서 문제를 해결하세요.

누락 로그 - 타임존과 정렬되지 않은 타임스탬프

기본적으로 Datadog는 로그의 모든 epoch 타임스탬프를 UTC로 파싱해요. 들어오는 로그가 다른 타임존을 사용하면 타임스탬프가 UTC로부터 해당 오프셋만큼 이동해 보일 수 있어요. 예를 들어 뉴욕(EST -5)에서 보낸 로그는 5시간 과거로 보일 수 있고, 호주(AEST +10)에서 보낸 로그는 예상 시간 프레임보다 10시간 앞으로 보일 수 있어요.

처리 중 로그의 타임존을 조정하려면 Datadog의 파싱 가이드의 각주에서 date 매처와 timezone 파라미터 사용에 대한 내용을 참고하세요. epoch 타임스탬프는 Grok Parser 프로세서의 timezone 파라미터로 지역화를 조정할 수 있어요.

Datadog의 Grok Parser 가이드의 예제를 사용해 지역화된 타임스탬프를 UTC로 변환하려면 다음 단계를 따르세요.

  1. Pipelines 페이지로 이동하세요.
  2. Pipelines에서 로그와 일치하는 올바른 파이프라인을 선택하세요.
  3. 로그를 파싱하는 Grok Parser 프로세서를 여세요.
  4. 로컬 호스트가 UTC+1로 로깅한다고 가정하면 이 차이를 반영하도록 date 매처를 조정하세요. 결과 규칙에는 UTC+1로 타임존을 정의하는 쉼표와 새 문자열이 있게 돼요.
  5. 로그 날짜 리매퍼가 파싱된 속성을 일치 로그의 공식 타임스탬프로 사용하는지 확인하세요.

로그 탐색기로 이동해 로그가 원래 타임스탬프와 일치하게 나타나는지 확인하세요.

JSON 로그에서 타임스탬프 키를 파싱할 수 없음

Datadog는 타임스탬프 속성이 지원되는 날짜 형식 중 하나를 사용해야 해요.

  • ISO8601
  • UNIX(밀리초 EPOCH 형식)
  • RFC3164

이 형식과 정확히 일치하지 않는 타임스탬프는 유사하더라도(예: 나노초 단위의 epoch 타임스탬프) 버려질 수 있어요.

JSON 로그의 타임스탬프를 Datadog에 수집되기 전에 인식된 날짜 형식으로 변환할 수 없다면, Datadog의 산술 프로세서와 로그 날짜 리매퍼를 사용해 타임스탬프를 변환하고 매핑하는 다음 단계를 따르세요.

  1. Pipelines 페이지로 이동하세요.

  2. Pipelines에서 JSON 로그 전처리 위에 마우스를 올리고 연필 아이콘을 클릭하세요.

  3. 예약 속성 매핑 목록에서 timestamp를 제거하세요. 해당 속성은 전처리 중 로그의 공식 타임스탬프로 파싱되지 않아요.

산술 프로세서를 설정해 공식이 타임스탬프를 1000으로 곱해 밀리초로 변환하도록 하세요. 공식의 결과는 새 속성이에요.

로그 날짜 리매퍼를 설정해 새 속성을 공식 타임스탬프로 사용하세요.

로그 탐색기로 이동해 매핑된 타임스탬프가 있는 새 JSON 로그를 확인하세요.

잘린 로그

1MB를 초과하는 로그는 잘려요. datadog.estimated_usage.logs.truncated_count와 datadog.estimated_usage.logs.truncated_bytes 메트릭으로 영향을 받는 service와 source를 확인해 소스에서 문제를 해결하세요.

잘린 로그 메시지

인덱스된 로그에만 적용되는 필드의 추가 잘림이 있어요: message 필드는 75KiB, 비 message 필드는 25KiB로 값이 잘려요. Datadog는 전체 텍스트를 저장하며 로그 탐색기의 일반 목록 쿼리에서 계속 표시돼요. 다만 잘린 필드로 로그를 그룹화하거나 해당 특정 필드를 표시하는 유사한 작업을 수행하는 그룹화 쿼리에서는 잘린 버전이 표시돼요.

라이브 테일에는 있지만 로그 탐색기에는 없는 로그

Logging Without Limits™는 로그 수집을 인덱싱에서 분리해 가장 중요한 로그를 보존할 수 있게 해 줘요. 인덱스에 적용된 제외 필터가 너무 광범위하면 의도보다 많은 로그를 제외할 수 있어요.

제외 필터와 인덱스 필터를 둘 다 주의 깊게 검토하세요. 파싱된 및 파싱되지 않은 JSON 로그는 특히 자유 텍스트 검색으로 짧은 문자열을 제외할 때 예상치 못한 방식으로 인덱스 필터와 일치할 수 있어요. 이로 인해 다른 유용한 데이터가 포함되어 있더라도 전체 로그가 인덱싱에서 제외될 수 있어요. 전체 텍스트 검색과 자유 텍스트 검색의 차이에 대한 자세한 내용은 검색 구문을 참고하세요.

예상 사용량 메트릭

로그가 인덱싱되지 않거나 예상보다 적거나 많은 비율로 보이면 로그 관리 대시보드에서 예상 사용량 메트릭 볼륨을 확인하세요.

메트릭에 따라 datadog_index, datadog_is_excluded, service, status 같은 태그를 필터링에 사용할 수 있어요. 이 태그들을 사용해 datadog.estimated_usage.logs.ingested_events 같은 메트릭을 제외 상태별로, 그리고 로그를 인덱싱하거나 제외하는 인덱스별로 필터링하세요.

메트릭 데이터 포인트의 datadog_index 태그가 N/A로 설정되면 해당 로그가 조직의 어떤 인덱스와도 일치하지 않는 거예요. 인덱스 순서와 필터 쿼리를 검토해 잠재적 제외를 식별하세요.

참고: 예상 사용량 메트릭은 일일 쿼터를 존중하지 않아요.

로그에 트레이스 ID가 있는데 관련 트레이스가 누락됨

로그 탐색기의 로그에 트레이스 ID가 표시되는데, 트레이스를 보려고 클릭하면 관련 트레이스가 누락되었다는 메시지가 보여요. 연결된 트레이스가 수집되지 않았거나 보존되지 않은 거예요.

이런 일이 발생하는 이유는 로그와 트레이스가 독립적으로 샘플링되기 때문이에요.

  • 트레이스는 트레이서 수준, 에이전트 수준, 수집 제어를 통한 수집 시점에 샘플링될 수 있어요.
  • 로그는 인덱스 제외 필터와 쿼터를 통해 샘플링될 수 있어요.

이러한 샘플링 결정이 조정되지 않으므로, 로그는 이 단계 중 어느 곳에서든 샘플아웃된 트레이스를 가리키는 트레이스 ID를 보유할 수 있고 그 반대도 마찬가지예요.

이는 구성 오류를 나타내지 않아요. 트레이스 ID는 트레이서가 올바르게 주입했지만 트레이스 자체가 샘플링 중 버려진 거예요. 이런 불일치 가능성을 줄이려면 트레이스와 로그 보존 전략을 정렬하세요. 자세한 내용은 로그와 트레이스 상관관계와 트레이스 수집 제어를 참고하세요.

지원 티켓 만들기

위의 트러블슈팅 단계로 Datadog의 누락 로그 문제가 해결되지 않으면 지원 티켓을 만드세요. 가능하면 다음 정보를 포함하세요.

정보 설명
원시 로그 샘플 아키텍처 또는 로거 구성에 따라 원본에서 생성된 로그를 직접 수집하세요. 로그를 텍스트 파일 또는 원시 JSON으로 지원 티켓에 첨부하세요.
인덱스 구성 로그가 라이브 테일에는 나타나지만 로그 탐색기에는 없으면 Get All Indexes API 호출 응답을 포함하세요. 조직에 인덱스가 많으면 예상 사용량 메트릭을 검토해 관련 인덱스를 식별한 다음 해당 인덱스에 대한 Get an Index API 호출 응답을 포함하세요.
에이전트 플레어 에이전트로 로그를 보내는데 Datadog UI 어디에도 나타나지 않으면 에이전트 플레어를 지원 티켓과 함께 제출하세요.
기타 소스 에이전트 외의 소스로 로그를 보낸다면 로그의 원래 소스에 대한 세부 정보(예: Lambda Forwarder 또는 Kinesis Firehose)를 포함하세요.

더 알아보기 (Learn more)

추가로 도움이 되는 문서, 링크, 아티클: