IT/모니터링

Sloth vs Pyrra, Prometheus SLO 도구 뭘 쓸까

gfrog 2026. 9. 14. 21:19

SLO 도입하겠다고 마음먹은 지 좀 됐는데, 실제로 툴을 고르는 순간이 되면 항상 같은 자리에서 멈춘다. Sloth인가 Pyrra인가. 둘 다 결국 Prometheus recording rule을 뽑아주는 도구인데, 왜 이걸 매번 고민하게 되는지 모르겠다. 최근에 우리 팀 SLO 스택을 한번 다시 정리하면서 두 개 다 붙여봤고, 그 과정에서 느낀 점을 정리해둔다.

두 도구가 하는 일은 사실 거의 같다

Sloth도 Pyrra도 출발점은 동일하다. YAML로 SLO를 선언하면 그걸 읽어서 Prometheus용 recording rule과 alert rule을 생성한다. 멀티윈도우 멀티번-레이트(MWMB) 방식으로 burn rate 알람을 만들어주는 것도 똑같다. Kubernetes CRD로도 쓸 수 있고, CLI로 프로메테우스 룰 파일을 뽑아내는 것도 지원한다.

근데 결이 좀 다르다. Sloth는 "PromQL을 잘 짠 룰 생성기"에 가깝고, Pyrra는 "SLO를 관리하는 플랫폼"을 지향한다.

Sloth: 완결된 도구

Sloth는 지금 유지보수 모드에 가깝다. 메인테이너가 몇 년 전부터 "이 도구는 사실상 완성됐다"는 톤을 유지하고 있고, 새 기능은 거의 안 들어온다. 안정성 위주의 릴리스만 나온다. 처음엔 좀 불안했는데, 반대로 생각하면 붙여놓고 잊을 수 있다는 뜻이기도 하다.

Sloth의 강점은 세 가지 정도로 요약된다.

첫째, plugin 시스템. Go plugin으로 커스텀 SLI 로직을 넣을 수 있다. 우리 팀에서는 특정 서비스의 "성공 기준"이 단순 5xx 카운트가 아니라 "5xx이면서 특정 헤더 없음" 같은 복잡한 조건이었는데, Sloth plugin으로 이걸 재사용 가능한 컴포넌트로 만들 수 있었다.

둘째, CI 검증. sloth validate 명령어로 SLO 스펙이 유효한지 미리 검사할 수 있다. PR 단계에서 SLI 쿼리 오탈자를 잡아내는 게 은근 크다. 프로메테우스 룰이 에러 상태로 들어가면 alert이 조용히 안 뜨는 케이스가 있어서.

셋째, 심플함. UI가 없다. 이게 단점이자 장점이다. Grafana 대시보드가 이미 팀 내 표준이라면 굳이 별도 UI를 붙일 이유가 없다. Sloth가 공식 Grafana 대시보드를 제공하기 때문에 그걸 import해서 쓰면 끝난다.

version: "prometheus/v1"
service: "checkout"
labels:
  team: "payment"
slos:
  - name: "requests-availability"
    objective: 99.9
    sli:
      events:
        error_query: sum(rate(http_requests_total{job="checkout",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="checkout"}[{{.window}}]))
    alerting:
      name: CheckoutHighErrorRate
      page_alert:
        labels: {severity: page}
      ticket_alert:
        labels: {severity: ticket}

Sloth 스펙은 이렇게 생겼다. 딱 봐도 뭐가 뭔지 알겠다.

Pyrra: UI가 붙은 관리 도구

Pyrra는 반대다. 여전히 활발하게 개발되고 있고, 웹 UI가 내장돼 있다. 처음엔 "그깟 UI가 뭐 대단하다고" 했는데, 실제로 써보니 SLO를 사업 조직에 설명할 때 큰 차이가 났다.

Pyrra UI에서는 각 SLO의 error budget이 얼마나 남았는지, burn rate이 어떤 추이로 진행 중인지 한눈에 보인다. Grafana 대시보드에서 같은 정보를 볼 수 있긴 한데, Pyrra는 "SLO 카탈로그" 관점으로 화면이 짜여 있다. 전사 SLO가 30개가 넘어가면 이 관점 차이가 꽤 크다.

Pyrra의 SLO 스펙은 Kubernetes CRD 방식이 훨씬 자연스럽다.

apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: checkout-availability
  labels: {team: payment}
spec:
  target: "99.9"
  window: "4w"
  indicator:
    ratio:
      errors:
        metric: http_requests_total{job="checkout",code=~"5.."}
      total:
        metric: http_requests_total{job="checkout"}

Sloth랑 큰 차이는 없어 보인다. 근데 이 CRD를 Pyrra operator가 감시하고 있고, apply하는 순간 PrometheusRule 오브젝트가 자동 생성되고 UI에도 바로 뜬다. GitOps 관점에서 흐름이 깔끔하다.

단점도 명확하다. plugin 개념이 없다. 복잡한 SLI 로직은 그냥 PromQL로 다 풀어써야 한다. 그리고 UI 서버, operator, Prometheus까지 세 개를 붙여야 해서 배포 컴포넌트가 하나 더 늘어난다.

우리 팀은 뭘 골랐나

솔직히 이 부분에서 팀 내부 논쟁이 좀 있었다. 결론부터 말하면 지금은 Sloth로 rule generation을 하고, Pyrra UI는 안 붙였다.

이유는 세 가지다.

하나. 우리는 이미 Grafana에 SLO 대시보드가 다 돌아가고 있었다. Pyrra UI를 붙이는 게 중복 투자로 느껴졌다. SRE팀 외의 스테이크홀더는 Grafana만 봐도 충분했다.

둘. plugin으로 커스텀 SLI를 재사용하는 케이스가 두어 개 있었다. Pyrra로 옮기면 그걸 다 PromQL로 풀어 써야 하는데, 그 PromQL이 서비스별로 반복되면 관리가 지옥이 된다.

셋. Sloth가 유지보수 모드라는 점이 오히려 안심이 됐다. Prometheus recording rule 문법이 근본적으로 바뀔 일은 없으니까, 새 기능이 없다고 손해볼 게 없다.

근데 만약 지금 처음부터 SLO를 도입하는 팀이라면, 나는 Pyrra를 먼저 검토하라고 말할 것 같다. UI가 주는 온보딩 속도의 차이가 크다. 특히 SLO 개념을 처음 접하는 개발팀에게 "여기 들어가서 우리 서비스 상태 보세요"라고 링크 하나 던져줄 수 있는 게 크다.

하나 더 얹으면

최근 KubeCon에서도 SLO 툴링 트랙에 Pyrra 얘기가 부�� 늘었다. OpenSLO 스펙과의 호환성도 조금씩 진행 중이라, 지금 도입한다면 나중에 벤더 lock-in을 걱정할 필요는 덜해 보인다.

Sloth는 안 죽는다. 그데 성장하지도 않는다. 이걸 "은퇴한 마이스터"로 볼지 "정체된 도구"로 볼지는 팀 성격에 따라 다를 것 같다. 나는 전자로 본다. 우리 팀 컨텍스트에서는 아직도 정답이라고 느낀다.

혹시 다른 조합 쓰고 계시면 코멘트로 알려주세요. Nobl9 같은 상용 툴로 넘어간 팀 얘기도 궁금하다.

저작자표시 비영리 동일조건 (새창열림)