프로메테우스의 선

프로메테우스의 선 (The Zen of Prometheus)

프로메테우스로 애플리케이션을 계측하고, 관용적인(idiohmatic) 알림을 작성할 때 바탕이 되는 핵심 가치와 지침을 모아 둔 초보자 친화적인 문서가 바로 이 페이지예요. "선(The Zen)"이라는 이름처럼, 프로메테우스 커뮤니티가 함께 유지보수하려는 철학적인 지침 모음이에요. 하나씩 읽다 보면 프로메테우스를 왜 그렇게 설계하고 사용하는지 그 정신을 느낄 수 있어요.

예를 들어 "Instrument first, ask questions later"(일단 계측부터, 질문은 나중에), "카운터가 지배하고 게이지는 형편없다", "그래프로 그릴 수 있으면 알림을 걸 수 있다" 같은 명쾌한 격언들로 가득해요. 이 문서는 프로메테우스를 쓰는 모든 사람이 한 번쯤 마음에 새기면 좋을 원칙들을 담고 있어요.

출처: 문서

본문

프로메테우스의 선(The Zen of Prometheus)은 Prometheus로 애플리케이션을 계측하고 관용적인 알림을 작성하기 위한 초보자 친화적인 핵심 가치와 지침 집합이에요. 이 문서는 Prometheus 커뮤니티가 유지보수하려는 문서예요. 기여는 자유롭게 하세요.

일단 계측부터, 질문은 나중에 (Instrument first, ask questions later)

개발 중에는 나중에 어떤 질문을 해야 할지 절대 알 수 없어요. 소프트웨어에는 좋은 계측이 필요하고, 그것은 선택 사항이 아니에요. 라벨이 없는 메트릭은 저렴해요. 라벨을 넉넉히 사용하되, 라벨을 추가할 때는 카디널리티에 주의하세요.

첫 번째이자 가장 중요한 규칙 — 단 하나만 기억해야 한다면 이것을 기억하세요. 모든 것을 계측하세요.

사용자가 신경 쓰는 것을 측정하세요 (Measure what users care about)

사용자가 여러분의 데이터베이스 서버가 다운됐는지 신경 쓸까요? CPU 포화를 신경 쓸까요? 네, 하지만 직접적으로는 아니에요. 그들은 자신이 경험하는 것을 신경 써요. 그들은 요청한 페이지에 접근할 수 있는지, 결과가 신선한지 신경 써요. 지연시간과 가용성의 관점에서 생각하세요. 여러분의 SLO가 계측과 알림을 이끌게 하세요.

RED, USE, The Four Golden Signals는 시작할 때 유용한 잘 알려진 프레임워크예요.

그래도 데이터베이스 가용성과 CPU 포화 같은 내부 메트릭도 측정해야 해요. 그것들을 트러블슈팅과 용량 계획에 사용하세요.

무언가가 왜 고장났는지에 답하기 위해 인과 메트릭(causal metrics)을 사용하세요.

라벨이 새로운 계층이다 (Labels are the new hierarchies)

라벨이 새로운 계층(hierarchies)이에요. 하지만 더 강력하고 유연하죠. 라벨이 Prometheus를 강하게 만드는 것이에요. 라벨을 사용하면 측정값을 나중에 그룹화하고 집계할 수 있어요. 라벨로 슬라이스하고 다이스하세요. 일단 계측부터, 질문은 나중에를 기억하고 가능한 한 많은 맥락을 제공하세요. 하지만 라벨은 주의해서 사용해야 해요. 아래 설명을 보세요.

누락된 메트릭 피하기 (Avoid missing metrics)

무언가가 발생할 때까지 존재하지 않는 타임시리즈는 다루기 어려워요. 이를 피하려면 미리 존재할 것으로 아는 모든 타임시리즈에 대해 0을 내보내세요. 깨진 대시보드와 오발화하는 알림을 방지하기 위해 메트릭을 0 값으로 초기화하세요. 더 자세한 설명은 메트릭의 실존 문제를 확인하세요.

기억하세요, 라벨이 타임시리즈를 만들므로, 사용할 것으로 예상하는 라벨로 메트릭을 초기화하세요. 클라이언트 라이브러리는 여러분이 어떤 라벨을 가질지 알 수 없으니까요.

카디널리티가 중요하다 (Cardinality matters)

