Kibana Dashboards API에서 이전 버전과의 호환성이 의미하는 사항

기술 미리 보기 기간에는 릴리스 간에 API 형태가 변경될 수 있었습니다.[1] 이제는 그렇지 않습니다. 정식 출시(GA)는 다음을 의미합니다.

• 완전한 이전 버전과의 호환성. 시간이 지남에 따라 새 필드와 패널 유형이 추가되지만, 기존 필드와 동작은 변경되지 않습니다. 향후 호환성이 깨지는 변경 사항은 매우 신중하게 검토되며, 새로운 주요 스택 버전에서만 도입됩니다.

• 프로덕션 준비 및 완전한 지원. API에는 Elastic의 완전한 지원 보증이 적용됩니다. 자동화된 배포, 환경 승격 및 프로그래밍 방식의 대시보드 관리에 이 API를 프로덕션 환경에서 안심하고 사용할 수 있습니다.

태그, Markdown 및 Links 패널을 위한 새로운 Kibana API 엔드포인트

Elastic 9.5에서는 대시보드를 분류하고 필터링할 수 있는 태그용 새로운 독립형 엔드포인트도 도입합니다. 이제 전용 CRUD 엔드포인트를 통해 태그를 프로그래밍 방식으로 관리할 수 있어, 여러 환경에서 대규모로 대시보드를 더 쉽게 구성할 수 있습니다.

새로운 Markdown 및 Links 패널 엔드포인트는 현재 Serverless에서 제공되며, 다음 스택 릴리스인 9.6에 추가될 예정입니다.

Kibana Dashboards API는 어떤 패널 유형을 지원하나요?

Dashboards API는 9.5의 모든 by-value 패널을 지원합니다. by-value 패널은 재사용을 위해 저장된 라이브러리 패널과 달리 대시보드에 직접 정의된 패널입니다. 지원되는 모든 패널 유형에는 타입이 지정되고 검증된 스키마가 있습니다.

패널 유형

상태

XY 차트

지원됨

메트릭

지원됨

파이

지원됨

게이지

지원됨

히트맵

지원됨

데이터 테이블

지원됨

트리맵

지원됨

Discover 세션

지원됨

컨트롤

지원됨

Markdown

지원됨

Links

지원됨

ML 패널

지원됨

Observability 패널

지원됨

Maps

출시 예정

Vega

출시 예정

Kibana 대시보드를 코드로 관리하는 방법

Dashboards API를 사용하면 코드 기반의 대시보드를 위한 전체 워크플로우를 구현할 수 있습니다. 대시보드를 차이 비교가 가능한 깔끔한 JSON으로 내보내고, 이를 단일 정보 원천으로 Git에 커밋하며, 풀 리퀘스트에서 변경 사항을 검토하고, 개발·스테이징·프로덕션 전반에 동일한 정의를 배포할 수 있습니다. 대시보드를 코드로 관리하기 시작했다면 Git을 단일 정보 원천으로 취급해야 합니다. UI에서 직접 변경한 내용은 다음 배포 시 덮어써집니다.

대시보드를 스페이스, 클러스터 또는 단계 간에 이동할 때 가장 큰 과제는 대시보드가 데이터 뷰와 라이브러리 시각화 같은 객체를 ID로 참조한다는 점입니다. 이러한 ID는 자동 생성되며 환경마다 다르므로, 한 환경에서 내보낸 대시보드가 다른 환경에는 존재하지 않는 객체를 가리킬 수 있습니다. 이를 처리하는 방법은 자동화 수준이 높은 순서부터 낮은 순서까지 다음 세 가지입니다.

• Terraform 사용. Elastic Stack Terraform provider는 각 리소스를 추적하고 환경별 ID를 자동으로 매핑하므로, 대시보드를 개발 환경에서 프로덕션으로 승격할 때 참조가 일관되게 유지됩니다.

• by-value Elasticsearch Query Language (ES|QL) 패널 정의. 가장 이식성이 높은 패널 생성 방법은 대시보드에서 ES|QL을 직접 사용해 시각화를 정의하는 것입니다. ES|QL 쿼리는 쿼리 내에 지정한 인덱스에서 읽어 오므로, 패널에는 데이터 뷰나 라이브러리 객체에 대한 외부 참조가 없습니다. 그 결과 완전히 독립적이고 이식 가능한 대시보드가 만들어집니다..

• 일치하는 ID 할당. 데이터 뷰나 라이브러리 시각화와 같은 저장된 객체를 참조하는 경우, ID를 자동 생성하는 POST 대신 PUT(업서트)을 사용하여 선택한 ID로 객체를 생성하세요. logs-prod와 같이 사람이 읽을 수 있는 ID를 사용하면 여러 환경에서 쉽게 재사용하고 식별할 수 있습니다.

이러한 이식성 패턴과 코드 기반의 대시보드를 위한 전체 워크플로우에 관한 자세한 안내는 코드 기반의 대시보드 관리 설명서를 참조하세요.

