Skip to main content

The Forrester Wave™: XDR 플랫폼, 2026년 2분기

보고서 보기
회사 소개파트너지원|로그인
Elastic logo
무료 체험판 시작영업팀에 문의하기

문제 해결 가이드: Kibana Discover 로드 시 발생하는 6가지 일반적인 문제 해결

By
Stef Nestor

Discover 는 데이터를 검색, 필터링 및 검사(시계열)하기 위한 Elastic®의 핵심 Kibana®UI입니다. 시각화 는 데이터 집계/요약에 사용됩니다.Discover UI 는 대용량 데이터 Elasticsearch® 응답에 탄력적으로 대응하지만, (압축되지 않은) 응답 크기, 매핑 폭발 및 브라우저 제한으로 인해 때때로 문제가 발생할 수 있습니다. 

아래에서는 긴 로드 시간, 시간 초과, 오류를 포함하여 가장 일반적인 과거 문제들을 요약하고, 이를 해결하기 위한 순차적인 문제 해결 가이드를 제공합니다. 참고: 이 문서의 API는 v8.6 기준으로 작성되었으나, 일반적인 문제 해결 흐름은 이전 및 이후 버전에도 적용됩니다.

Kibana 이벤트 로그

사용자 세션을 설정하고 로드한 후, Kibana는 기본 URI /app/discover (또는 관련 Kibana Space 특정 URI)를 통해 Discover를 로드합니다. 이 페이지를 로드하기 위해 브라우저 페이지는 Kibana 서버에서 세 개의 API를 순차적으로 요청합니다(필요에 따라 Kibana를 거쳐 아래의 Elasticsearch 서버로 요청).

일반적인 문제 1: 로드 시 페이지 오류

Kibana 페이지 로드 시 오류가 발생하면 브라우저의 네트워크 탭 을 열어 어떤 순차적 요청이 실패하는지 확인하십시오. HAR 로그를 내보내 결과를 공유할 수 있습니다.

1. Data view 로드

브라우저 페이지는 현재 선택된Data View 에 대해 Kibana의 Saved Objects 엔드포인트를 요청합니다(이 개체는 이전 버전에서 “인덱스 패턴”으로 명명되었으나 명확성을 위해 v8.0에서 이름이 변경되었으므로 코드는 여전히 `type:index-pattern`을 대상으로 합니다).

POST /api/saved_objects/_bulk_get
[{"id":"${INDEX_PATTERN_ID}","type":"index-pattern"}]

이 Kibana API는 Saved Object의 백업 Alias인 .kibana 아래의 Elasticsearch API로 검색을 전달합니다. 쿼리 번역에 대해서는 확실하지 않지만, 대략 다음과 같을 것입니다:

GET .kibana*/_search
{"query": {"bool": {"filter": [{"bool": {"should": [{
 "match_phrase": {"_id": "index-pattern:INDEX_PATTERN_ID"}
}]}}]}}}

참고: 저장된 개체는 제목이나 이름이 아닌 Data view의 ID로 조회됩니다. 내보내기/가져오기 를 수행하거나 Kibana 스페이스 또는 Elasticsearch 클러스터 간에 저장된 개체를 복사 하는 경우, 가져오기 중에 기본 ID가 변경되어 시각화/대시보드/Discover 오류가 발생할 수 있습니다(방지하려면 저장된 개체의 가져오기 모듈을 참조하십시오). 이러한 필드의 차이점을 보여주기 위해:

저장된 개체
일반적인 문제 2: 누락된 Data view

이 문제가 발생하는 경우, 페이지 로드 중에 오른쪽 하단에 다음과 유사한 경고/오류 모듈이 표시됩니다: "DATA_VIEW_ID"은(는) 구성된 Data view ID가 아닙니다.

이 오류는 현재 Kibana Space 의 컨텍스트에서 보고되며, Data View가 다른 Space에 존재하는지 여부는 고려하지 않습니다.

2. 필드 로드

다음으로 Kibana UI가 백업 인덱스의 관련 필드 모음을 로드합니다.

API. 먼저, API 요청을 수행합니다:

