Splunk REST API로 같은 조건의 로그 분석 반복하기

성능 문제를 분석할 때 같은 Splunk 검색을 여러 시간대와 환경에서 반복할 일이 있었습니다. 웹 UI에서 조건을 바꾸며 확인하다 보면 이전에 어떤 범위로 검색했는지 다시 맞춰야 했습니다. 결과를 다른 사람과 비교할 때도 검색 조건부터 확인하는 일이 생겼습니다.

그래서 REST API로 검색을 실행하고 결과를 받아 분석하는 방식으로 정리했습니다. 검색 조건과 시간 범위를 코드에 남겨 같은 분석을 다시 실행할 수 있도록 했습니다.

검색 조건과 시간 범위 고정

비교하려는 대상 API와 환경, 시작·종료 시각을 먼저 정했습니다. 같은 쿼리를 사용해도 시간 범위나 대상 인스턴스가 다르면 결과를 그대로 비교하기 어렵습니다.

평균만 보면 일부 요청이 오래 걸리는 상황을 놓칠 수 있어 응답 시간의 분포도 함께 봤습니다. 아래는 로그 필드가 uri, elapsed_ms라고 가정한 SPL 예시입니다. 실제 인덱스와 필드 이름은 환경에 맞춰 바꿔야 합니다.

search index=example_logs uri="/api/users"
| stats count,
        avg(elapsed_ms) as avg_ms,
        perc95(elapsed_ms) as p95_ms,
        max(elapsed_ms) as max_ms

배포 전후를 비교할 때는 같은 길이의 시간 구간뿐 아니라 요청 수와 데이터 양, 오류 비율도 함께 봐야 합니다. 조건이 달라졌다면 응답 시간이 줄었다는 결과만으로 배포 효과라고 판단하기 어렵습니다.

REST API 검색 과정

비동기 검색은 검색 작업을 만들고, 작업 상태를 확인한 다음, 완료된 결과를 가져오는 순서입니다. Splunk Search API 문서 에 각 endpoint와 검색 상태가 정리돼 있습니다.

다음은 작업을 만드는 요청 예시입니다. 주소와 토큰은 환경 변수로 전달하고, 검색 시간은 비교에 사용할 실제 구간으로 지정합니다.

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${SPLUNK_TOKEN}" \
  --data-urlencode 'search=search index=example_logs uri="/api/users" | stats count, avg(elapsed_ms)' \
  --data-urlencode 'earliest_time=2026-02-01T00:00:00+09:00' \
  --data-urlencode 'latest_time=2026-02-02T00:00:00+09:00' \
  --data-urlencode 'output_mode=json' \
  "${SPLUNK_BASE_URL}/services/search/jobs"

반환된 sid로 상태를 조회합니다. 자동화 스크립트에서는 완료 여부뿐 아니라 실패 상태와 대기 제한 시간을 처리해야 합니다. 결과가 많다면 페이지 단위로 가져오고, 검색 조건과 결과를 함께 남겨야 이후 비교도 가능합니다.

요청 식별자로 서비스 연결

특정 요청이 느린 이유를 볼 때는 공통 trace ID 같은 값으로 여러 서비스의 로그를 모았습니다. 구조화 로그와 trace context가 이미 있어 같은 요청에 속한 기록을 찾을 수 있었습니다.

search index=example_logs trace_id="example-trace-id"
| sort 0 _time
| table _time service_name uri status elapsed_ms

시간순으로 나열해도 각 로그의 소요 시간을 모두 더하면 전체 응답 시간이 되는 것은 아닙니다. 상위 호출 안에 하위 호출 시간이 포함되거나 여러 요청이 병렬로 실행될 수 있습니다. 각 시간의 측정 구간을 확인하면서 어느 호출을 기다렸는지 좁혀야 합니다.

로그 분석 이후의 확인

API로 검색을 반복할 수 있게 되면서 환경이나 시간 범위를 바꿔 같은 질문을 확인하기 쉬워졌습니다. 특정 서비스 안에서 시간이 늘어나는지, 다른 서비스의 응답을 기다리는지, 데이터가 많아질수록 어디가 느려지는지 나눠 볼 수 있었습니다.

다만 로그에 남지 않은 DB 내부 대기나 캐시 상태까지 검색만으로 알 수는 없습니다. 로그로 병목 후보를 좁힌 뒤에는 해당 코드와 쿼리도 확인해야 했습니다.

다음 글에서는 28초 걸린 사용자 조회 API의 병목 분석을 다룹니다.