PUT을 사용하여 Dashboards API로 Kibana 대시보드 생성

다음은 POST 대신 PUT을 사용해 대시보드 이름인 service-health-overview를 사용자 지정 ID로 할당하고, 메트릭 패널을 포함한 대시보드를 생성하는 간단한 예입니다. 동일한 로직은 라이브러리에 저장되는 독립형 시각화를 만들 때도 적용됩니다.

Kibana Dashboards API 로드맵: Maps, Vega 및 독립형 엔드포인트

Elastic은 API 기능 범위를 활발히 확장하고 있습니다. 다음으로는 Maps 및 Vega 패널 지원을 추가하고, 이들 패널의 타입이 지정된 스키마를 제공합니다. 또한 기존 대시보드 패널 지원 범위를 넘어 Discover 세션용 독립형 CRUD 엔드포인트와 Vega, Maps 및 Annotations용 독립형 CRUD 엔드포인트도 구축하고 있습니다. 이 엔드포인트는 대시보드 수명 주기와 분리됩니다.

전체 스키마 정의는 Dashboards API 설명서에서 확인하세요. Terraform 사용자는 Elastic Stack Terraform provider를 통해 정식 출시된 Dashboards API를 사용할 수 있습니다.

참고

1. 핵심 엔드포인트는 기술 미리보기와 비교해 변경되지 않았습니다. 9.4를 대상으로 통합을 구축했다면 9.5에서도 작동합니다. 호환성이 깨지는 변경 사항은 대시보드 목록 표시 및 기간 단위 형식에 영향을 주는 사소한 변경 두 가지뿐이며, 여기에서 설명합니다.

Kibana의 AI 대시보드 생성 기능, 무엇이 새로워졌을까요

기능

기술 미리보기(9.4)

정식 출시(9.5)

오류 처리

실패한 ES|QL 쿼리에 대한 재시도 없음

쿼리 검사 및 조정을 통해 최대 3회까지 자동 재시도

ES|QL 생성 비용

모든 쿼리가 기본 모델을 통해 라우팅됨

계층형 모델 라우팅, 최대 5분의 1 비용

기간 범위

고정된 기본 창

데이터 시간 분포에 기반한 자동 선택

필터 제어

지원되지 않음

가장 관련성 높은 필드에 대해 자동으로 추가됨

Vega-Lite 차트

지원되지 않음

산점도, 박스플롯, 조건부 서식, 맞춤형 툴팁을 포함한 자연어 기반 생성

차트 편집

지원되지 않음

자연어를 통해 기존 Vega-Lite 패널 편집

AI 대시보드 생성을 위한 자동 오류 복구

기술 미리보기 단계에서는 에이전트가 실패한 ES|QL 쿼리를 재시도하지 않았습니다. 9.5에서는 쿼리 오류를 감지하면 최대 3회까지 재시도하며, 포기하기 전에 각 오류를 검사하고 쿼리를 조정합니다. 실제로 이를 통해 대부분의 빈 패널 문제가 해결되며, 대시보드가 처음부터 제대로 렌더링됩니다.

Elastic 9.5에서 AI 대시보드 생성 비용이 더 저렴해진 이유는 무엇일까요?

대시보드 생성의 모든 단계가 동일한 수준의 추론을 필요로 하는 것은 아닙니다. 9.5에서는 ES|QL 생성이 기본적으로 더 가벼운 모델을 통해 처리되며, 필요한 경우에만 기본 모델로 대체됩니다. 사용 중인 커넥터가 Anthropic의 Claude Opus 4.8을 사용한다면, 모든 패널에 걸쳐 ES|QL 생성 비용이 5분의 1로 줄어든다는 의미입니다

데이터에 기반한 자동 기간 범위 선택

대시보드는 올바른 데이터 구간을 보여 줄 때만 유용합니다. 이제 에이전트는 사용자가 특정 기간 범위를 요청하지 않는 한, 쿼리하는 데이터에 적합한 기간 범위를 선택하기 위해 개선된 논리를 적용합니다. 고정된 창을 기본값으로 사용하는 대신, 데이터의 시간 분포를 고려해 그에 맞게 조정합니다. 실시간 인시던트라면 지난 1시간, 트렌드 분석이라면 지난 90일이 되는 식입니다.

AI 생성 대시보드의 자동 필터 제어

이제 대시보드 생성 기능이 제어, 즉 기본 쿼리를 수정하지 않고도 뷰어가 필드 값을 기준으로 대시보드를 좁혀볼 수 있는 대화형 필터를 지원합니다. 대시보드를 생성할 때 에이전트는 필터링하기에 가장 관련성 높은 필드에 대한 제어를 상단에 자동으로 추가합니다.

자연어로 만드는 Vega-Lite 차트: 기본 제공 범위를 넘어선 차트 유형과 서식