GET /api/index_patterns/_fields_for_wildcard?pattern=INDEX_PATTERN&meta_fields=_source&meta_fields=_id&meta_fields=_index&meta_fields=_score

이 API는 사용자가 왼쪽 상단에서 Data View를 선택할 때마다 다시 트리거됩니다. 백엔드에서 Kibana는 Elasticsearch의 필드 Caps API로부터 인덱스를 반환합니다.

일반적인 문제 3: 매핑 폭발

이 API의 응답 시간은 매핑 폭발의 영향을 크게 받으며, 이는 이 API의 압축/비압축 응답 크기로 부분적으로 진단할 수 있습니다. 일반적으로 이는 얼마나 다양한 인덱스 매핑 이 로드되는지와 관련이 있지만, 매핑 제한을 초과하여 발생할 수도 있습니다. 일반적으로 3초 미만으로 반환되지만, 10초 이상인 경우 확실히 느린 것으로 간주해야 합니다.

일반적인 문제 4: 필드 충돌

오류는 과거부터 인덱스 간의 필드 이름 충돌로 인해 발생해 왔습니다. 근본적인 인덱스 매핑을 수정하는 것이 좋지만, 런타임 필드를 적용 하여 임시 재정의로 잘못된 인덱스의 매핑 유형을 수정할 수도 있습니다.

JS. API 결과가 반환되면 왼쪽 서랍(“선택된 필드” 및 “사용 가능한 필드” 표시)이 열려 있는 경우, 브라우저 JavaScript가 이 필드들에 대한 요약 분석을 수행합니다. 속도가 느리면 브라우저 네트워크 탭에 API 요청은 종료되었으나 후속 (3) 요청이 수 초 동안 시작되지 않는 것으로 나타납니다. 사용자는 일반적으로 ≥10초 이상일 때만 이를 인지합니다.

필드 스크린샷

이 JavaScript 컴파일 시간은 브라우저 DevTool의 Performance 탭을 통해 진단됩니다(예: Chrome, Firefox, Edge; 공유를 위해 HAR과 유사한 형식으로 내보낼 수도 있습니다).

3. 검색 로드

마지막으로, 브라우저 페이지에서 API 검색 요청을 수행합니다. 이 API 검색 요청은 Kibana 서버를 통과하지만, Elasticsearch API에 직접 요청하는 것과 거의 동일한 시간이 소요됩니다(소요되어야 합니다).

API. 이 URI의 기본값은 다음과 같습니다:

POST /internal/bsearch {REQUEST_BODY_HERE}

하지만 고급 설정 courier:batchSearches 가 false (<v8.0)로 설정된 경우, 그러면 대신 다음 API를 요청합니다:

POST /internal/_msearch {REQUEST_BODY_HERE}
(빠른 페이지 검색 지원: #inspectViaDevTools.) 이 검색을 처리하는 데 시간이 걸리는 경우, 일반적으로 조회 기간을 가능한 한 최소한으로(예: 1~5분) 줄입니다. 그런 다음 Discover > Inspect로 이동합니다. Statistics > “Query time”과 비교하여 총 로딩 시간(아래 녹색 상자)을 빠르게 확인하겠습니다.
검사기-1

“쿼리 시간”(Elasticsearch가 검색하는 데 소요된다고 판단하는 시간)과 Kibana가 보고하는 시간 사이에는 차이가 있을 것으로 예상되지만, 후자가 전자와 수십 배 이상 차이가 나는지 확인해야 합니다. 이는 예를 들어 Kibana 서버 부하, HTTP 압축 비활성화 또는 일반적인 렌더링 문제 등을 나타낼 수 있습니다. 

Kibana 서버 부하와 일반적인 렌더링 문제를 구분하기 위해 검색을 더 자세히 조사하려면 Inspect > Request > Open in Console(일명 DevTools)로 이동하십시오. 시각적으로는 다음과 같습니다:

검사기-2

그런 다음 이 API 검색 요청을 DevTools 에서 실행하고 별도로 Elasticsearch API curl을 통해 실행하여 Discover, DevTools 및 Elasticsearch API 간의 전반적인 응답 시간 차이를 확인합니다.

일반적인 문제 5: Elasticsearch API에서 쿼리 작업이 느린 경우

Elasticsearch도 다른 두 가지와 마찬가지로 느리다면, 원래의 Discover 뷰에서 최적화되지 않은 검색/필터를 의심해 볼 수 있습니다. 필터/검색이 적용되지 않았거나(또는 적용하지 않은 상태에서 재현되는 경우), CAT Node, CAT Threadpools (특히 검색 스레드), 그리고 CAT Tasks (장기 실행 작업용)를 통해 일반적인 Elasticsearch 성능을 확인합니다. 클러스터 전체의 문제가 발견되지 않으면, Discover에서 선택한 서로 다른 Data view 간의 검색 응답 시간을 비교한 다음, 이러한 검색과 관련된 Query Profiling (검색 요청 본문에 profile: true 를 삽입한 후)을 비교합니다.

JS. API 결과가 반환되면 브라우저의 JavaScript가 실행되어 1) 표시 테이블 요약(열 보기를 켜거나 끌 수 있는 중앙 하단의 “Documents” 테이블) 또는 2) “필드 통계”(베타 버전, Advanced Settings 에서 discover:showFieldStatistics를 통해 전환)를 로드합니다.

