Important
이 기능은 베타 버전으로 제공됩니다. 작업 영역 관리자는 미리 보기 페이지에서 이 기능에 대한 액세스를 제어할 수 있습니다. Azure Databricks 미리 보기 관리를 참조하세요.
프로젝트의 관측 가능성을 설정할 때, Lakebase는 텔레메트리 테이블 위에 이미 만들어진 Lakeview 대시보드를 만들어 직접 만들지 않아도 Postgres 활동의 풍부하고 상호작용적인 차트를 얻을 수 있습니다. 그들은 Insights와 Genie가 사용하는 것과 동일한 Delta 테이블을 Unity 카탈로그에서 읽습니다.
프로젝트의 모니터링 페이지에서 메트릭스 탭에서는 단일 컴퓨트(CPU, 메모리, 연결, 캐시 히트율)의 실시간 그래프가 제공되며, "지금 내 데이터베이스가 건강한가요?"에 대한 무설정 답변을 제공합니다. Advanced Postgres Telemetry 탭도 항상 존재하지만, 관측성을 설정할 때까지 비어 있습니다. 텔레메트리 데이터가 들어오기 시작하면 이러한 각 대시보드로 연결되는 카드가 표시됩니다. 텔레메트리를 델타 테이블에 전송하기 때문에 재시작 후에도 지속되며, 메트릭이 답하지 못하는 질문들에 답합니다: 어떤 쿼리가 느리는지, 계획이 변경되었는지, 두 시간 간격 간 차이가 무엇인지 등.
사전 요구 사항
- 관측 가능성이 설정되어 있고 실행 중인 컴퓨트가 있는 Lakebase 프로젝트입니다.
- 대시보드는 구성이 텔레메트리를 처음 작성할 때 생성되므로, 관측 가능성을 처음 설정한 후 몇 분간 기다려 보세요. 표와 마찬가지로, 텔레메트리 데이터가 적어도 한 번 수집되기 전까지는 표시되지 않습니다.
대시보드 열기
Advanced Postgres Telemetry 탭에서 프로젝트 대시보드를 열어보세요:
- 프로젝트를 열고 모니터링으로 가세요.
- Advanced Postgres Telemetry 탭을 선택하세요. 여기에는 프로젝트의 observability 구성이 생성한 각 대시보드에 대한 카드가 표시됩니다.
- 카드를 클릭해 Databricks SQL의 새 탭에서 대시보드를 열어보세요. 대시보드는 브랜치의 기본 엔드포인트(읽기/쓰기) 엔드포인트로 필터링되어 열립니다.
탭에 카드 대신 빈 상태가 표시된다면, 두 가지 중 하나가 빠진 것입니다:
- 설정은 할당되지 않았 으며, 프로젝트에는 아직 고급 텔레메트리가 설정되어 있지 않습니다. 먼저 프로젝트 설정에서 관측성 구성을 할당하거나 생성하세요. 자세한 내용은 '관측성 구성'을 참조하세요.
- 아직 대시보드는 없습니다 — 설정은 할당되었지만 대시보드는 아직 생성되지 않았습니다. 텔레메트리가 처음 플로우된 직후, 구성이 이들을 제공하면 나타납니다.
Note
대시보드를 직접 열 수도 있습니다. 작업 공간에서 대시보드 로 가서 Lakebase Overview 또는 Lakebase Time Interval Comparison을 검색하세요. 대시보드는 작업 공간 내 일반 Lakeview 대시보드이기 때문에(자세한 내용은 '대시보드는 당신의 것' 참조), 다른 곳과 마찬가지로 검색이 가능합니다.
기본 대시보드
각 관측 가능성 구성마다 두 개의 대시보드가 생성됩니다. 각 대시보드에는 뷰를 탐색하는 필터가 있어, 관심 있는 시간대와 계산 범위로 좁힐 수 있습니다. 아래에 설명된 두 대시보드마다 필터와 위치가 다릅니다.
호수 기지 개요
하나 이상의 엔드포인트에 대해 일정 기간 동안 프로젝트의 건강 상태와 성과를 폭넓게 파악하는 시각입니다. 세 페이지 정도입니다.
개요 페이지는 계산, 연결, 쿼리, 대기 기능을 한눈에 다룹니다:
| Graph | 표시되는 내용 | 읽는 내용 |
|---|---|---|
| CPU 및 RAM 시간 경과에 따른 변화 | 선택한 창 전체에서 CPU와 메모리 사용량을 계산합니다. | compute_gauges |
| CPU 사용 중인 코어 사용 시간 변화 | 시간 경과에 따른 사용 중인 코어 수 CPU 사용량이 할당된 CPU 수준에 가까운 상태로 지속되면 해당 컴퓨팅 작업은 CPU 바운드 상태임을 나타냅니다. | compute_counters |
| 시간 경과에 따른 디스크 I/O(MB/s) | 시간에 따른 디스크 읽기/쓰기 처리량. | compute_counters |
| 시간 경과에 따른 네트워크 I/O(MB/s) | 네트워크 처리량이 시간에 따라 변합니다. | compute_counters |
| 엔드포인트별 연결 | 엔드포인트별 시간에 따른 연결 수 | active_session_history |
| 시간에 따른 활성 세션 | 시간에 따라 동시 활성 세션을 진행하세요. | active_session_history |
| 시간에 따른 쿼리 실행 볼륨 | 시간 동안 몇 개의 쿼리가 실행되었는지. | pg_stat_statements_counters |
| 평균 쿼리 실행 시간 (ms) | 시간에 따른 평균 쿼리 지연. | pg_stat_statements_counters |
| 통화 횟수 기준 상위 20개 쿼리 | 창에서 가장 자주 실행되는 쿼리들. | pg_stat_statements_counters |
| 상위 10개 쿼리: 시간 경과에 따른 총 실행 시간 | 가장 많은 총 실행 시간을 소모하는 쿼리가 윈도우 전체에 걸쳐 추적됩니다. | pg_stat_statements_counters |
| 상위 10개 쿼리: 평균 실행 시간 변화율(평균 대비) | 평균 지연 시간이 자신의 평균에서 가장 크게 벗어난 쿼리, 즉 표면 회귀 분석에 이르는 쿼리들입니다. | pg_stat_statements_counters |
| 시간에 따른 클래스별 대기 시간 | 시간 경과에 따른 대기 클래스(잠금, I/O 및 기타)별 대기 시간입니다. 어떤 클래스가 지배적인지를 가리키며 쿼리가 차단되는 지점을 나타냅니다. | wait_event_counters |
| 가장 느린 쿼리 25개 (플랜 이력) | 계획 역사상 가장 느린 개별 집행 기록입니다. | plan_history |
| 엔드포인트별 LFC 메모리 개요 | 엔드포인트별 로컬 파일 캐시 메모리 사용량은 작업 집합 크기를 나타내는 지표입니다. | compute_gauges |
쿼리 분석 페이지에서는 페이지의 쿼리 ID 필터로 선택한 단일 쿼리를 자세히 살펴봅니다:
| Graph | 표시되는 내용 | 읽는 내용 |
|---|---|---|
| 시간 경과에 따른 쿼리 호출 수 및 평균 실행 시간 | 선택한 쿼리의 통화량과 평균 지연 시간도 시간에 따른 것입니다. | pg_stat_statements_counters |
| 계획 해시당 실행 시간 | 실행 시간을 계획 해시로 표시하여, 쿼리의 계획이 언제 변경되었고 각 계획이 어떻게 작동하는지 확인할 수 있습니다. 여기서 갑작스러운 성능 저하는 종종 더 느린 새 플랜 해시로 나타납니다. | plan_history |
| 쿼리 지속 시간 통계 | 선택한 쿼리의 실행 기간을 통계합니다. | plan_history |
| 시간에 따른 평균 입출력 통계 | 시간에 따른 선택한 쿼리의 평균 I/O | plan_history |
| 가장 긴 사형 집행 5대 | 선택한 쿼리의 가장 느린 다섯 개 개별 실행. | plan_history |
글로벌 필터 페이지에는 다른 페이지마다 범위를 확장하는 컨트롤인 Date Range, Endpoint, Include Postgres 데이터베이스가 있습니다.
호수 기지 시간 간격 비교
엔드포인트의 활동을 두 가지 시간 구간 ('전'과 '후')과 표면적 변화 및 회귀(예: 배포 후, 트래픽 급증 후)에 걸쳐 비교합니다. 날짜 범위 선택기로 A와B 기간 을 설정하고 끝점을 선택한 후 두 기간을 나란히 읽습니다:
| Graph | 표시되는 내용 | 읽는 내용 |
|---|---|---|
| 주요 대기 이벤트 — A / B 단계 | 각 기간의 주요 대기 이벤트를 나란히 배치된 막대로 표시합니다. | wait_event_counters |
| 시간 경과에 따른 대기 이벤트 — 기간 A / 기간 B | 각 기간 내에서 대기 이벤트의 추세는 어떤가요. | wait_event_counters |
| 대기 이벤트 비교표 | 두 기간의 대기 이벤트를 하나의 테이블에 표시하여 차이가 두드러지도록 하세요. | wait_event_counters |
| 쿼리 비교 표 | 두 기간의 쿼리 통계를 나란히 비교하여 어떤 쿼리가 느려졌거나 더 복잡해졌는지 파악하세요. | pg_stat_statements_counters |
이 표의 각 열이 의미하는 바는 텔레메트리 표 참고 항목을 참조하세요.
대시보드 공유
대시보드는 본인이 소유한 초안으로 만들어져서 바로 열고 사용할 수 있습니다.
대시보드를 다른 사용자와 공유하고 싶으면 게시하세요. 게시할 때, 해당 시청자들을 위해 쿼리가 어떻게 진행될지 선택할 수 있습니다:
- 임베디드 자격 증명 — 쿼리는 퍼블리셔로 실행되고, 대시보드 수준에서 접근 권한을 관리합니다. 이게 더 간단한 선택입니다.
- 뷰어 자격 증명 — 쿼리는 각 뷰어별로 실행되므로, 기본 텔레메트리 테이블에 대한 권한을 부여합니다. 이 방법은 더 많은 작업이 필요하지만, 다른 사람들이 같은 데이터에 대해 자신만의 맞춤형 쿼리를 실행할 수 있게 해줍니다.
대시보드를 맞춤화하고 확장하세요
대시보드는 여러분이 변경할 수 있습니다. 각 대시보드는 일반 Lakeview 대시보드이기 때문에, 다른 대시보드처럼 편집할 수 있습니다: 그래프 제목 변경, 시각화 변경, 기본 필터 조정, 또는 동일한 텔레메트리 테이블(또는 Unity 카탈로그 내 다른 데이터와 결합)으로 지원하는 자체 그래프와 페이지를 추가할 수 있습니다. Lakeview 대시보드 편집 방법은 대시보드를 참조하세요.
원본을 그대로 유지하고 싶다면, 먼저 대시보드를 복제하고 복사본을 커스터마이즈하세요.
완전히 새로운 뷰를 구축하려면 Azure Databricks SQL 도구로 텔레메트리 테이블에 대해 직접 쿼리를 작성하세요. 데이터는 여러분의 Unity 카탈로그에 있는 표준 Delta 데이터입니다.
대시보드는 당신 것입니다
대시보드와 텔레메트리 테이블은 사용자 소유입니다. Lakebase가 생성하지만, 그 구성은 당신 소유이며, 구성을 제거해도 사라지지 않습니다:
- 관측 가능성을 삭제한다고 해서 그 설정들이 삭제되지 않습니다. 설정을 삭제하거나 재할당해도 대시보드와 텔레메트리 테이블은 그대로 유지됩니다. 대시보드에 편집한 모든 내용은 보존됩니다. 더 이상 원하지 않는다면 직접 제거하세요.
- 구성이 어디에 기록하는지 (카탈로그, 스키마, 테이블 프리픽스)를 변경하면 기존 대시보드는 그대로 두고 새로운 목적지를 향한 새 대시보드가 생성됩니다. 이전 대시보드는 독립적인 콘텐츠로 남아 있습니다.
이들은 사용자 고유의 Unity Catalog에 있는 표준 Lakeview 대시보드와 Delta 테이블이기 때문에, 별도의 옵저버빌리티 제품 안에 묶여 있지 않고 사용자가 소유한 다른 콘텐츠와 마찬가지로 작동합니다.
다음 단계
- 레이크하우스로 텔레메트리를 캡처하세요 — 이 대시보드를 만드는 관측 가능성 구성을 설정하세요.
- 텔레메트리 테이블 참조 — 그래프가 데이터를 읽어 오는 모든 테이블과 열.
- Insights로 문제를 찾아내고 해결하세요 — 배경 상담원이 동일한 텔레메트리에서 문제를 찾아내도록 하세요.
- Genie 관련 문제를 진단하고 해결 합니다. 대화형으로 문제를 조사합니다.