Vega와 Vega-Lite는 Kibana에서 다양한 차트 유형과 맞춤형 옵션을 지원합니다. 9.5부터는 직접 코드를 작성하지 않고도 일반 언어만으로 이를 만들 수 있습니다. 

산점도, 박스플롯 및 기타 다양한 Vega-Lite 차트 유형

산점도, 박스플롯 차트, 패싯 처리된 소형 다중 차트, 버블 차트, 그리고 (히스토그램과 히트맵을 결합하는 등의) 합성 차트를 비롯한 다양한 차트 유형이 Vega-Lite에서 지원됩니다. 예를 들어 응답 시간 대 요청 크기의 산점도를 서비스 이름별로 색상을 구분해서 보여줘와 같은 프롬프트를 입력하면, 올바른 데이터 매핑이 적용된 Vega-Lite 패널이 생성됩니다. 이때 차트는 Kibana의 기본 색상 팔레트를 사용해 대시보드의 나머지 요소와 자연스럽게 어우러집니다.

표준 차트에 조건부 서식, 맞춤형 툴팁, 레이블 적용

막대, 선, 영역 차트처럼 이미 대시보드에 기본으로 내장된 차트 유형이라 하더라도, 기본 기능만으로는 부족한 세밀한 제어가 필요할 때가 있습니다. 이럴 때 채팅을 통한 Vega-Lite가 그 부족한 부분을 채워 줍니다. 몇 가지 예는 다음과 같습니다.

• 조건부 색상 서식: 임계값을 초과하는 데이터 요소를 다른 색상으로 표시합니다. 예를 들어 특정 메트릭이 서비스 수준 목표(SLO)를 초과해 급증할 때, 선이나 막대의 데이터 요소를 빨간색으로 바꾸는 식입니다. 에이전트에게 내 라인 차트에서 500ms를 초과하는 포인트는 모두 빨간색으로 바꿔줘와 같이 요청해 보세요.

  

• 사용자 지정 표시 및 레이블: 데이터 포인트에 이모티콘, 기호 또는 텍스트 레이블을 추가하여 한눈에 상태를 파악할 수 있습니다.

  

• 맞춤형 툴팁: 차트의 축에는 포함되지 않는 추가 메트릭, 맥락 정보, 계산된 값 등으로 마우스 오버 시 표시되는 정보를 더욱 풍부하게 만듭니다. 각 막대의 전체 레코드 수와 비율(%)을 보여 주는 툴팁을 추가해줘와 같이 요청해 보세요.

  

이 기능은 기존 Vega 차트를 편집할 때도 동일하게 작동합니다. 색상 스케일 변경, 축 조정, 마크 유형 전환처럼 Vega-Lite 패널에 손질이 필요할 때, JSON 코드를 직접 파고들 필요 없이 채팅에서 원하는 변경 사항을 설명하기만 하면 됩니다.

Kibana에서 자연어 기반 Vega-Lite 생성 기능을 구축한 방법

문장 하나로 Vega-Lite 차트를 생성하는 것은 모델에게 JSON을 달라고 한 번에 요청하는 단순한 프롬프트 작업이 아닙니다. 저희는 자연어로 표현된 의도를 검증되고 데이터에 기반한 차트로 전환하는 소규모 에이전틱 파이프라인을 구축했습니다.

요청이 들어오면 에이전트는 먼저 Vega-Lite가 적합한지 판단합니다. Vega-Lite 요청인 경우, Elasticsearch에 대한 실제 ES|QL 쿼리를 바탕으로 시각화를 구성한 다음, 모델을 사용해 Vega-Lite 코드를 생성합니다. 렌더링 전에 결과는 정규화 계층을 거치며, 여기서 스키마를 수정하고 표준 쿼리를 연결합니다. 또한 렌더링 안전성을 위한 변환도 적용합니다.

몇 가지 설계 선택이 이 워크플로우의 신뢰성을 뒷받침합니다.

• 유형이 지정된 도구 호출: 차트 생성은 대화창에 자유 형식의 Vega-Lite 코드를 붙여넣는 방식이 아니라, 구조화된 도구 호출로 이루어집니다.

• 제약된 생성: 모델은 정의된 스키마 내에서 Vega-Lite 코드를 생성하므로, 출력 결과가 더 예측 가능하고 검증하기 쉬워집니다.

• 엄선된 예시: 패싯 처리, 레이어드 마크, 히트맵과 같은 구조적 패턴이 기본 데이터를 그대로 복사하지 않으면서도 지침을 제공합니다.

• 실행 및 검증 루프: 쿼리는 차트 작성 전에 실행되며, 검증에 실패하면 ES|QL 생성을 위한 수정 재시도가 트리거됩니다.

Kibana에서 AI 대시보드 생성과 Vega-Lite 차트 사용해 보기

