runlot 문서

모든 프로젝트의 로그, 요청 기록, 트레이스, 메트릭, 오류, 모니터, 대시보드를 플랫폼이 수집합니다. 에이전트도 SDK도 필요 없습니다.

Runlot은 워커를 실행하고, 워커가 호출하는 모든 바인딩을 직접 운영하며, 각 배포가 어느 커밋에서 왔는지 알고 있습니다. 그래서 Observability 서비스가 보통 설치하라고 요구하는 것 대부분을 이미 수집하고 있습니다. 모든 요청은 ID와 기록과 결과를 받고, 프로세스의 메모리는 cgroup에서 읽으며, env.db, env.storage, env.ai 호출은 따로 설정하지 않아도 스팬이 됩니다.

프로젝트를 열고 Observability를 선택합니다. 구성은 다음과 같습니다.

섹션	보여 주는 것
Overview	요청, 오류, 상태 코드 계열, 지연 시간 p50/p95/p99와 배포 및 OOM 표시
Logs	워커가 출력한 내용의 실시간 로그와 저장된 기록
Invocations	요청, cron 실행, 큐 배치, 이메일마다 하나씩 남는 기록, Query Builder, 저장한 쿼리, 로그 패턴
Traces (APM)	라우트별 요청, 오류, 지연 시간, 지연 시간 분해, 서비스 맵, 배포 비교, 트레이스 탐색기
Database	`env.db` 문장 지문과 데이터베이스 상태
Infrastructure	한도 대비 메모리, CPU, 압력 지연, I/O, 재시작, 파킹과 깨우기
Metrics	`env.metrics`의 사용자 정의 메트릭과 로그에서 파생한 메트릭
Errors	Runlot Errors: 예외, 크래시, 메모리 부족 종료를 이슈로 묶은 것
Browser	브라우저 오류, Web Vitals, 세션 리플레이 (Pro)
Dashboards	기본 제공 대시보드와 직접 만든 대시보드
Monitors	모니터, SLO, 다운타임, 합성 검사
Settings	샘플링, 한도와 비용, 파이프라인과 스캐너, 내보내기, 프로파일러, 역할과 감사

요청 ID

Runlot을 거치는 모든 요청은 32자리 16진수 ID를 받습니다. 이 ID는 Runlot-Request-Id 응답 헤더로 호출자에게 돌아가고, 요청과 함께 워커에도 전달됩니다. 트레이스 ID이기도 합니다. 요청을 지정하라는 곳이면 어디든 붙여 넣으면 됩니다.

runlot logs request 4bf92f3577b34da6a3ce929d0e0e4736

앱 대신 Runlot이 응답하는 경우, 즉 프로세스가 메모리를 다 썼거나, 크래시했거나, 시작하는 중일 때도 오류 페이지와 JSON 본문에 같은 ID가 담깁니다. 익명 방문자에게는 일반적인 app_error 코드만 보입니다. 프로젝트 조직의 멤버가 로그인한 상태라면 원인(exceeded its memory limit, 시그널 이름, 배포 버전)과 /o/<org>/p/<project>/observability/requests/<id>의 요청 링크를 볼 수 있습니다. 공개 앱에서는 페이지에 Owner? Sign in to see details가 표시됩니다.

직접 켜는 것

요청 기록, 메트릭, 메모리, 워커 종료, 서버 오류는 아무 설정 없이 모든 프로젝트에서 수집합니다. 다음 두 가지는 요청마다 워커의 CPU를 쓰므로 직접 켜기 전까지 꺼져 있습니다. 각 요청의 콘솔 줄과 예외(logs), 그리고 스팬(traces)입니다.

runlot.json

{
  "observability": {
    "logs": { "enabled": true, "head_sampling_rate": 1 },
    "traces": { "enabled": true, "head_sampling_rate": 0.1 }
  }
}

대시보드의 Settings에서 배포 없이 두 설정을 모두 덮어쓸 수 있습니다. Settings를 참고하세요.

Free와 Pro

