Slow Request Log

Slow Request Log (느린 요청 로그) (ops-monitoring-slow-request-log)

검색 요청이 유난히 느릴 때 어떤 쿼리가 지연을 일으키는지 알고 싶어질 때가 있어요. Qdrant의 Slow Request Log가 바로 그 역할을 해줘요. 이 문서에서 이 로그가 무엇을 기록하는지, 어떻게 읽는지, 응답 필드는 어떻게 생겼는지 차근차근 설명해 드릴게요.

출처: Qdrant 공식문서

v1.16.0(beta)부터 사용할 수 있어요. 향후 릴리스에서 동작이 바뀔 수 있어요.

Slow request log는 노드가 시작된 이후 가장 느렸던 고유한 연산들을 기록해요. 어떤 쿼리가 높은 지연 시간의 원인인지 파악하는 데 사용할 수 있죠.

이 로그는 요청 유형별로 최대 32개 항목을 유지해요. 항목은 요청 본문과 컬렉션 이름의 콘텐츠 해시(content hash)로 중복 제거되므로, 동일한 요청이 반복돼도 로그가 중복으로 채워지지 않아요. 로그는 각 요청 패턴이 몇 번 발생했는지 횟수도 세어 둬요. 특정 요청 유형의 큐가 가득 차면, 새 항목은 기존의 가장 빠른 항목보다 오래 걸린 경우에만 그 자리를 대체해요.

이 로그는 메모리에만 존재하고 서버가 재시작되면 초기화돼요. 로그를 읽는 유일한 방법은 REST 엔드포인트를 통해서예요. 배포나 구성 변경 후에는 서버를 재시작해 깨끗한 기준선(baseline)을 확보하는 게 좋아요.

로그는 노드별로 존재해요. 각 노드는 자신의 로컬 샤드에서 일어난 연산을 추적하죠. 한 노드에서 로그를 조회하면 그 노드의 데이터만 반환돼요. 클러스터 전반의 느린 요청에 대한 완전한 그림을 얻으려면 각 노드를 따로 조회하고 결과를 집계해야 해요.

Slow Request Log는 기본적으로 활성화되어 있고 비활성화할 수 없어요.

무엇이 기록되나요 (What Gets Captured)

로그는 50ms보다 오래 걸리는 샤드 레벨 연산을 기록해요. 다음 연산 유형이 추적돼요.

  • core_search와 query_batch
  • count
  • retrieve
  • facet
  • upsert, delete 같은 쓰기 연산

로그 읽기 (Reading the Log)

GET /profiler/slow_requests는 로그의 현재 상태를 반환해요. 이 엔드포인트는 manage 접근 권한이 필요하고 REST API로만 제공돼요.

쿼리 파라미터:

Parameter Default Description
limit 10 반환할 최대 항목 수예요.
request — 요청 유형에 대한 부분 문자열(substring) 필터예요. 예를 들어 search는 검색 연산만 반환해요. 
# 모든 유형에서 가장 느린 상위 10개 요청
curl http://YOUR_NODE_URL:6333/profiler/slow_requests \
  -H "api-key: your-api-key"

# 검색 요청 중 가장 느린 상위 20개만
curl "http://YOUR_NODE_URL:6333/profiler/slow_requests?limit=20&request=search" \
  -H "api-key: your-api-key"

응답 필드 (Response Fields)

응답의 각 항목에는 다음 필드가 포함돼요.

Field Description
collection_name 요청이 실행된 컬렉션이에요.
duration 요청 시간(초 단위)이에요.
datetime 요청의 타임스탬프예요.
request_name 연산 유형이에요. 예: core_search.
approx_count 시작 이후 이 요청 패턴이 관찰된 대략적인 횟수예요.
cpu_usage_ratio 요청 중 CPU 사용률이에요(선택 사항).
request_body 전체 요청을 JSON으로 표현한 값이에요.

결과는 가장 느린 것부터 정렬되고, 그다음 limit만큼 잘려서 반환돼요.

더 알아보기 (Learn more)