자연어 기반 대시보드 생성과 Vega-Lite 차트를 사용해 보려면, Elastic 9.5로 업그레이드하거나(또는 무료 체험 시작하기), Kibana에서 채팅을 열어 보세요. 그런 다음 여러분의 데이터로 대시보드를 만들어달라고 요청해 보세요. Vega-Lite의 경우, 산점도나 버블 차트와 같이 평소 만들어보고 싶었지만 시도하지 못했던 차트 유형을 요청해 보세요. 결과가 원하는 대로 나오지 않으면, 에이전트에게 무엇을 바꿔야 할지 알려주세요. 에이전트가 여러분과 함께 반복하며 수정해 나갑니다.

이 경우 엔터프라이즈 라이선스가 필요합니다. 시작해 보세요.

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

이 에이전트는 대시보드를 처음부터 구축할 뿐만 아니라 기존에 이미 보유한 대시보드와도 함께 작동합니다. 대시보드를 보고 있는 상태에서 AI Chat 사이드바를 열면 자동으로 첨부됩니다. 메트릭이 급증한 이유를 묻거나, 리전별로 분석하거나, 비교 패널을 추가할 수 있습니다. 기존 대시보드는 최종 결과물이 아니라 출발점이 됩니다.

내부 구현 방식: AI Chat로 대시보드를 구축한 방법

우리는 스킬을 통해 에이전트에게 특정 작업을 가르칩니다. 스킬은 주어진 문제를 어떻게 처리할지에 대한 구조화된 설명입니다. 하지만 대시보드 스킬을 구축하려면 LLM이 유효한 Kibana 대시보드를 생성할 수 있도록 해야 했고, 기존의 Saved Object API는 이를 매우 번거롭게 만들었습니다. 깊게 중첩된 JSON 구조, 버전 간 미묘한 변경 사항, 취약한 참조 관계 등이 문제였습니다. 우리는 다른 접근 방식이 필요했습니다.

프로그램 기반 대시보드를 위한 맞춤형 API

새로운 Dashboards API는 바로 이러한 시나리오를 위해 설계되었습니다. 원시 내부 상태를 노출하는 대신, 모든 패널 유형에 대해 타입이 지정되고 검증된 스키마를 제공합니다. 이 API는 깔끔한 외부 구조와 Kibana 내부 표현 간의 변환을 처리하므로, 에이전트는 대시보드에 무엇을 포함해야 하는지에만 집중하고 형식을 어떻게 구성할지는 신경 쓰지 않아도 됩니다.

하나의 스킬, 하나의 도구, 다양한 작업

dashboard-management 스킬은 순서가 지정된 작업 배열을 허용하는 단일 manage_dashboard 도구를 제공합니다. 각 작업은 독립적인 동작으로, 메타데이터 설정, 마크다운 패널 추가, 자연어를 기반으로 ES|QL 기반 시각화 생성, 기존 패널 편집, 패널을 접을 수 있는 섹션으로 그룹화, 그리드에서 항목 위치 변경 등이 포함됩니다.

에이전트는 대시보드의 제목, 설명, 섹션, 그리고 각 섹션에 포함된 모든 패널까지 한 번의 호출로 설명할 수 있습니다.

작업은 순서대로 실행되므로 이후 단계에서 이전 단계를 참조하고 이를 기반으로 확장할 수 있습니다. 이 설계는 대화가 구현 세부 사항보다는 의도에 집중할 수 있도록 합니다.

시각화 파이프라인: 자연어에서 ES|QL을 거쳐 시각화로

대시보드를 요청하면 에이전트는 인덱스, 필드 매핑, 유형 등 데이터를 탐색한 다음 시각화를 계획하고 manage_dashboard를 호출합니다.

각 패널은 자체적인 파이프라인을 거치며, 차트 유형 선택, ES|QL 생성, 시각화 구성, 검증 단계로 처리됩니다. 우리는 이 과정을 메인 에이전트 스레드와 분리했는데, 시각화 생성에는 패널당 여러 모델 호출이 필요하고 이를 메인 컨텍스트에 포함하면 컨텍스트 윈도우가 불필요하게 커지고 추론이 흐려질 수 있기 때문입니다.

manage_dashboard 내부에서 모든 패널이 동시에 생성된 뒤 순서대로 재조립됩니다. 그 결과, 내장된 패널로 구성된 완전한 대시보드가 만들어지며, 고립된 시각화나 동기화 문제는 발생하지 않습니다.

대시보드 도구에 시각화 생성을 통합한 이유

초기 접근 방식에서는 별도의 create_visualization 도구를 사용해 패널당 한 번씩 호출한 뒤 각 결과를 대시보드 도구에 전달했습니다. 이 방식은 작동하기는 했지만, 모든 시각화마다 개별 도구 호출, 자체 수명 주기, 그리고 명시적인 핸드오프가 필요했습니다. 더 큰 문제는 대화에서 시각화를 수정해도 해당 변경 사항이 대시보드 패널에 반영되지 않아 사용자 혼란을 초래했다는 점입니다.

