> ## Documentation Index
> Fetch the complete documentation index at: https://control.datarelay.run/llms.txt
> Use this file to discover all available pages before exploring further.

# 운영자 일일 점검

> Dashboard에서 문제 Stream과 Route를 찾아 실제 로그와 수신 상태까지 점검합니다.

# DataRelay Control 일일 운영 점검

**목표:** 중요한 데이터가 정상 수집·전송되는지 확인하고 장애 시 **Stream/Route/Destination** 단위로 문제를 좁힙니다.

> [!NOTE]
>
> **화면 버전:** 표시된 이미지는 과거 Control UI 테스트 캡처입니다. 현재 제품의 기본 5단계 순서(Connect → Sample & Record Selection → Destinations → Route Processing → Deploy)를 우선하세요. [번호별 화면 가이드](https://control.datarelay.run/ko/use-cases/screen-walkthrough.md)에서 차이를 설명합니다.

## 적용 순서

이 사례는 이미 구성된 Connector·Destination·Stream을 전제로 합니다. 아직 생성하지 않았다면 [커넥터별 수집 가이드](https://control.datarelay.run/ko/use-cases/index.md)에서 먼저 수집 Source를 설정하세요. 이후 이 페이지의 구체적인 단계를 수행하고 **실제 Logs와 Destination/격리 기록**을 검증합니다. 화면 캡처는 기존 테스트 증빙으로, 실제 결과를 대신하지 않습니다.

## 근무 시작 전

담당하는 Stream Group, 평상시 수집량/수집 간격을 확인합니다. 상태 조회만 한다면 Viewer 권한을 사용하고, 설정 변경·Replay 등은 허가된 Operator/Administrator 계정을 사용합니다.

## 1. 전체 흐름 상태 확인

1. **Dashboard** (`/monitoring`)를 엽니다.
2. 확인 시간 범위를 기록하고 **Healthy/Warning/Critical**, **Incoming/Outgoing Events**, **Delivery Success Rate**를 확인합니다.
3. **No Data / Low Volume** Stream을 찾습니다. 단, 원래 조용한 Source라면 데이터 0건이 정상일 수 있으므로 기대되는 수집 주기와 비교합니다.
4. Destination Capacity, Schema Drift 등 Warning을 검토하되 Dashboard의 집계 결과만으로 장애 원인을 단정하지 않습니다.

![dashboard-triage — numbered Control historical UI capture](https://mintcdn.com/datarelay-control/Tl9_UibGAprPlCr8/images/screenshots/annotated/dashboard-triage.webp?fit=max\&auto=format\&n=Tl9_UibGAprPlCr8\&q=85\&s=f9c658cdeaa4638d8010ca10721745f1)

*그림 1. **Dashboard에서 장애 Stream 추적 시작.** ① 조회 기간을 설정하고 ② Health의 Critical/Warning을 확인한 다음 ③ Recent Alerts를 열어 영향 범위를 찾습니다. 근본 원인은 Streams·Routes·Logs에서 확인합니다.*

## 2. 문제 Stream 찾기

1. **Streams** (`/streams`)를 열어 해당 Source Product/Group을 선택합니다.
2. 수집량이나 상태가 비정상적인 Stream의 Runtime/Detail을 엽니다.
3. Source 수집, 마지막 Run, 추출 레코드, Checkpoint, Stream Enabled 상태를 확인합니다.
4. **Data Flows / Routes** (`/routes`)에서 Route별 Destination 상태를 비교합니다.

## 3. 실제 이벤트 증거 수집

1. **Logs** (`/logs`)에서 정확한 Stream/Route, 시간 범위, Status, Stage로 필터링합니다.
2. 오류 Row의 Detail에서 Event/Run/Route ID, 시각, Stage, 오류와 Destination을 기록합니다.
3. 전송 실패이면 [전송 장애 진단과 복구](https://control.datarelay.run/ko/use-cases/delivery-incident.md), 정책 격리라면 [Quarantine·Release·Replay](https://control.datarelay.run/ko/use-cases/quarantine-replay.md)를 수행합니다.
4. 사고 분석 자료가 필요하면 [Logs·Saved View·Export](https://control.datarelay.run/ko/use-cases/logs-audit.md)를 따라 현재 로드된 필터 일치 행을 추출합니다.

## 4. 복구 확인

허가된 조치 후 **새로운 Run**을 관찰하고 해당 Event/Route ID, 독립 수신 시스템의 실제 데이터, Checkpoint 결과를 비교합니다. Dashboard가 Healthy로 바뀌었다고 이전 실패 이벤트까지 복구된 것으로 판단하지 않습니다.

## 점검 기록과 완료 기준

점검 시각, Stream Group, 문제 Stream/Route/Destination, 실패 원인, 조치, Run ID, 이후 수신 증명, 미해결 항목 및 담당자를 기록합니다.

**완료 조건:** 모든 중요 Stream이 정상이라는 증빙이 있거나, 문제가 있는 경우 담당자와 근거 로그가 기록된 상태여야 합니다. Dashboard를 초록색으로 만들기 위해 임의로 Alert/Policy를 비활성화하지 않습니다.

**관련:** [로그 증빙](https://control.datarelay.run/ko/use-cases/logs-audit.md), [Schema 변경](https://control.datarelay.run/ko/use-cases/schema-change.md), [Route Processing](https://control.datarelay.run/ko/processing/route-processing.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.