실시간, 인사이트, 알림
실시간 이벤트를 확인하고, 이상 징후를 탐지하고, 조건에 맞으면 알림을 받는 방법을 안내합니다.
실시간, 인사이트, 알림은 데이터의 변화를 확인하고 팀에 알리는 화면입니다. 실시간으로 상태를 보고, 인사이트로 이상 유형을 확인하고, 알림으로 팀에 전달하세요.
진입 경로
- 실시간:
/dashboard/[orgId]/[projectId]/realtime - 인사이트:
/dashboard/[orgId]/[projectId]/insights - 알림:
/dashboard/[orgId]/[projectId]/alerts
실시간
SSE 연결로 이벤트를 실시간으로 보는 화면입니다.
- 활성 사용자 (5분): 최근 5분 동안 이벤트를 보낸 디바이스 수
- 지난 1분, 지난 1시간, 지난 24시간 이벤트 수
- 인기 이벤트 (1시간): 최근 1시간 동안 많이 발생한 이벤트 상위 5개
- 실시간 이벤트 피드: 가장 최근 100건. 이벤트 이름과 경로·국가·브라우저를 보여주고, 예외 이벤트는 에러로 구분합니다
- 연결 상태:
Connected또는Disconnected
숫자는 30초마다 서버 집계로 갱신되고, 그 사이에 도착한 이벤트는 화면에서 바로 더합니다. 피드는 이벤트가 수집된 뒤 분석 저장소에 반영되는 시점에 채워집니다.
실시간 화면은 데이터 포인트를 쓰지 않습니다. 다 봤으면 실시간 일시 중지를 누르세요. 연결을 끊습니다. 다시 보려면 실시간 다시 연결을 누르세요. 재연결과 다른 탭은 각각 새 연결로 계산합니다. 같은 프로젝트에 1분에 30번 넘게 연결하면 잠시 거절됩니다.
원본 보기인사이트
이벤트와 세션의 일별 추이에서 이상 징후를 찾아 카드로 보여줍니다. 탐지는 자동으로 돌지 않습니다. 유형과 값을 고른 뒤 이상 탐지 실행을 눌러야 새 결과가 쌓입니다.
탐지 유형:
| 유형 | 찾는 것 |
|---|---|
| 볼륨 이상 탐지 | 이벤트별 일별 발생 수의 급증·급감. 이벤트마다 7일 이상의 데이터가 있어야 합니다 |
| 신규 이벤트 감지 | 분석 기간 이전에는 기록이 없고 최근 3일 안에 처음 나타난 이벤트 |
| 비활성 이벤트 감지 | 이전에는 발생하던 이벤트가 최근 3일 동안 한 건도 없는 경우 |
| 전환율 이상 탐지 | signup_completed, purchase_completed, trial_started, demo_requested가 전체 이벤트에서 차지하는 일별 비율의 변동 |
| 세션 이상 탐지 | 일별 세션 수와 평균 세션 시간의 변동 |
실행 값:
- 분석 기간 (일): 기본 30일. 7~90일만 실행됩니다.
- Z-Score 임계값: 기본 2. 1~5만 실행됩니다. 가장 최근 날의 값이 평균에서 표준편차의 이 배수 이상 벗어나면 이상으로 봅니다.
범위를 벗어난 값으로 실행하면 탐지가 실패하고 오류가 표시됩니다.
심각도는 Z-Score의 크기로 정합니다. 3 이상이면 Critical, 2.5 이상이면 Warning, 그 밖은 Info입니다. 신규 이벤트는 항상 Info이고, 비활성 이벤트는 사라지기 전 하루 평균이 10건 이상이면 Critical, 3건 이상이면 Warning입니다.
운영 기능:
- 심각도 카드(전체, Critical, Warning, Info)를 누르면 그 심각도만 봅니다. 건수는 숨긴 인사이트를 빼고 셉니다.
- 숨기기로 확인한 인사이트를 목록에서 내립니다. 숨긴 인사이트 표시를 켜면 다시 보입니다.
- 같은 이벤트의 같은 종류 인사이트는 24시간 안에 다시 추가하지 않습니다. 그래서 실행 결과의 "새로 추가" 건수가 감지 건수보다 적을 수 있습니다.
- 목록에는 가장 최근 100건이 표시됩니다.
원본 보기알림
조건이 맞으면 이메일, Slack, webhook으로 통지를 보냅니다.
프로젝트에 접근할 수 있는 조직 멤버는 알림을 만들고 수정할 수 있습니다.
알림을 저장소의 reopt-data/alerts.json으로 선언하고 웹훅 주소를 ${env:NAME}으로 두는 방법은 프로젝트를 코드로 관리하기에 있습니다.
저장소가 관리하는 알림(key가 있는 항목)은 목록의 관리 방식에 코드 관리로 표시됩니다. 콘솔에서 고치면 다음 verify가 어긋남으로 잡습니다.
만들기와 수정
+ 새 알림을 누르면 알림을 받을 이메일 주소나 웹훅 URL을 먼저 입력합니다. 알림 만들기를 누르면 알림이 바로 만들어지고 오른쪽에 알림 수정 패널이 열립니다.
처음 조건은 이름 New Alert, 1시간에 100건 이상입니다.
저장 버튼은 없습니다. 패널에서 값을 바꾸면 그때마다 저장되고 다음 평가부터 적용됩니다. 알림 채널은 입력을 마치고 다른 곳을 누르거나 Enter를 누를 때 저장됩니다.
웹훅 URL은 https로 시작하는 공개 주소여야 하고, example.com 같은 예시용 주소는 받지 않습니다.
조건 종류에서 무엇을 감시할지 고릅니다.
| 조건 종류 | 감시 대상 | 설정 |
|---|---|---|
| 이벤트 수 | 이벤트 하나의 발생 건수 | 이벤트, 비교, 임계값, 확인 주기 |
| 에러 이슈 | 에러 이슈의 상태 변화 | 발생 시점, 최소 심각도 |
| AI 관측 | 모델 호출의 비용, 에러율, p95 지연, 비용 미상 비율 | 지표, 임계값, 비교, 측정 기간, 모델·기능·에이전트 |
이벤트 수:
- 확인 주기
Real-time,Hourly,Daily는 각각 5분, 1시간, 24시간 윈도의 건수를 봅니다. 목록에는실시간,1시간마다,하루 한 번으로 표시됩니다. - 알림 하나는 조건 하나만 봅니다. 조건 줄을 더 추가해도 첫 번째 조건만 저장됩니다.
- 고를 수 있는 이벤트가 아직 없으면 양식 대신 안내 문구만 보입니다.
- 이 양식에는 전달 주소 입력란이 없습니다. 요약의 알림 줄이 실제 받을 주소인지 확인하세요. 주소는
reopt-data/alerts.json의destination으로 지정할 수 있습니다.
에러 이슈:
- 발생 시점은
신규(처음 보는 에러),재발(닫아 두었던 이슈가 다시 활성으로 돌아옴),급증(발생량이 평소의 3배를 넘음) 중 하나입니다. - 최소 심각도를 고르면 그 이상인 이슈만 알립니다.
신규와재발은 상태가 바뀐 이슈마다 한 번씩 통지합니다. 한 번의 평가에서 이슈를 최대 50건까지 확인하고 나머지는 다음 평가로 넘깁니다.- 새로 만든
신규알림은 첫 평가에서 이미 활성 상태인 기존 이슈도 통지 대상으로 봅니다. - 에러 이슈 상세의 알림 만들기로 들어오면 새 알림이 이 조건 종류로 시작합니다.
- 이슈 묶음과 심각도 규칙은 에러 트래킹을 보세요.
AI 관측:
- 지표는 비용(기간 합계, USD), 에러율(%), p95 지연(ms), 비용 미상 비율(%)입니다.
- 측정 기간은 최근 5분, 15분, 1시간, 6시간, 24시간 중에서 고릅니다.
- 모델·기능·에이전트는 각각 한 값으로 좁힐 수 있습니다. 선택지는 최근 24시간에 실제로 호출된 값입니다.
- 모델 호출이 한 건도 없는 윈도는
이하·미만조건이어도 조건이 맞지 않은 것으로 봅니다. - 지표의 뜻은 AI 관측을 보세요.
전달 주소:
- 에러 이슈와 AI 관측 양식의 알림 채널에 이메일 주소 또는 웹훅 URL 하나를 넣습니다.
- 이메일 주소는 이메일로,
hooks.slack.com주소는 Slack으로, 그 밖의 URL은 webhook으로 보냅니다. - URL은
https://여야 합니다. 주소에 계정 정보(user:pass@)를 넣은 URL과 localhost·사설 IP 같은 내부 주소는 저장되지 않습니다. - 형식이 맞지 않는 주소는 저장되지 않고 오류가 표시됩니다.
원본 보기평가 방식
- 켜져 있는 알림은 5분마다 평가합니다.
- 이벤트 수와 AI 관측 알림은 끝난 윈도만 봅니다. 윈도는 UTC 기준으로 길이에 맞춰 정렬됩니다. 1시간 윈도라면 정시부터 다음 정시까지를 그 시간이 끝난 뒤 한 번 평가합니다.
- 그래서 통지는 임계값을 넘은 순간이 아니라 윈도가 끝난 뒤의 다음 평가에서 나갑니다. 24시간 윈도는 UTC 자정(한국 시간 오전 9시)에 끝납니다. 프로젝트 타임존의 하루와 다를 수 있습니다.
- 조건이 계속 맞는 동안은 한 번만 알립니다. 조건이 더 이상 맞지 않는 첫 윈도에 같은 채널로 해제 통지를 보냅니다. 패널의 해제되면 알려주기를 끄면 해제 통지를 보내지 않습니다.
- 새 알림은 과거를 거슬러 평가하지 않습니다. 직전에 끝난 윈도 하나부터 시작합니다.
- 평가가 밀리면 다음 평가가 놓친 윈도를 오래된 것부터 채웁니다. 한 번에 알림당 최대 24개 윈도, 최대 7일 전까지이고 그보다 오래된 윈도는 건너뜁니다. 통지는 가장 최근 윈도에서 상태가 바뀐 경우에만 나갑니다.
- 측정에 실패한 윈도는
평가 오류로 남기고 다음 평가에서 다시 시도합니다. - 에러 이슈 알림은 윈도 없이, 평가할 때마다 그 사이 상태가 바뀐 이슈를 확인합니다.
상태, 음소거, 이력
목록의 상태는 마지막 평가 결과이고, 마지막 평가는 평가한 윈도의 시작 시각입니다. 상태는 1분마다 새로 읽습니다.
| 상태 | 뜻 |
|---|---|
| 미평가 | 아직 한 번도 평가되지 않았습니다 |
| 정상 | 마지막으로 평가한 윈도에서 조건이 맞지 않았습니다 |
| 발생 중 | 마지막으로 평가한 윈도에서 조건이 맞았습니다 |
| 평가 오류 | 가장 최근 평가가 실패했습니다 |
| 음소거 | 통지를 멈춘 상태입니다. 평가는 계속합니다 |
| 중지됨 | 꺼져 있어 평가하지 않습니다 |
콘솔에는 알림을 끄는 버튼이 없습니다. 중지됨은 reopt-data/alerts.json에서 status를 paused로 선언한 알림에 표시됩니다.
음소거는 패널의 30분, 2시간, 24시간 버튼으로 겁니다. 그동안 평가와 이력은 계속 쌓이고 통지만 나가지 않습니다. 음소거 해제로 바로 풉니다.
- 음소거 중에 조건이 맞기 시작했다면, 음소거가 끝난 뒤에도 조건이 계속 맞는 동안은 통지하지 않습니다. 그 사건의 해제 통지도 보내지 않습니다.
- 음소거는 이벤트 수와 AI 관측 알림의 통지를 멈춥니다. 에러 이슈 알림은 음소거해도 통지가 나갑니다.
패널의 평가 이력은 최근 48개 윈도를 보여줍니다. 윈도, 상태, 측정값과 임계값, 통지를 보냈는지, 몇 윈도 늦게 평가했는지, 오류 내용이 나옵니다. 평가 이력은 30일 동안 보관합니다.
화면 아래 최근 발송 이력은 가장 최근에 시도한 통지 10건의 성공과 실패를 보여줍니다.
조건 테스트는 지금부터 윈도 길이만큼 거슬러 올라간 기간의 값을 계산해 조건이 맞는지만 알려줍니다. 통지를 보내지 않고, 데이터 포인트도 쓰지 않습니다. 실제 평가는 정렬된 윈도를 쓰므로 결과가 다를 수 있습니다. 에러 이슈 알림은 조건 테스트를 지원하지 않습니다.
통지 내용
통지 문구는 영어로 나갑니다. 이벤트 수 알림의 발생은 Alert triggered: <알림 이름>, 해제는 Resolved: <알림 이름>으로 시작합니다.
통지와 평가는 데이터 포인트를 쓰지 않습니다.
webhook은 JSON을 POST합니다.
{
"alertId": "…",
"alert": "결제 급감",
"event": "purchase_completed",
"count": 3,
"operator": "lte",
"threshold": 5,
"timeWindow": "1h",
"triggeredAt": "2026-10-13T03:05:12.000Z",
"resolved": false,
"window": { "start": "2026-10-13T02:00:00.000Z", "end": "2026-10-13T03:00:00.000Z" }
}resolved가true이면 같은 알림의 앞선 통지에 대한 해제입니다.- 에러 이슈 알림은
issue(이슈 id, 이름, 심각도, 발생 횟수, 발생 시점created·reopened·spiking, 콘솔 링크)가 붙습니다.event는$exception이고threshold·operator·timeWindow는 의미 없는 자리 채움 값입니다.window는 없습니다. - AI 관측 알림은
ai(지표, 측정값, 모델 호출 수, 필터, 비용 상위 모델, 콘솔 링크)가 붙습니다.event는$ai_generation입니다. - 요청에는
Idempotency-Key헤더가 있습니다. 재시도는 같은 값을 보내므로 중복 수신을 걸러낼 때 쓰세요. 서명 헤더는 없습니다. - 2xx 응답이면 성공입니다. 네트워크 오류,
429,5xx는 합쳐서 3번까지 시도합니다. 10초 안에 응답이 없거나 그 밖의4xx를 받으면 다시 시도하지 않습니다. - 리다이렉트는 따라가지 않고 실패로 기록합니다. 보내기 직전에 주소를 다시 확인해, 내부 주소로 풀리면 보내지 않습니다.
Slack 주소로는 같은 내용을 Slack 메시지 형식으로 보냅니다.
알림이 오지 않을 때
- 상태가
미평가라면 첫 평가를 기다리는 중입니다. - 윈도가 아직 끝나지 않았을 수 있습니다.
Daily알림은 UTC 자정이 지나야 평가됩니다. - 상태가 이미
발생 중이면 조건이 계속 맞는 동안 다시 보내지 않습니다. - 평가가 밀린 사이에 조건이 맞기 시작해 지금까지 이어지고 있다면, 이력에는
발생으로 남지만 통지는 나가지 않습니다. 평가 이력의 지연 열을 확인하세요. - 음소거 중이었거나, 음소거 중에 시작된 사건일 수 있습니다.
- 최근 발송 이력에
실패가 있으면 전달 주소와 수신 서버를 확인하세요. 실패한 통지는 다음 윈도에서 다시 보내지 않습니다. - 전달 주소가
example.com같은 예시용 주소이면 보내지 않고 발송 이력에실패로 남습니다. 예전에 만든 알림이https://example.com/webhook으로 남아 있다면 알림 채널을 실제 주소로 바꾸세요. - 에러 이슈 알림은 활성 상태인 이슈만 알립니다. 최소 심각도보다 낮은 이슈는 건너뜁니다.
세 화면을 함께 쓰는 순서
- 실시간에서 이상을 봅니다.
- 인사이트에서 이상 유형을 확인합니다.
- 알림으로 담당자에게 전달합니다.
- 필요하면 사용자, 세그먼트, 쿼리로 내려가 원인을 좁힙니다.
주의할 점
- 실시간 피드에는 수집되어 처리가 끝난 이벤트가 나타납니다. 방금 보낸 이벤트가 조금 늦게 보일 수 있습니다.
- 알림 임계값은 너무 낮게 잡으면 노이즈가 커집니다.
- 전달 주소는 알림 목록의 알림 채널 열에 그대로 표시됩니다. 주소에 넣은 토큰도 프로젝트 멤버에게 보입니다.
- webhook 요청에는 서명이 없습니다. 수신 주소를 추측하기 어렵게 관리하고,
Idempotency-Key로 중복 수신을 처리하세요. - 알림을 만든 뒤 조건 테스트로 조건을 확인하고, 최근 발송 이력에서 실제 전달 결과를 확인하세요.
다음 단계
- 원인을 사용자군으로 좁히려면 사용자와 세그먼트
- 직접 집계하려면 코호트 비교, 브레이크다운, 쿼리
- 알림을 파일로 관리하려면 프로젝트를 코드로 관리하기
- 데이터 포인트 기준은 비용과 보존 정책