우리는 시각화 생성 기능을 manage_dashboard에 직접 포함시켰습니다. 동일한 병렬 워크플로는 그대로 실행되지만, 패널은 중간 attachment 없이 대시보드 구조로 조립됩니다. 호출 수 감소, 동기화 문제 없음, 단일 수명 주기로 작동합니다.

독립형 시각화는 여전히 작동합니다. 기존 차트를 첨부 참조를 통해 대시보드에 추가할 수 있지만, 처음부터 빌드하는 경우 인라인 생성이 더 깔끔한 방법입니다.

보안 팀을 위한 스킬

SOC 분석가와 탐지 엔지니어는 조사 도중 대시보드 편집기로 왔다 갔다 할 여유가 없습니다. AI Chat을 사용하면 규칙 유형, 호스트 또는 MITRE 전술별 알림 볼륨을 요청하고 약 1분 내에 스레드에서 바로 확인할 수 있습니다. 헌팅이 진행됨에 따라 프로세스 실행 이상, 네트워크 연결, 타임라인 비교와 같은 패널을 컨텍스트를 유지한 채 레이어처럼 쌓아갈 수 있습니다.

완료되면 저장하세요. 대시보드는 인시던트 이후 분석을 위한 참고 자료, 다음 분석가를 위한 시작점, 또는 주간 위협 브리핑으로 활용되며 별도의 재설명이 필요하지 않습니다.

이 블로그 게시물에서 보안 팀이 대시보드 생성 및 최근 출시된 AI Chat 기능을 어떻게 활용할 수 있는지 자세한 내용을 확인하세요.

통합 가시성 및 사이트 신뢰성 엔지니어(SRE) 사용 사례

새벽 2시에 서비스 장애가 발생하면 대시보드를 처음부터 다시 구축할 시간이 없습니다. AI Chat을 통해 SRE는 필요한 메트릭(서비스별 p99 지연 시간, 배포 이벤트 대비 오류율, 지난 1시간 동안의 포드 재시작 등)을 설명하고 약 1분 내에 조사 스레드에서 전체 대시보드를 얻을 수 있습니다. 상황이 점차 명확해짐에 따라 에이전트는 단계적으로 세밀하게 다듬을 수 있습니다. 패널을 추가하고, 시간 범위를 변경하고, 리전별로 분류할 수 있습니다.

대시보드를 저장하면 비상 상황실(war room)에서 인시던트 브릿지에 참여하는 모든 사람이 동일한 패널과 동일한 분석 구성을 즉시 활용할 수 있습니다. 인시던트 이후에는 사후 분석의 기반이 됩니다.

그럼 이제 무엇을 해야 할까요?

토큰 최적화, 더 풍부한 전체 화면 경험, 확장된 패널 지원, 그리고 지속적인 품질 개선을 진행 중입니다. 기술 프리뷰 단계는 우선순위를 함께 결정해 나가는 시기입니다. 누락된 부분이 있다면 상단 메뉴의 '피드백 제출' 아이콘을 통해 알려주세요.

직접 사용해 보기

체험판을 시작하거나 Elastic 9.4로 업그레이드한 후, 전체 화면 모드에서 AI Chat을 열고 실제 조사에 적용해 보세요. 에이전트에게 확인 중인 메트릭을 차트로 생성하도록 요청한 뒤, 다음 단계 분석을 요청하세요. 이야기가 완성되면 저장하고 공유하세요. 동일한 패널과 동일한 분석 구성을 그대로 활용할 수 있어 별도로 재설명이 필요하지 않습니다. 엔터프라이즈 라이선스가 필요합니다(시작하기). 이 게시물에서 설명된 모든 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

이것이 바로 우리가 읽기 전용 대시보드를 개발한 이유입니다. 여러분이 기다려온 바로 그 제어 기능입니다. 이제 편집 권한이 있는 다른 사용자가 대시보드를 수정하거나 손상시킬 걱정 없이 안심하고 공유하세요.

참고: 읽기 전용 권한은 Elastic Cloud Serverless에서 사용할 수 있으며 Elastic Cloud Hosted 및 Elastic 자체 관리형의 경우 버전 9.3부터 제공됩니다.

“모든 사람이 편집할 수 있을 때 방해가 되는 경우”

그동안 Kibana에서의 공유는 보통 스페이스 수준의 권한을 의미했습니다. 특정 스페이스에서 대시보드를 생성할 수 있는 사용자라면 다른 사용자의 대시보드 역시 편집하거나 삭제할 수 있었습니다. 이는 협업에는 유용하지만 예기치 못한 문제를 일으키기도 합니다. 단 한 번의 편집 실수가 잘못된 의사결정이나 신뢰 상실로 이어지고 막대한 복구 작업이 필요해질 수 있기 때문입니다.