라벨의 모든 고유한 집합은 새로운 타임시리즈를 만들어요. 라벨을 주의해서 사용하고 무엇을 넣는지 주의하세요. 카디널리티 폭발을 피하세요. 무한한 라벨은 Prometheus를 폭발시킬 거예요. 라벨은 차원에 걸쳐 곱셈적(multiplicative)이라는 점을 기억하세요.

Prometheus 성능은 거의 항상 한 가지로 귀결된다: 라벨 카디널리티.

항상 카디널리티가 핵심이다를 기억하세요.

이름 짓기는 어렵다 (Naming is hard)

메트릭 이름은 잡 안에서 단일 의미를 가져야 하고, 이상적으로는 잡들 사이에서도 같은 의미를 가져야 해요(process_cpu_seconds_total처럼).

선호(preferences)보다 규칙(conventions)을 존중하세요. 규칙은 누구의 취향도 아니지만, 규칙은 모두의 취향이에요. 세세한 내용은 Naming 문서를 보세요.

카운터가 지배하고 게이지는 형편없다 (Counters rule and gauges suck)

원시 카운터를 노출하고 Prometheus가 rate()와 increase()로 비율을 도출하게 하세요. 타깃에서 비율을 미리 계산하지 마세요. 정보를 버리는 것이니까요. 일단 계측부터, 질문은 나중에를 기억하세요.

물론 게이지도 쓸 자리가 있어요. 셀 것이 그냥 없는 주기적 측정 — 온도, 디스크 포화도, 큐 깊이 — 에 게이지를 사용하세요. 하지만 무언가가 오직 증가만 한다면 카운터로 만드세요.

집계를 위해 메트릭을 추가하지 마세요. PromQL이 해줄 수 있으니까요.

먼저 rate, 그다음 집계 (First the rate, then aggregate)

카운터 리셋을 인지하세요. Rate then sum, never sum then rate에 명시된 대로요. 엄지손가락 규칙으로, 카운터 값에 직접 안전하게 적용할 수 있는 유일한 수학 연산은 rate, irate, increase, resets예요. 다른 것은 무엇이든 문제를 일으킬 거예요.

로그할 수 있으면 메트릭도 만들 수 있다 (If you can log it, you can have a metric for it)

로그는 종종 트러블슈팅에 중요하지만, 메트릭도 똑같이 가치 있어요 — 트러블슈팅 여정은 보통 서로 다른 신호 사이를 오가며 점프하거든요. 무슨 일이 일어나고 있는지 이해하는 데 메트릭의 가치를 과소평가하지 마세요.

이벤트를 로그할 때마다 넓은 범주로 세는 것을 고려하세요. 이것은 저렴하고, 높아진 오류율에 대한 알림과 무슨 일이 일어나고 있는지에 대한 개요를 줘요. 기억하세요, 라벨이 없는 메트릭은 저렴해요 — 카운터를 넉넉히 퍼뜨리세요.

네이티브 히스토그램은 거의 항상 클래식 히스토그램보다 낫다 (Native histograms are almost always better than classic histograms)

네이티브 히스토그램은 클래식 히스토그램의 버킷 레이아웃 문제를 해결해요. 사전 정의된 경계가 필요 없고, 해상도를 동적으로 조정하며, 빈 버킷이 비용이 들지 않는 희소(sparse) 표현을 사용해요. 여러분의 계측 라이브러리나 OTel이 지원한다면, 새 계측에는 네이티브 히스토그램을 선호하세요.

클래식 히스토그램으로 올바른 버킷 레이아웃을 만드는 것은 하나의 예술이에요. 관측의 유용성과 알림의 정확성을 보장하려면 의미 있는 버킷 레이아웃을 고안해야 해요. 이것은 일단 계측부터, 질문은 나중에와 충돌해요. 측정하기 전에 지연시간에 대한 아이디어가 필요하니까요. 여러분의 SLO가 버킷 레이아웃을 이끌게 하세요. SLO에 맞게 경계를 만드세요.

클래식 히스토그램은 바탕에 그냥 라벨이 있는 카운터이며, 버킷 경계가 라벨로 사용돼요. 히스토그램에 추가 라벨을 더할 때는 주의하세요. 라벨은 곱셈적이고 카디널리티가 중요하다는 것을 기억하세요.