일반적인 문제 6: 매핑 폭발로 인한 렌더링 시간 영향

매핑 폭발(Mapping Explosions) 은 대규모 결과 집합으로 이어질 수 있으며, 과거에 브라우저 성능 저하를 유발한 적이 있습니다(예: kibana#144673). 매핑 폭발은 Chrome의 '오류: maximum call stack size exceeded'와 같은 브라우저별 오류를 표면화할 수 있는데, 이는 시크릿 모드에서 재현되고 Firefox/Safari에서는 발생하지 않으며 때로는 Chrome을 업그레이드해야만 해결됩니다. 그러나 결과가 반환된 후 오류 없이 매우 느린 렌더링 프로세스가 발생하는 경우, 브라우저 성능 프로필을 기록하여 렌더링 속도 저하의 원인을 분석해야 합니다. 저희 팀은 Kibana GitHub, Elastic Discuss를 통하거나 지원 케이스를 열어 출력 결과를 검토해 드릴 수 있습니다!

연쇄적 영향

(빠른 페이지 검색 지원: #devToolsAuto.) 잠재적인 매핑 폭발(Mapping Explosions) 문제를 해결하는 동안, DevTools 는 Discover 보다 응답이 느릴 수 있으며 URI로 인해 요청이 예상되지 않을 때 왼쪽 상단 아이콘이 로드될 수 있습니다.

GET /api/console/autocomplete_entities?fields=true&indices=true&templates=true&dataStreams=true
이는 DevTools > Settings > “Autocomplete”를 통해 (최소한) Fields를 비활성화하고 Refresh Frequency를 높여 제어할 수 있습니다.
콘솔 설정

이러한 요청은 빈도와 비용에 따라 1) 페이지 충돌이나 “페이지를 기다리시겠습니까?(wait for page?)” 배너를 유발하는 로컬 브라우저와 2) Kibana 서버의 속도를 저하시킬 수 있습니다. 이 변경 사항은 로그인한 사용자에게만 적용됩니다.

결론

Discover는 클러스터 내 여러 인덱스의 데이터를 쉽게 조사할 수 있는 방법입니다. 일부 구성 및 설정으로 인해 이 UI가 불필요하게 느리게 로드될 수 있습니다. 이 가이드에서는 이러한 다양한 문제의 영향을 살펴보았지만, 올바른 데이터 위생 관리를 통해 모두 방지할 수 있습니다. 더 많은 데이터 위생 관리 팁은 Elasticsearch 설명서를 참조하십시오.

이 게시물에서 설명된 모든 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

Elastic Cloud 무료 체험판 등록하기

선택하신 클라우드 서비스 제공자에서 완전히 로드된 배포를 이용하세요. Elasticsearch의 개발사로서, Elastic이 클라우드에 있는 여러분의 Elastic 클러스터에 기능과 지원을 제공해드립니다.

무료 체험판 시작