그동안 "대시보드 이름에 '읽기 전용'이라고 적어두고 사용자들이 제발 알아봐 주기만을 바란다"는 식의 임시방편들을 많이 봐왔습니다. 혹은 "태그를 달아두고 아무 일 없기를 간절히 기도한다"는 분들도 계셨죠. 하지만 이러한 막연한 기대는 제대로 된 권한 관리 모델이 아닙니다. 여러분에게는 스페이스 접근 권한을 완전히 막지 않고도 대시보드만 확실하게 잠글 수 있는 실질적인 방법이 필요했습니다.

실제로 어떤 문제가 발생할까요?

데브와 케빈은 모두 운영 스페이스 내 로그 모니터링 대시보드에 대한 편집 권한을 가지고 있습니다. 케빈이 차트를 일부 변경합니다. 나중에 데브가 확인했을 때 대시보드의 숫자는 그녀가 제시했던 수치와 일치하지 않습니다. 결국 무엇이 변경되었는지(종종 기억에 의존하여) 일일이 추적하여 수정해야 하며 잘못된 데이터가 포함된 보고가 얼마나 많이 배포되었는지 우려하게 됩니다.

읽기 전용 대시보드: 합리적인 소유권과 제어

읽기 전용 대시보드는 다른 사용자의 편집 허용 여부를 직접 결정할 수 있는 제어 기능을 제공하여 이 문제를 해결합니다. 대시보드를 공유할 때 편집(기본 설정, 기존과 동일) 또는 보기 중 하나를 선택할 수 있습니다. 보기 모드에서는 작성자 본인과 Kibana 관리자만 대시보드를 수정하거나 삭제할 수 있습니다. 그 외 모든 사용자는 대시보드를 열어보고 활용하며 데이터를 신뢰할 수 있지만 임의로 수정할 수는 없습니다.

주요 혜택

• 대시보드 무결성: 보기 모드에서는 해당 스페이스의 편집 권한이 있는 다른 사용자라도 대시보드를 수정하거나 삭제할 수 없습니다. 만약 시도할 경우에는 대시보드가 잠겨 있다는 안내가 표시됩니다. 여러분의 차트와 로직은 그대로 유지됩니다.

• 주도권 유지: 여러분이 소유자입니다. 소유자는 언제든지 편집하고 세부 조정하거나 업데이트할 수 있습니다. 보기 전용으로 공유한다고 해서 소유자의 권한까지 제한되는 것은 아닙니다. 다만, 다른 사용자가 보게 되는 버전만 고정할 뿐입니다.

• 유연한 라이프사이클: 언제든지 대시보드를 "편집 가능" 상태로 전환할 수 있습니다. 또한 Kibana 관리자는(예: 소유자가 퇴사하는 경우) 모든 대시보드를 지속적으로 관리할 수 있습니다. 관리의 공백이 발생하지 않습니다.

이제 최종 확정된 핵심 업무용 대시보드를 안심하고 광범위하게 공유하며 데이터의 일관성을 유지할 수 있습니다. 이 기능은 Serverless를 포함한 모든 Elastic 티어 및 서비스 모델에서 사용할 수 있습니다.

권한별 기능 안내

역할별 권한 요약:

• 대시보드 소유자: 직접 생성한 대시보드이므로 소유자가 모든 편집 권한을 가집니다.

• Kibana 관리자: 모든 대시보드를 관리할 수 있습니다.

• 스페이스 편집 권한이 있는 사용자: 자신의 대시보드를 생성하고 편집할 수 있습니다. 보기 전용 대시보드는 편집하거나 삭제할 수 없습니다.

• 스페이스 보기 권한 사용자: 대시보드 목록 확인 및 조회만 가능합니다.

작업

대시보드 소유자

Kibana 관리자

스페이스 편집 권한 사용자

스페이스 보기 권한 사용자

대시보드 목록 및 보기

✔

✔

✔

✔

새 대시보드 생성

✔

✔

✔

✘

편집 가능한 대시보드 수정/삭제

✔

✔

✔

✘

읽기 전용 대시보드 수정/삭제

✔

✔

✘

✘

읽기 전용 모드 활성화 방법

새 대시보드를 저장할 때 또는 나중에 공유 메뉴에서 보기 전용으로 설정할 수 있습니다.

새 대시보드를 저장하는 경우

• 대시보드를 구성한 후 저장 버튼을 클릭합니다.

• "새 대시보드로 저장" 모달에서 권한을 찾습니다.

• 편집 가능 에서 보기 가능으로 변경합니다.

• 저장을 클릭하면 끝입니다. 이제 다른 모든 사용자에게는 읽기 전용으로 표시됩니다.

이미 소유하고 있는 대시보드의 경우

• 대시보드를 엽니다.

• 대시보드 공유 메뉴를 엽니다.

• 공유 모달에서 권한을 찾아 보기 가능으로 전환합니다. 변경 사항은 즉시 적용되며, 해당 스페이스의 다른 사용자는 더 이상 대시보드를 수정하거나 삭제할 수 없습니다.

