Settings

여기 있는 모든 설정은 Observability → Settings에 있으며, 각 설정에는 /v1/orgs/{org}/projects/{project}/observability/ 아래의 API 경로가 있습니다.

샘플링

요청 기록은 항상 보관합니다. 샘플링이 정하는 것은 호출의 내용, 즉 콘솔 줄과 예외(logs), 그리고 스팬(traces)을 수집할지 여부입니다. 이를 만드는 데 요청마다 워커의 CPU가 들기 때문에 둘 다 기본적으로 꺼져 있습니다.

{
  "observability": {
    "logs": { "enabled": true, "head_sampling_rate": 0.25, "invocation_logs": true },
    "traces": { "enabled": true, "head_sampling_rate": 0.05 }
  }
}

결정은 요청이 도착할 때 요청마다 한 번 내리므로, 샘플링된 요청에는 모든 줄과 스팬이 있고 샘플링되지 않은 요청에는 하나도 없습니다. 워커가 stdout과 stderr로 출력한 내용은 이와 관계없이 저장합니다.

대시보드에서 배포 없이 네 값을 모두 덮어쓸 수 있습니다. 비워 둔 필드는 현재 배포의 runlot.json 값을 따릅니다.

curl -X PUT https://api.runlot.io/v1/orgs/my-org/projects/my-app/observability/sampling \
  -H "Authorization: Bearer $RUNLOT_TOKEN" -H "Content-Type: application/json" \
  -d '{"logsEnabled": true, "logSampleRate": 0.1, "tracesEnabled": null, "traceSampleRate": null}'

요청은 다음 라우팅 맵 갱신 때 변경을 반영하며, 보통 몇 초 안, 늦어도 30초 정도 뒤입니다. cron, 큐, 이메일, Durable Object 알람 호출은 다음에 앱이 시작할 때 반영합니다. 설정하려면 admin 역할이 필요합니다.

한도와 비용

계량하는 모든 신호는 한 가지 규칙을 따릅니다.

• 한도는 기본적으로 켜져 있으며, 플랜의 포함량으로 정해져 있습니다.
• Pro는 프로젝트별로 한도를 올리거나 제거할 수 있습니다. 포함량을 넘는 사용량은 청구되며, 페이지에서 변경 전후의 현재 사용률 기준 월 예상 비용을 보여 줍니다.
• Free는 포함량으로 고정됩니다. 한도를 낮추는 것은 어느 플랜이든 가능합니다.
• 조직의 지출 한도는 모든 한도보다 위에 있습니다. 지출 한도에 도달하면 수집이 멈추며, 앱은 멈추지 않습니다.
• 한도에 도달하면 수집이 줄어들 뿐, 일어났다는 기록은 줄지 않습니다. 개수는 항상 보관합니다.

플랫폼 오류 이벤트, 즉 Runlot이 앱 대신 응답해야 했을 때 기록하는 이벤트에는 한도가 없습니다.

curl -X PUT https://api.runlot.io/v1/orgs/my-org/projects/my-app/observability/caps \
  -H "Authorization: Bearer $RUNLOT_TOKEN" -H "Content-Type: application/json" \
  -d '{"logEventsDaily": 10000000, "customSeries": -1}'

logEventsDaily, customSeries, rumSessions는 각각 숫자, 한도 없음을 뜻하는 -1, 또는 플랜 포함량을 뜻하는 null을 받습니다. 지정하지 않은 항목은 바뀌지 않습니다. 오류와 스팬 한도는 runlot errors settings(--cap, --span-cap)에 있습니다. 한도를 바꾸려면 admin 역할과 observability:admin이 필요합니다.

파이프라인과 민감 데이터 스캐너

로그 이벤트는 수집 시점에, 저장하기 전과 내보내기 전에 파이프라인과 스캐너를 거칩니다. 둘 다 .runlot/logs.json에 두며, runlot deploy가 이 파일을 배포와 함께 가져갑니다.

{
  "pipeline": [
    { "type": "json_parse" },
    { "type": "regex", "pattern": "took (?P<took_ms>\\d+)ms" },
    { "type": "rename", "from": "uid", "to": "userId" },
    { "type": "level", "field": "severity", "mapping": { "W": "warn", "E": "error" } },
    { "type": "drop", "filter": [{ "key": "$message", "op": "starts_with", "value": "healthcheck" }] }
  ],
  "scanner": {
    "builtins": { "email": "hash", "card": "redact", "jwt": "redact" },
    "rules": [{ "name": "order-token", "pattern": "ot_[A-Za-z0-9]{24}", "action": "redact" }]
  },
  "logMetrics": []
}

• 프로세서는 순서대로 실행합니다. json_parse, kv, regex(이름 있는 그룹을 쓰는 RE2), rename, level, url, user_agent, drop, sample이 있습니다. 최대 32개입니다. 파이프라인이 없으면 json_parse만 실행합니다.
• 기본 제공 스캐너 규칙: jwt, bearer, api_key, email, card(Luhn으로 검사), kr_rrn(검증 숫자을 통과하는 주민등록번호). 각각 redact, hash, drop, off 중 하나이며, 언급하지 않은 규칙은 가립니다. 직접 만든 RE2 규칙을 최대 50개 추가할 수 있습니다. 같은 스캐너가 오류 이벤트에도 적용됩니다.
• 파이프라인이나 스캐너가 버린 이벤트는 일일 한도에 포함하지 않습니다.
• logMetrics는 로그 기반 메트릭입니다.
• 파일은 최대 64 KiB입니다. 해당 배포가 실제로 적용될 때 반영되며, 대시보드에서 고친 내용은 이 파일을 가진 다음 배포 전까지 유지됩니다. 대시보드의 Export는 현재 설정을 이 형식으로 내보냅니다.
• 저장하기 전에 예시 문자열로 스캐너를 시험해 보세요. 아무것도 저장하지 않습니다.

