4-5. Grafana 대시보드 확인¶
Grafana 대시보드 Demo는 운영 품질 신호를 한 화면에서 어떻게 묶어 볼지 확인하는 과정입니다. 대시보드는 결론을 내려 주는 화면이 아니라, 어떤 메트릭(metric)과 로그(log)를 더 확인해야 하는지 알려 주는 출발점입니다.
이 문서를 읽을 때는 다음 기준을 중심으로 확인합니다.
- 대시보드 구조: 현재값 요약, 시간 흐름, 기준선 대비 현재 분포, 검증 실패 로그, trace 패널 확인
- 조합 해석: 오류(error), 지연 시간(latency), 점수(score), 예측(prediction)을 따로 보지 않고 함께 확인
- 후속 확인: 패널에서 이상 신호를 발견하면 로그와 설정값으로 내려가는 흐름 확인
4-5-1. 대시보드(dashboard) 구조 이해¶
대시보드는 운영 품질 신호를 “한눈에 보는 화면”으로 묶습니다. 하지만 한눈에 본다는 것은 결론을 자동으로 얻는다는 뜻이 아닙니다. 패널(panel)은 이상 후보를 보여주고, QA는 그 패널이 어떤 쿼리(query)와 로그 필드(field)에 연결되는지 확인해야 합니다.
Grafana Cloud Demo 자료는 demos/ch04_grafana_cloud에 있습니다. Demo 실행은 대시보드 JSON(dashboard JSON)과 페이로드 미리보기(payload preview)를 생성합니다. 이 Demo의 필수 경로는 로컬 artifact 확인입니다. Grafana Cloud import는 개인 계정, 네트워크, datasource 권한이 있을 때만 선택적으로 수행합니다.
uv run python demos/ch04_grafana_cloud/run_demo.py
생성되는 대시보드는 2개이며, Cloud import를 실행하면 Grafana의 AI Quality folder 아래에 들어갑니다. AI Quality Overview는 artifacts/grafana/ai_quality_overview_dashboard.json에 있고, 운영 품질 신호가 기준선과 달라졌는지 먼저 보는 화면입니다. AI Quality Details는 artifacts/grafana/ai_quality_details_dashboard.json에 있고, Overview에서 발견한 이상 신호를 로그와 trace로 확인하는 화면입니다. 두 화면으로 나누는 이유는 수강생이 처음 보는 화면에서 모든 후보를 동시에 펼치기보다, 먼저 판단 질문을 보고 그다음 근거를 확인하게 만들기 위해서입니다.
| Dashboard | 패널 | 쿼리 또는 조건 | 확인 목적 |
|---|---|---|---|
| AI Quality Overview | Request Count | ai_quality_request_total |
트래픽(traffic) 규모 확인 |
| AI Quality Overview | Error Count | ai_quality_error_total |
API 오류 증가 확인 |
| AI Quality Overview | Average Latency | ai_quality_latency_average_ms |
응답 지연 확인 |
| AI Quality Overview | High Risk Rate | ai_quality_high_risk_rate |
예측 분포(prediction distribution) 변화 확인 |
| AI Quality Overview | Service Reliability Trend | ai_quality_error_total, ai_quality_validation_failure_total |
오류와 검증 실패가 함께 움직이는지 확인 |
| AI Quality Overview | Score and Prediction Trend | ai_quality_score_average, ai_quality_valid_score_average, ai_quality_high_risk_rate, ai_quality_valid_high_risk_rate |
점수와 예측 분포 이동을 한 번에 확인 |
| AI Quality Overview | Prediction Distribution | ai_quality_prediction_count |
class별 예측 건수와 전체/유효 요청 차이 확인 |
| AI Quality Overview | Score Bucket Distribution | ai_quality_score_bucket_count |
score bucket별 건수와 전체/유효 요청 차이 확인 |
| AI Quality Overview | Input Drift Delta Trend | ai_quality_input_mean_delta |
입력 평균 변화 후보의 시간 흐름 확인 |
| AI Quality Overview | Heart Rate Distribution: Reference vs Current | ai_quality_input_histogram_count{feature="heart_rate"} |
기준선과 현재 입력 bucket 비교 |
| AI Quality Overview | Oxygen Saturation Distribution: Reference vs Current | ai_quality_input_histogram_count{feature="oxygen_saturation"} |
기준선과 현재 입력 bucket 비교 |
| AI Quality Details | Validation Failures | validation_failure="true" |
입력 검증 실패 로그 확인 |
| AI Quality Details | Trace Search by course_trace_id | { .course_trace_id = "$course_trace_id" } |
Tempo에서 대표 요청 trace 검색 |
| AI Quality Details | Correlated Logs by trace_id | trace_id="$course_trace_id" |
같은 요청 흐름의 Loki 로그 확인 |
| AI Quality Details | Representative Request Trace | $tempo_trace_id |
대표 요청의 trace waterfall 확인 |
| AI Quality Details | Service Topology Map | traces_service_graph_request_server_seconds_count |
client/server 관계를 node graph로 확인 |
| AI Quality Details | Service Graph Connectivity | traces_service_graph_request_server_seconds_count |
topology map에 들어갈 edge metric 생성 여부 확인 |
| AI Quality Details | Service Graph Latency p90 | traces_service_graph_request_server_seconds_bucket |
service edge별 지연 시간 추세 확인 |
대시보드는 결론을 주는 화면이 아니라 질문을 시작하게 하는 화면입니다. 패널에서 이상 신호를 발견하면 메트릭과 로그로 내려가 원인을 확인해야 합니다. 대시보드만 보고 “모델 자체 문제”라고 단정하면 안 됩니다.
Grafana dashboard best practices는 dashboard가 하나의 질문에 답하고 인지 부하를 줄여야 한다고 설명합니다. 이 기준에 맞춰 Average Score, Valid Average Score, Valid High Risk Rate 같은 세부 stat 패널은 별도 패널로 두지 않고 Score and Prediction Trend 안에 묶었습니다. Grafana Time series 문서는 시간에 따라 값이 어떻게 변하는지 보기 위한 기본 시각화를 설명합니다. Grafana Bar chart 문서는 범주별 값을 비교할 때 bar chart를 사용할 수 있음을 설명합니다. 이 Demo는 초보자가 먼저 분포 이동을 읽을 수 있도록 score bucket과 입력 feature의 Reference vs Current 분포 비교를 함께 사용하고, 실무 histogram 설계는 확장 항목으로 둡니다.
Evidently의 data drift 설명은 data drift를 모델 입력 feature 분포 변화로 보고, label이 늦게 들어오는 운영 환경에서는 입력 분포와 모델 출력 분포를 proxy signal로 사용할 수 있다고 설명합니다. 따라서 이 dashboard는 drift를 확정하는 화면이 아니라 “입력 분포 변화와 예측 분포 변화가 함께 보이는가”를 확인하는 초기 조사 화면입니다. Evidently의 data drift와 prediction drift 해석 글은 두 신호를 문맥 없이 단독으로 해석하지 말고 함께 봐야 한다고 설명합니다. 그래서 Overview는 입력 분포와 score/prediction 분포를 한 화면에 두고, Details는 로그와 trace로 실제 요청 근거를 확인하게 구성합니다.
Grafana의 분포 패널은 운영 신호 확인용이지 Evidently식 KDE(density) 리포트의 대체물이 아닙니다. Grafana Histogram 문서는 histogram을 bucket별 count를 bar로 보여주는 시각화로 설명하고, 여러 series는 나란히 보거나 쌓아서 볼 수 있다고 설명합니다. 반면 KDE나 부드러운 density curve는 원시 값 또는 별도로 계산된 x/y density 데이터가 필요합니다. Grafana XY chart 문서는 임의의 numeric x/y 값을 선이나 점으로 그릴 수 있지만, Grafana가 Prometheus bucket count에서 KDE를 자동 계산해 주지는 않습니다.
따라서 이 과정에서는 역할을 분리합니다. Grafana dashboard는 운영 중 계속 들어오는 metric을 빠르게 보는 화면이고, 정교한 분포 비교 그림은 5장 drift_report.md 같은 보고서 artifact에서 보완합니다. 수강생은 Grafana의 bar chart를 보고 “어떤 bucket이 움직였는가”를 확인하고, KDE/density 형태의 부드러운 분포 비교가 필요하면 raw data 기반 분석 리포트에서 확인해야 합니다.
| 표현 방식 | 이 과정의 위치 | 장점 | 한계 |
|---|---|---|---|
| Grafana grouped bar | 4장 dashboard | 운영 metric을 계속 갱신해 확인 가능 | KDE처럼 부드러운 곡선은 아님 |
| Grafana histogram | 확장 확인 | raw numeric value가 있으면 분포를 빠르게 볼 수 있음 | Prometheus bucket count 기반 reference/current overlay에는 제한 |
| XY chart 또는 plugin | 확장 확인 | 미리 계산한 density x/y를 선으로 표시 가능 | KDE 계산 로직과 별도 데이터 생성 필요 |
| Drift report artifact | 5장 보고서 | raw data 기반 histogram, KDE, 표를 함께 제공 가능 | 실시간 dashboard가 아니라 분석 산출물 |
이번 Demo의 이상 상태(anomaly) 메트릭은 아래처럼 읽을 수 있습니다.
| 패널 | 예시 값 | 다음 확인 |
|---|---|---|
| Request Count | 120 | 영향 범위가 몇 건인지 확인 |
| Error Count | 8 | 오류율(error rate)과 검증 실패(validation failure) 연결 |
| Average Latency | 223.750ms | 정상 기준선(baseline) 대비 지연 증가 확인 |
| High Risk Rate | 0.458333 | 예측 분포 변화 확인 |
| Average Score | 0.640249 | 점수 분포 변화 확인 |
| Valid High Risk Rate | 0.464286 | 검증 실패 제외 예측 분포 확인 |
| Validation Failures | 8건 | 실패 요청의 request_id와 입력 필드 확인 |
| Score Bucket Distribution | 0.2-0.4=65, 0.8-1.0=55 |
score가 낮은 bucket과 높은 bucket으로 나뉘는지 확인 |
| Heart Rate Mean Delta | +10.4917 | current batch 입력 구성 변화 후보 확인 |
| Oxygen Saturation Mean Delta | -1.4698 | current batch 입력 구성 변화 후보 확인 |
| Score and Prediction Trend | 평균 점수 +0.1382, high_risk 비율 +0.2417 |
점수와 예측이 같은 방향으로 움직이는지 확인 |
이 표에서 중요한 것은 값의 크기만 보는 것이 아닙니다. 120건 중 8건의 오류가 있고, high_risk 비율과 평균 점수가 함께 높다면 입력 품질, 운영 부하, 모델 변경, 설정 변경을 분리해서 봐야 합니다.
4-5-2. 응답 속도와 오류율 시각화¶
Average Latency와 Error Count는 함께 봐야 합니다. 지연 시간만 증가하면 처리 지연이 주요 후보이고, 오류(error)도 함께 증가하면 API 실패나 검증 실패가 운영 품질 기준 미충족에 영향을 주었을 수 있습니다.
응답 속도와 오류율은 서비스 안정성의 기본입니다. 오프라인 평가 지표(metric)가 기준을 충족해도 API가 느리거나 자주 실패하면 운영 품질 기준을 만족하기 어렵습니다. 특히 AI 서비스에서는 모델 실행 시간이 길어질 수 있으므로 지연 시간 관측이 중요합니다.
| 관측 조합 | QA 해석 |
|---|---|
| 지연 시간 증가, 오류(error) 변화 없음 | 처리 지연 또는 트래픽 증가 |
| 지연 시간 증가, 오류 증가 | 타임아웃(timeout), 서버 부하, 의존성 장애 |
| 지연 시간 정상, 오류 증가 | 검증 실패 또는 특정 API 오류 |
| 오류 정상, 예측 변화 | 데이터, 모델, 설정 문제 우선 확인 |
이번 Demo에서는 정상 기준선 대비 지연 시간이 120.00ms 증가하고, 오류율이 0.0000에서 0.0667로 증가합니다. 이 조합은 모델 출력 변화만 볼 상황이 아닙니다. 먼저 검증 실패와 서비스 부하 후보를 함께 확인해야 합니다.
4-5-3. 검증 실패 시각화¶
Validation Failures 패널은 오류 요청을 로그로 확인하기 위한 패널입니다. 검증 실패가 늘면 모델 지표보다 먼저 API 입력 품질과 스키마(schema) 변경을 확인합니다.
검증 실패는 클라이언트(client) 또는 상위 시스템(upstream)이 API 계약(contract)을 지키지 못했다는 신호입니다. 이 신호가 늘어난 상태에서 모델 지표를 계산하면 잘못된 요청과 정상 요청이 섞일 수 있습니다. 따라서 검증 실패는 품질 분석의 선행 조건입니다.
| 확인 항목 | 이유 |
|---|---|
| 실패 필드 | 어떤 입력이 문제인지 확인 |
| 실패 출처(source) | 특정 클라이언트나 배치(batch)에서 발생하는지 확인 |
| 발생 시점 | 배포나 상위 시스템(upstream) 변경과 연결 |
| 정상 요청 비율 | 모델 품질 분석에 사용할 수 있는 요청 규모 확인 |
대시보드에서 Validation Failures가 증가하면 로그 쿼리로 내려가야 합니다. 예를 들어 validation_failure="true" 조건으로 실패 요청을 찾고, 대표 request_id를 골라 어떤 입력 필드가 문제였는지 확인합니다. 4-6 Lab은 이 후속 확인을 위해 artifacts/reports/chapter_04_validation_failure_examples.md를 생성합니다. 이 파일에서 failed_field, client_id, source_system, owner를 확인한 뒤 “API schema owner가 볼 문제인지, upstream client owner가 볼 문제인지”를 나눕니다.
4-5-4. 점수와 예측 분포 시각화¶
Average Score와 High Risk Rate가 함께 증가하면 입력 분포 변화, 임계값(threshold) 설정 오류, 모델 버전(model_version) 변경을 확인합니다. 점수만 증가하고 high_risk 비율이 크게 바뀌지 않았다면 임계값이 높은 값으로 설정되어 있을 수도 있습니다.
점수와 예측은 반드시 함께 봐야 합니다. 점수는 임계값 적용 이전 모델 출력이고, 예측은 임계값 이후 결과입니다. 둘의 관계를 보면 점수 분포 변화와 임계값 설정 문제를 분리할 수 있습니다.
분포를 볼 때는 평균만 보지 않습니다. 평균 점수는 분포가 어느 방향으로 움직였는지 빠르게 알려 주지만, 낮은 점수와 높은 점수가 섞여 있는지, 특정 bucket에 몰렸는지는 보여 주지 못합니다. 그래서 dashboard에는 Score and Prediction Trend, Prediction Distribution, Score Bucket Distribution을 함께 둡니다. Prediction Distribution은 class별 건수를 보여 주고, Score Bucket Distribution은 임계값 적용 전 점수 구간을 보여 주므로 두 패널을 같이 봐야 임계값 문제와 입력 구성 변화 후보를 분리할 수 있습니다.
| 관측 조합 | 우선 확인 |
|---|---|
점수 증가, high_risk 비율 증가 |
입력 분포 변화, 모델 버전 변경 |
점수 증가, high_risk 비율 변화 작음 |
임계값 설정 |
점수 변화 작음, high_risk 비율 급증 |
임계값 변경 또는 집계 기준 오류 |
| 검증 실패 증가, 점수 패널(score panel) 변화 | 입력 검증 실패가 분포 계산에 섞였는지 확인 |
이번 Demo에서는 전체 이벤트 기준 high_risk 비율이 정상 기준선 대비 0.2417 증가하고, 평균 점수도 0.1382 증가합니다. 유효 요청 기준 high_risk 비율은 0.464286입니다. 따라서 High Risk Rate 패널만 보지 말고 Valid High Risk Rate, Average Score, Validation Failures, model_version, threshold를 함께 확인해야 합니다.
분포 bucket으로 보면 전체 요청에서 0.2-0.4 score bucket은 65건이고, 0.8-1.0 score bucket은 55건입니다. 유효 요청만 보면 0.2-0.4는 60건, 0.8-1.0은 52건입니다. 검증 실패 8건을 제외해도 높은 score bucket과 high_risk 예측이 유지되므로, QA는 “검증 실패만으로 모든 변화가 설명된다”고 쓰면 안 됩니다.
입력 drift 후보는 평균 delta와 기준선 대비 현재 분포를 함께 봐야 합니다. 평균 delta는 어느 feature가 움직였는지 빠르게 알려 주지만, 특정 bucket의 요청이 늘었는지는 보여 주지 못합니다. 그래서 dashboard에는 Input Drift Delta Trend와 함께 Heart Rate Distribution: Reference vs Current, Oxygen Saturation Distribution: Reference vs Current를 둡니다. 이 단계에서 곧바로 재학습을 결론내리면 안 됩니다. 먼저 시각적 분포 차이가 실제 환경 변화인지, 입력 품질 문제인지, 검증 실패나 집계 기준 문제인지 분리해야 합니다. 5장에서는 이 후보를 drift_report.md, quality_issue_trace.md, 승인 기준으로 연결해 최종 판단에 사용합니다.