• 공유 작업 위에 마우스를 올리면 해당 대시보드에 설정된 권한 유형을 바로 확인할 수 있습니다.

잠겨 있는 대시보드 식별

메인 대시보드 목록에서 편집이나 삭제가 불가능한 대시보드는 선택 체크박스가 비활성화되어 있습니다. 이를 통해 어떤 항목이 보기 전용인지 한눈에 쉽게 확인할 수 있습니다.

대시보드에서 편집 작업이 비활성화되며 해당 대시보드가 보기 전용으로 설정되었음을 안내하는 툴팁이 표시됩니다.

직접 사용해 보기

지금 바로 읽기 전용 대시보드를 이용해 보세요. 대시보드를 생성하고 보기 가능으로 설정한 뒤 공유하기만 하면 됩니다. 팀은 신뢰할 수 있는 단일 소스를 공유하게 되고 여러분은 안심할 수 있습니다. 이제 대시보드 제목에 "편집 금지"라고 적지 않아도 됩니다.

읽기 전용 대시보드를 어떻게 활용하고 계신지 여러분의 이야기가 궁금합니다. 커뮤니티 포럼에서 피드백을 공유하세요.

변수 제어란 무엇인가요?

이전에 Kibana 대시보드를 사용해 본 적이 있다면, 아마도 클래식 대시보드 제어를 알고 계실 것입니다. 데이터에서 값을 표시하여 몇 번의 클릭만으로 항목을 필터링할 수 있는 편리한 드롭다운입니다.

변수 제어는 겉보기에는 비슷해 보이지만, 독창적인 차별점이 있습니다. 대시보드의 모든 패널을 자동으로 필터링하는 대신, 개별 시각화 내의 ES|QL 쿼리에 직접 연결할 수 있습니다.

즉, 사용자가 각 제어가 적용되는 위치를 결정할 수 있습니다. 더욱 좋은 점은, 시간 간격 조정, 분석 필드 전환, 시각화 매개변수 실시간 변경 등 다양한 창의적인 트릭에 활용할 수 있다는 것입니다. 기본적으로, 대시보드는 진정한 상호 작용 경험을 제공하여 인사이트를 더 빠르고 쉽게 얻을 수 있습니다.

변수 제어 사용 사례

좋습니다, 변수 제어는 유용한 것 같은데요. 그렇다면 실제로 무엇을 할 수 있을까요? 대시보드 수준을 높이는 몇 가지 예는 다음과 같습니다.

선택한 시각화 필터링

일부 시각화는 필터링하고 다른 시각화는 그대로 두고 싶으신가요? 변수 제어를 사용하면 바로 그렇게 할 수 있습니다. 응답할 패널을 선택하고 시각화의 기반이 되는 ES|QL 쿼리에 연결하세요.

다른 시간 간격을 선택하세요

사용자에게 '5분', '1시간', '1일' 등 원하는 시간 버킷으로 전환할 수 있는 권한을 부여합니다. 미리 정의된 간격으로 변수 제어를 작성하고 시계열 쿼리에 연결합니다.

함수 변경

각 작업에 대해 여러 차트를 생성하는 대신, 대시보드 사용자가 최대값, 평균값, 다양한 백분위수 또는 다른 집계기를 선택할 수 있도록 합니다.

다양한 필드로 그룹화

조사 중에는 데이터를 다양한 차원으로 세분화해야 할 때가 있습니다. 변수 제어를 통해 여러 '그룹별' 필드를 정의하고, 대시보드 사용자들이 자신만의 인사이트를 발견하는 데 가장 적합한 필드를 선택할 수 있게 할 수 있습니다.

어떻게 만들 수 있나요?

변수 제어를 만드는 가장 쉽게 (그리고 아마도 가장 즐겁게 만드는) 방법은 시각화의 ES|QL 쿼리 편집기에서 직접 만드는 것입니다. 쿼리를 입력하기 시작하고 자동 완성 메뉴를 사용하면 Kibana가 제어 구성을 훌륭히 도와줍니다.

하지만 변수 자체에서 시작하고 싶다면 패널 추가 → 제어 → 변수 제어 로 이동하여 제어를 만든 후 시각화에 변수를 추가할 수도 있습니다.

예제 1: 다중 값 선택 기능을 갖춘 필터링 제어

1. ES|QL 쿼리로 구동되는 시각화를 선택하고 WHERE 절에서 '제어 생성'을 클릭합니다.

2. 자동으로 변수 생성 플라이아웃으로 리디렉션되며, '쿼리에서 값 가져오기' 유형이 선택되고 변수 이름이 이미 입력되어 있습니다. 시각화 쿼리에서 작동하려면 컨트롤의 이름이 항상 '?...'로 시작해야 합니다.

대시보드에서 선택된 시간 범위에 따라 필드의 값을 가져오고 업데이트하려면 보통 이런 쿼리가 필요합니다.

