모니터와 SLO

모니터

모니터는 1분마다 쿼리를 평가하고, 값이 임계치를 넘으면 알립니다. Observability → Monitors나 API에서 만들거나, 저장소에 파일로 둘 수 있습니다.

각 모니터에는 구간(기본 5분), 주기(1분), 늦게 도착하는 데이터를 위한 평가 지연(60초), 알림 임계치와 경고 임계치가 있고, 선택적으로 복구 임계치를 두어 경계선 근처를 오가는 값이 알림을 반복하지 않게 할 수 있습니다. groupBy를 쓰면 전체에 알림 하나가 아니라 그룹마다, 예를 들어 라우트마다 알림을 하나씩 보냅니다. noData는 빈 구간을 어떻게 볼지 정합니다. 무시(기본), 알림, 해결 중에서 고릅니다. 행이 없는 개수는 0이므로, 더 이상 실패하지 않는 라우트는 복구됩니다.

메시지는 템플릿입니다. {{value}}, {{threshold}}, {{state}}, {{monitor.name}}, {{project}}, {{link}}, 그리고 {{route}} 같은 각 그룹 차원을 쓸 수 있습니다.

Free는 프로젝트당 모니터 10개, Pro는 500개입니다.

알림 대상

모니터는 Runlot Errors와 같은 프로젝트 알림 대상으로 알립니다. 이메일, Slack, 웹훅, PagerDuty, Opsgenie입니다. Slack이나 웹훅 URL, PagerDuty 라우팅 키, Opsgenie API 키(EU 인스턴스는 eu: 접두사)는 저장할 때 봉인하며 다시 보여 주지 않습니다. 외부 대상은 켜고 나서 알림 데이터를 받는다는 점을 확인하기 전까지 꺼져 있습니다. 모니터가 복구되면 PagerDuty 인시던트는 해결되고 Opsgenie 알림은 닫힙니다.

실제로 의존하기 전에 모니터 페이지에서 테스트 알림을 보내 보세요.

다운타임

다운타임은 ID나 태그로 모니터를 음소거하며, 한 번만 또는 매일이나 매주 일정으로 적용합니다. 모니터는 배포할 때마다 그 뒤 N분 동안 스스로 음소거할 수도 있습니다(muteAfterDeployMinutes). 음소거는 알림을 버리지 않고 미룹니다. 다운타임이 끝났을 때 그룹이 여전히 알림 상태라면 그때 알림을 보냅니다. 이미 보낸 알림의 복구 알림은 음소거하지 않습니다.

SLO

SLO는 7일, 30일, 90일 동안의 목표입니다.

• 요청 기반: 5xx가 아니고 지연 시간 목표 안에 끝난 요청을 정상 요청으로 봅니다. 목표는 50, 100, 200, 300, 500, 750, 1000, 1500, 2000, 3000, 5000, 10000 ms 중 하나이며, 개수는 추정이 아니라 정확한 값입니다. 최대 50개 라우트로 범위를 정할 수 있습니다.
• 모니터 기반: 모니터의 모든 그룹이 OK였던 시간의 비율입니다.

각 SLO는 남은 오류 예산과 소진 차트를 보여 줍니다. slo_burn 모니터는 두 구간을 동시에 보고 소진율로 알리므로, 빠른 소진은 호출하고 느린 소진은 누구도 깨우지 않습니다. 기본값은 1시간과 5분에 14.4배이면 알림, 6시간과 30분에 6배이면 경고입니다.

Free는 프로젝트당 SLO 1개, Pro는 50개입니다. 요청 기반 SLO는 만든 시점부터 요청을 셉니다.

합성 검사

합성 검사는 컨트롤 플레인에서 정해진 일정에 따라 프로젝트 자신의 HTTPS 주소 하나를 호출하고 응답을 확인합니다. 파킹된 앱을 깨우는데, 바로 그것이 목적입니다.

runlot errors uptime add https://my-app.me.runlot.app/health 5
runlot errors uptime list
runlot errors uptime runs <id>

• 1분, 5분, 15분마다 실행합니다. Free: 검사 1개, 최소 15분 간격. Pro: 검사 20개, 1분마다.
• 상태, 헤더, 본문, JSON 경로($.status), 지연 시간에 대해 단언합니다. 리디렉션은 따라가지 않으며, 3xx가 곧 응답입니다.
• 다단계 검사는 최대 10개 요청을 순서대로 실행하며 값을 다음 단계로 넘깁니다. 한 단계에서 JSON 경로나 헤더로 토큰을 꺼내 다음 단계에서 {{token}}으로 씁니다. 비밀로 표시한 헤더는 봉인합니다.
• 두 번 연속 실패하면 이슈 하나를 열고, 다음 성공에서 해결합니다. uptime 모니터는 결과를 알림으로, 모니터 기반 SLO는 가동 시간 목표로 바꿉니다.
• 검사 트래픽은 synthetic 태그가 붙고 기본적으로 APM 수치에서 제외합니다.

Pro에서 1분 간격 기준으로 포함된 20개를 넘는 검사 실행은 검사당 월 $1.00로 일할 계산해 청구합니다.

코드로 관리하는 모니터

모니터를 저장소의 .runlot/monitors/ 아래에 둡니다. 그 안의 모든 .json 파일은 모니터 하나 또는 모니터 배열을 담으며, 배포가 실제로 적용될 때 함께 반영됩니다.

{
  "name": "Checkout 5xx",
  "type": "apm",
  "query": { "metric": "error_rate", "filter": { "route": "/checkout" } },
  "options": {
    "windowMinutes": 5,
    "thresholds": { "alert": 5, "warn": 2 },
    "groupBy": ["route"]
  },
  "message": "Checkout errors at {{value}}% on {{route}}. {{link}}",
  "destinations": ["on-call"]
}

• key가 없는 단독 모니터는 파일 이름(checkout-5xx)을 키로 씁니다. 배열 안에서는 각각 자신의 key가 필요합니다. 다음 배포는 이 키로 같은 모니터를 찾습니다.
• 알림 대상은 ID가 아니라 이름으로 지정하므로 파일에 비밀이 들어가지 않습니다.
• 빈 .runlot/monitors/ 디렉터리는 저장소에서 온 모니터를 모두 제거합니다. 디렉터리가 없으면 아무것도 바뀌지 않습니다.
• 저장소에서 온 모니터는 대시보드에서 읽기 전용입니다. 파일을 고치고 배포하세요. 프리뷰 배포는 모니터를 적용하지 않습니다.
• Monitors 페이지의 Export 또는 GET …/observability/monitors/export는 대시보드에서 만든 모니터를 이 파일 형식으로 내보내므로 그대로 커밋할 수 있습니다.