그래프로 그릴 수 있으면 알림을 걸 수 있다 (If you can graph it, you can alert on it)

하루 24시간 대시보드를 볼 수는 없어요. Prometheus는 메트릭, 대시보딩, 알림을 통합해요. PromQL은 모든 Prometheus 알림의 핵심이고, PromQL 쿼리는 대시보드의 어떤 그래프의 원천이에요. 그것을 사용하세요.

실행하는 것이 있으면 알림을 걸어야 한다 (If you run it, then you should put an alert on it)

적어도 타깃의 존재와 건강성(healthiness)에 대한 알림은 항상 가져야 해요. 관측하거나 조치할 수 없는 것에 의존할 수는 없어요.

누락되고 건강하지 않은 타깃을 피하세요. Prometheus는 각 타깃에 대해 up 메트릭을 자동으로 생성해요. 그것을 사용하세요.

알림은 긴급하고, 중요하고, 행동 가능하고, 실제여야 한다 (Alerts should be urgent, important, actionable, and real)

알림은 긴급하고, 중요하고, 행동 가능하고, 실제여야 한다. 그 말 그대로예요.

그리고 과도한 알림을 만들지 마세요. 알림 피로(alert-fatigue)는 실재해요.

페이지는 증상 기반, 트러블슈팅은 원인 기반 (Symptom-based alerts for paging, cause-based for troubleshooting)

사용자가 신경 쓰는 것을 측정하세요와 비슷하게, 정말로 중요한 것에 알림을 거세요. 사용자가 알아차리지 못한다면 CPU가 포화됐는지는 중요하지 않아요. 여러분의 SLO가 알림을 이끌게 하세요.

모든 알림이 누군가를 페이지할 필요는 없어요. 원인 기반 알림은 누구도 깨우면 안 돼요 — 그것들은 대시보드나 티켓 큐로 흘러가 필요할 때 확인하거나 여유롭게 배치로 처리하면 돼요. 사용자에게 보이는 영향(user-facing impact)을 나타내는 증상 기반 알림에 페이지를 아껴두세요.

더 많은 맥락은 My Philosophy on Alerting을 보세요.

5분 더 주세요 (Please five more minutes)

Prometheus 알림 규칙은 for 기간을 지정하게 해 주는데, 이것은 알림이 발화하기 전에 조건이 얼마나 오래 참이어야 하는지 결정해요. 지정하지 않으면 단 한 번의 실패한 스크랩이 알림을 발화시킬 수 있어요. 관용(tolerance)이 필요해요. 엄지손가락 규칙으로, 특별한 이유가 없다면 적어도 5분을 사용하세요. 더 많은 정보는 알림 임계값 설정을 확인하세요.

맥락이 왕이다 (Context is king)

알림에 공통적이고 유용한 라벨을 보존하세요. 그것들은 라우팅과 사일런싱에 가장 유용해요.

이 아이디어의 영감은 The Zen of Go, Go Proverbs, The Zen of Python에서 왔어요.

*귀중한 아이디어로 기여한 모든 분들께 감사드립니다.*
초기 규칙은 커뮤니티의 여러 소스에서 모았습니다. 예를 들어 [Björn Rabenstein](https://github.com/beorn7)의 [Prometheus Proverbs](https://www.youtube.com/watch?v=TwH3KXKbJqM), [Julius Volz](https://github.com/juliusv)의 [Best Practices and Beastly Pitfalls](https://www.youtube.com/watch?v=_MNYuTNfTb4), [Bartek Plotka](https://github.com/bwplotka)와 [Kemal Akkoyun](https://github.com/kakkoyun)의 [Patterns for Instrumenting Your Go Services](https://www.youtube.com/watch?v=LU6D5cNeHks), [Simon Pasquier](https://github.com/simonpasquier)의 [Instrumenting Applications and Alerting with Prometheus](https://www.youtube.com/watch?v=sHKWD8XnmmY), 그리고 [Brian Brazil](https://github.com/brian-brazil)의 [Robust Perception Blog](https://www.robustperception.io/blog)을 참고했습니다.

추가 자료 (Further resources)

이 규칙들을 따르면 커뮤니티 도구의 혜택을 받을 수 있어요.

  • Monitoring Mixins — 흔한 서비스를 위한 재사용 가능한 대시보드와 알림

더 알아보기 (Learn more)