이 문서는 머신러닝 섹션의 일부입니다.
Serving UI 메트릭
Model Serving 엔드포인트 페이지에서 다음 메트릭을 실시간으로 확인할 수 있습니다.🆕 Endpoint Telemetry (Beta): OpenTelemetry 기반의 관찰 가능성 기능이 추가되었습니다. OTLP(OpenTelemetry Protocol)로 외부 모니터링 시스템(Datadog, Grafana 등)과 연동할 수 있습니다.
알림 설정 (Alerting)
모니터링 메트릭에 기반한 알림을 설정하여, 문제가 발생하면 즉시 대응할 수 있습니다.Databricks SQL Alert 활용
알림 채널 설정
대시보드 구축 (System 테이블 기반)
종합 모니터링 대시보드 쿼리
아래 쿼리들을 Databricks SQL 대시보드에 위젯으로 추가하면, 종합 모니터링 대시보드를 구축할 수 있습니다.멀티 엔드포인트 비교 대시보드
여러 엔드포인트를 동시에 비교하는 운영 대시보드용 쿼리입니다.모니터링 장단점과 트레이드오프
모니터링 체계를 설계할 때 비용과 가치 사이의 트레이드오프를 이해해야 합니다.모니터링 수준별 비교
💡 비용은 트래픽 규모, 데이터 크기, 클러스터 구성에 따라 크게 달라집니다. 실제 비용은 Databricks Cost Management에서 확인하십시오.
Inference Table: 전수 기록 vs 샘플링
Lakehouse Monitoring 설정 트레이드오프
베스트 프랙티스와 흔한 실수
베스트 프랙티스 (Best Practices)
1. 모니터링을 배포 전에 설계하세요 모델 배포 후 모니터링을 추가하면 초기 데이터가 유실됩니다. Inference Table은 엔드포인트 생성 시 함께 활성화하십시오.흔한 실수 (Common Mistakes)
실수 1: Inference Table을date 파티션 없이 쿼리
트러블슈팅 가이드
정리
모니터링 설계 원칙 요약:
- 배포 전 설계 — Inference Table은 엔드포인트 생성 시 활성화합니다
- Percentile 기반 SLA — P99를 기준으로 서비스 수준을 정의합니다
- 계층적 알림 — 긴급/경고/정보로 구분하여 알림 피로를 방지합니다
- 비용과 가치 균형 — 트래픽 규모에 맞는 샘플링 전략을 선택합니다
- Ground Truth 연동 — 가능하면 실제 레이블을 수집하여 성능을 검증합니다