3. 제어를 저장하면 대시보드 상단에 제어가 나타나고, 시각화 쿼리가 변수 제어 이름으로 업데이트됩니다.

4. 제어에 다중 값 선택을 추가하려면 쿼리에서 MV_CONTAINS 함수를 사용하고 2단계에서 제어 생성 시 '다중 선택 허용'을 선택해야 합니다(9.3부터 사용 가능).

예제 2: 시간 간격 제어

시계열을 구축하는 경우, 날짜 히스토그램 간격에 대한 변수 제어를 쉽게 추가할 수 있습니다.

1. 시계열에 대한 ES|QL 쿼리를 작성할 때 '제어 생성'을 클릭합니다. 간격 변수를 만들 때는 BUCKET 대신 TBUCKET 을(를) 사용하는 것이 좋습니다. '1시간', '1일'과 같은 더 읽기 쉬운 간격을 허용하기 때문입니다. TBUCKET 에 곧 자동 옵션이 추가되어 시간 범위에 자동으로 적응할 수 있게 됩니다.

2. 드롭다운 메뉴에서 옵션을 채울 간격을 정의합니다.

3. 드롭다운 메뉴에서 다른 간격을 선택하고 시각화가 어떻게 변하는지 확인합니다.

예제 3: 함수용 변수

1. '정적 값' 유형의 제어를 사용하여 변수를 생성하고 드롭다운 값에 함수 이름을 추가합니다. 함수를 대체하려면 '??...'로 시작하는 변수 이름을 사용하는 것이 중요합니다.

2. ES|QL 쿼리에 변수 이름을 포함합니다.

예제 4: 필드를 위한 변수

1. '정적 값' 유형의 제어를 사용하여 원하는 필드 이름을 작성할 수 있습니다. 필드에서 작동하려면 '??...'로 시작하는 변수 이름을 사용하는 것이 중요합니다.

2. 시각화 쿼리에서 원하는 위치에 변수를 참조합니다.

Discover의 변수 제어

변수 컨트롤은 단순한 대시보드 기능이 아닙니다. Discover의 ES|QL 편집기에서도 직접 사용할 수 있습니다. Discover에서 더 빠른 데이터 탐색 경험을 위한 제어를 생성하고, 이를 대시보드로 가져올 수 있으며, 그 반대로도 가능합니다.

기술적 세부 사항

이제 변수 제어에는 쿼리에서 참조할 수 있는 부분과 사용해야 하는 명명 접두사(값의 경우 "?...", 필드 또는 함수의 경우 "??...")와 같은 몇 가지 규칙이 있다는 것을 눈치채셨을 것입니다. 변수는 단순히 클라이언트 측에서 스트링 치환만 하는 것이 아니기 때문입니다. 실제로는 쿼리 언어 자체에서 1급 시민으로 처리됩니다(ES|QL에서 매개변수로 알려짐).

이 디자인은 몇 가지 큰 장점을 제공합니다. 첫째, Kibana는 각 변수의 맥락을 이해할 수 있어, 자동으로 구성 설정을 생성하고 미리 채울 수 있습니다. 또한 훨씬 더 안전합니다. 언어가 변수 입력의 유효성을 엄격하게 검사하여 악의적인 주입을 방지하고, 이상이 있을 경우 우아하게 오류를 처리합니다. 또한 복잡한 유효성 검사 및 오류 처리를 클라이언트가 아닌 서버로 전환하여 성능과 안정성을 향상합니다. 성능에 대한 참고 사항을 말씀드리자면, 빠른 쿼리는 대시보드보다 먼저 로드되기 대문에 쿼리가 느리면 전체 대시보드 성능에 영향을 미칠 수 있으므로 빠른 쿼리를 포함하는 변수를 작성하는 것이 가장 좋습니다.

물론, 이 아키텍처에는 현재로서 몇 가지 제약이 있습니다. 변수는 아직 필터링에 '모두' 옵션을 지원하지 않으며, 현재 LIKE또는 FROM (데이터 소스 전환용)과 같은 특정 연산자와 함께 사용할 수 없습니다. 좋은 소식은? 이러한 기능을 추가하기 위해 열심히 노력하고 있습니다.

제어의 미래가 가져올 변화

여기서 멈추지 않습니다! 주목하고 있는 개선 사항 일부는 다음과 같습니다.

✨ 대시보드 어디에나 컨트롤을 배치할 수 있는 기능

✨ 제어 체인 연결 - 한 제어의 출력이 다음 제어의 입력이 되는 것

✨ 변수에 대한 '모든' 선택과 같은 더 나은 선택 옵션

✨ 새로운 제어 유형(검색 유형 제어 및 데이터 소스용 변수)

✨ 그리고 많은 분들이 요청했던 삶의 질을 향상하는 추가 기능(예: 일반 제어 사전 필터링)

아이디어나 피드백이 있으시면 언제든지 알려주시기 바랍니다.