내보내기

로그, 트레이스, 메트릭을 자신의 도구로 보냅니다. Pro이며, 프로젝트당 대상은 최대 5개입니다.

• OTLP: 공개 주소의 443 또는 4318 포트에 있는 HTTPS 수집기로 OTLP/HTTP JSON을 보냅니다. 선택적으로 헤더를 붙일 수 있습니다(봉인하며, 이후에는 이름만 보여 줍니다). 신호는 logs, traces, metrics입니다. persist: false이면 로그와 트레이스를 Runlot에 저장하지 않고 내보내기만 합니다.
• Logpush: logs와 invocations를 시간마다 gzip으로 압축한 NDJSON 객체로, 지정한 S3 호환 버킷이나 프로젝트 자신의 env.storage 버킷에 <prefix>/yyyy/mm/dd/hh/<signal>-<n>.ndjson.gz 형태로 씁니다.

각 대상은 전송 상태와 마지막 실패를 보여 줍니다. 느리거나 실패하는 대상은 백오프로 다시 시도하며, 앱을 붙잡지 않습니다.

재수화

플랜의 보관 기간보다 오래된 로그를 Logpush 아카이브에서 다시 불러와 쿼리할 수 있습니다. Logpush 대상과 최대 72시간의 범위를 고르면, 보관 기간보다 오래된 부분을 다시 불러와 7일 동안 같은 쿼리에 응답합니다. 재수화한 행은 다시 내보내지 않으며 메트릭 차트를 바꾸지 않습니다. Pro입니다.

테일 컨슈머

테일 컨슈머는 각 호출의 트레이스를 런타임으로부터 받는 워커 자신의 export이며, Cloudflare의 tail_consumers와 같습니다.

{ "main": "src/index.ts", "tail_consumers": [{ "entrypoint": "AuditTail" }] }

import { WorkerEntrypoint } from "cloudflare:workers";

export class AuditTail extends WorkerEntrypoint {
  async tail(events) {
    for (const e of events) if (e.outcome !== "ok") console.log({ audit: e.outcome });
  }
}

export default { fetch: () => new Response("ok") };

엔트리포인트는 메인 모듈의 export여야 하며, Durable Object 클래스이거나 runlot으로 시작하는 이름이면 안 됩니다. 모든 호출은 테일 컨슈머가 읽든 읽지 않든 트레이스를 만들므로 CPU가 듭니다. Free는 1개, Pro는 5개까지입니다.

프로파일러와 힙 스냅샷

연속 프로파일러는 대략 10분마다 10초 동안 앱의 CPU 프로필을 샘플링하고, 배포의 소스 맵으로 심볼을 붙인 다음, 버전별 플레임 그래프, 자체 시간 기준 상위 함수, 두 버전 간 비교를 보여 줍니다. 같은 분의 느린 트레이스에서 프로필로 연결됩니다.

Pro 기능이며 기본적으로 꺼져 있습니다. 켜면 다음 배포나 재시작 때 적용되며, 프로파일러를 붙이려고 앱을 재시작하지는 않습니다. 프로파일링한 시간은 시간당 $0.03로 청구됩니다.

프로파일러가 켜져 있으면 관리자가 실행 중인 앱의 힙 스냅샷을 찍을 수 있습니다. 찍는 동안 앱이 멈추고, 스냅샷에는 비밀을 포함해 앱이 메모리에 가진 모든 것이 담깁니다. 그래서 관리자만 찍을 수 있고 감사 기록에 남으며, 한 번에 하나씩, 최대 10분에 한 번만 찍을 수 있고, 7일 뒤 만료됩니다.

역할과 감사

프로젝트의 Observability 데이터는 세 가지 권한으로 관리합니다.

조직의 viewer와 member는 read를 받고, admin은 세 가지를 모두 받습니다. 관리자는 한 프로젝트에서 한 사람의 권한을 넓히거나 좁힐 수 있습니다. pii와 admin에는 read가 함께 있어야 하며, 자신의 admin은 제거할 수 없습니다. 개인 액세스 토큰은 만들 때 지정한 범위만 가지므로, 토큰은 권한을 더 좁힙니다.

감사 기록에는 모든 설정 변경(한도, 내보내기, 재수화, 역할 재정의, 파이프라인, 스캐너, 모니터)과 PII 범위 데이터의 모든 조회가 남습니다. 버그 리포트를 보냈다면 Runlot 직원이 그 리포트를 조회한 기록도 여기에 나타납니다. 감사 기록을 보려면 observability:admin이 필요합니다.

Data는 프로젝트의 Observability 데이터가 어디에 보관되고 어디로 내보내지는지 보여 줍니다.