어느 플랜이든 앱이 왜 실패했는지 볼 수 있습니다. 플랜에 따라 달라지는 것은 얼마나 많이, 얼마나 오래 보관하는지와 그 위에서 얼마나 많은 분석을 하는지입니다.

	Free	Pro
실패 원인: 메모리 부족, 크래시, 플랫폼 오류, 요청 ID, 로그인 시 원인 보기	예	예
로그와 요청 기록	3일, 프로젝트당 하루 200,000 이벤트, 한도 고정	7일, 프로젝트당 하루 2,000,000 이벤트, 한도 해제 가능
기본 제공 메트릭	15일	15개월
Query Builder	예, 저장한 쿼리 10개	저장한 쿼리 무제한
Runlot Errors (서버)	월 5,000 이벤트, 30일 보관	월 100,000 이벤트, 90일 보관
APM	상위 5개 라우트만	전체: 분해, 서비스 맵, 배포 비교, `env.db` 쿼리 모니터링
장기 보관 트레이스 (오류, 가장 느린 1 %, 직접 정한 필터)	—	30일
사용자 정의 메트릭 시리즈	월 100개, 고정	월 2,000개 포함, 한도 해제 가능
사용자 정의 대시보드	3	무제한
모니터	10	500
SLO	1	50
합성 검사	1개, 15분마다	20개, 1분마다
Watchdog	배포 회귀	배포 회귀, 계절성 이상, 새 로그 패턴
브라우저 오류, RUM, 세션 리플레이	—	예 (월 RUM 세션 50,000개와 리플레이 5,000개 포함)
연속 프로파일러, 힙 스냅샷	—	예
내보내기 (OTLP, Logpush)와 재수화	—	대상 5개
테일 컨슈머	1	5

Pro에서 포함량을 넘는 사용량은 해당 한도를 올리거나 제거한 경우에만 청구되며, 언제나 조직의 지출 한도 안에서만 청구됩니다.

계량 항목	포함량을 넘는 가격
로그 이벤트	100만 개당 $0.60
스팬	100만 개당 $0.60
오류 이벤트	1,000개당 $0.20
세션 리플레이	1,000개당 $3.00
RUM 세션	1,000개당 $0.50
사용자 정의 메트릭 시리즈	시리즈당 월 $0.05
합성 검사	1분 간격 기준 검사당 월 $1.00, 일할 계산
프로파일러	프로파일링한 시간당 $0.03
장기 보관 트레이스	GB-월당 $0.10

한도와 비용을 참고하세요.

자체 호스팅

자체 호스팅 Runlot은 Observability 데이터를 ClickHouse에 저장하며, ClickHouse는 선택 사항입니다. ClickHouse가 없어도 요청 ID, 오류 페이지, 실시간 로그, 저장된 로그 줄(PostgreSQL에 저장), 워커 종료 기록, 메모리 차트는 그대로 쓸 수 있습니다. Query Builder, 요청 기록, 트레이스, APM, 내보내기는 ClickHouse가 필요합니다. 대시보드는 쓸 수 없는 섹션을 빈 채로 보여 주지 않고 표시하지 않습니다.

이 섹션의 페이지

로그 — 실시간 로그와 저장된 로그를 보는 runlot logs
호출과 쿼리 — 요청 기록, Query Builder, runlot logs query와 runlot logs request
트레이스와 APM — 라우트, 서비스 맵, 배포 비교, 보관 필터
메트릭 — 기본 제공, 인프라, 데이터베이스, env.metrics, 로그 기반 메트릭
모니터와 SLO — 알림, 다운타임, 합성 검사, 코드로 관리하는 모니터
대시보드 — 사용자 정의 대시보드, 코드로 관리하는 대시보드, 공유
Settings — 샘플링, 한도, 파이프라인, 스캐너, 내보내기, 프로파일러, 역할
버그 리포트 — runlot bug-report

Observability

요청 ID

직접 켜는 것

Free와 Pro

자체 호스팅

이 섹션의 페이지

이 페이지의 목차