글에 들어가기 앞서 ⚡
서비스를 개발하다 보면 서비스가 성장함에 따라 유지보수를 위해 모니터링 시스템을 구축하게 됩니다.
모니터링 시스템 구축 시 어떤 지표를 봐야 하는지, 어떤 상황에 알람이 와야 하는지는 경험적으로 알아가는 경우가 많습니다.
많은 트래픽을 받고 있는 구글의 SRE팀은 해당 고민을 오래전부터 해왔고, 본인들의 경험을 공유했습니다.
이번 포스트에서는 구글에서 공유한 Four Golden Signal로 유명한 monitoring-distributed-system를 번역하고, 중간중간 저의 이해를 공유해보려 합니다.
본 글은 SRE 관점의 모니터링이고, application 관점의 모니터링은 해당 글에서 다루지 않습니다.
왜 모니터링을 해야 하는가?
시스템을 모니터링해야 하는 이유는 아래와 같이 다양합니다.
- long-term 트랜드를 분석
- 상태 비교 (*시간 / 실험에 따라)
- 알람
- dashboard를 구성하기 위해
- ad-hoc관점의 retrospective 분석을 위해 (*ex. 디버깅 등)
시스템을 모니터링 하는 것은 비즈니스에 raw input을 제공하고, 보안 위반을 분석하는데 도움을 줍니다.
모니터링과 알람 시스템은 시스템이 언제 broken 되었는지 알려줍니다. 모니터링 지표들은 break의 원인이나 해결에 관점을 제공할 수 있는 정보를 줄 확률이 높습니다. 시스템이 자동으로 fix 될 수 없을 때, 모니터링 시스템을 통해 전달된 알람을 조사하고, 진짜 문제가 해결될 수 있는지 결정하고, 문제를 완화하고, 문제의 근본적인 원인을 결정하기를 원합니다. 시스템을 구축할 때, 단순히 "뭔가 이상해 보인다"와 같은 알람을 지양하고, 시스템의 매우 좁은 범위로 구분된 컴포넌트에 대한 모니터링을 지향해야 합니다.
사람을 "호출"하는 것은 그 사람의 관점에서 매우 비싼 연산입니다. 개발자가 출근했을 때, "호출"을 당한 개발자는 그의 workflow에 큰 방해를 받게 됩니다. (* context-swtiching은 비싸니까요)
개발자가 집에 있을 때 호출이 발생되면, 개발자의 사적인 시간까지 침해받게 됩니다. (*심지어 잠까지..)
호출이 매우 잦게 이루어지면, 개발자는 각 알람들을 대충 추측하고, 훑어보고, 알람을 무시하게 됩니다. 그렇게 되면, 진짜 문제 상황에 대해서도 해당 알람이 다른 전혀 중요하지 않은 알람들에 누락될 수 있습니다. 다른 noise에 해당되는 알람들이 즉각적인 진단 및 fix를 방해해서 시스템 장애 상태 상태가 더 오래 지속될 수 있습니다.
효율적인 alerting 시스템은 좋은 signal들과 매우 적은 noise로 구성되어야 합니다.
모니터링에 대한 합리적인 기대치 설정하기
복잡한 어플리케이션을 모니터링하는 것은 그 자체로 중요한 엔지니어링 작업입니다. 구글에서는 계측, 수집, 표시, 알림을 위한 충분한 infrastructure이 있어도, 12명의 SRE팀 인원 중 한 명에서 두 명의 인원에게 "모니터링 시스템을 만들고, 유지하는 것"이 메인 업무로 주어집니다. 모니터링해야 하는 업무를 일반화하고 중앙화 함으로써, 모니터링 인원이 줄였지만, 모든 SRE팀은 보통 적어도 한 명의 "monitoring person"을 갖고 있습니다. (*단, "문제를 보기 위해 스크린을 응시하고 있는 상황"을 지양합니다.)
일반적으로, 구글은 사후 분석을 지원하는 간단하고, 빠른 모니터링 시스템을 갖고 있습니다. 구글에서는 threshold를 배우고, 자동으로 인과관계를 감지하는 "magic" 시스템을 지양합니다. end-user의 비율의 급격한 변화를 감지하는 규칙과 같이 규칙을 매우 간단하게 유지할 수 있지만, 규칙이 매우 단순하고 구체적이기 때문에, 심각한 이상현상을 매우 빠르게 감지할 수 있습니다.
Symptom VS Causes
모니터링 시스템은 "시스템에서 무엇이 broken 되었는지?" "시스템이 왜 broken 되었는지?"에 대한 질문을 답할 수 있어야 합니다.
Symptom은 "무엇이 broken 되었는지?"라고, Cause는 "왜 broken 되었는지"에 해당됩니다.
아래는 예시입니다.
| Symtom | Cause |
| HTTP 상태코드 500s or 404s를 서빙 | DB 서버가 connection을 거부 |
| response time이 느림 | CPU가 overload되거나 내부 케이블이 프레임 아래에서 꼬여서 부분적인 패킷 손실이 발생 |
| Private content가 world readable한 상황 | ACL을 깜빡해서 모든 요청들이 허용되는 소프트웨어가 push됨 |
"What"과 "Why"를 구분하는 것은 최대한의 Signal과 최소한의 noise로 구성된 모니터링 시스템을 구축하는데 매우 중요합니다.
Black-Box VS White-Box
구글에서는 다량의 white-box 모니터링과 적지만 크리티컬 한 black-box 모니터링을 결합하여 사용합니다. black-box 모니터링과 white-box 모니터링을 비교하는 가장 간단한 방법은 black-box 모니터링은 symptom-oriented 하고, active 한 문제를 나타낸다는 것입니다. (예측 x) (ex. 현재 시스템에 장애가 있다.) white-box 모니터링은 로그, http endpoint, 계측과 같은 시스템의 내부를 점검하는 능력에 의존합니다. 즉, white-box 모니터링은 retry에 감춰진 임박한 문제와 실패의 detection을 가능하게 해 줍니다.
Multi-layer system에서 누군가의 Symptom은 다른 사람의 casue가 됩니다. 예를 들어, DB 성능이 느린 상황을 가정해 봅시다. 느린 데이터베이스 read는 database SRE팀에서 symptom이 됩니다. 하지만, 느린 웹사이트를 관측하는 프론트엔드 SRE에게는 느린 데이터베이스 읽기는 cause가 됩니다. 그러므로 화이트박스 모니터링은 당신의 화이트박스가 얼마나 informative 한 지에 기반해 종종 symptom-oriented가 되고, 종종 cause-oriented가 됩니다.
디버깅을 위한 telemetry를 수집할 때 white-box 모니터링은 필수적입니다. 웹사이트가 데이터베이스의 무거운 리퀘스트로 느려 보인다면, 웹서버가 데이터베이스를 얼마나 빠르게 인식하는 지와, 데이터베이스가 자신을 얼마나 빠르다고 믿는지 둘 다 알아야 합니다. 그렇지 않는다면, 느린 DB 서버와 네트워크 문제 중 어떤 것이 원인인지 구분할 수 없게 됩니다.
paging의 경우, 블랙박스 모니터링은 문제가 이미 진행 중이고, 실제 증상을 유발할 때만 알리도록 강제하는 이점이 있습니다. 반면 아직 발생하지 않았지만 임박한 문제에 대해서는 블랙박스 모니터링은 거의 쓸모가 없습니다.
The Four Golden Signals
모니터링의 4개의 Golden signal은 latency, traffic, error, saturation입니다. 만약 시스템의 4개의 메트릭만 측정할 수 있다면, 아래 4개의 메트릭에 집중하면 좋습니다.
Latency
Latency는 요청이 걸린 시간을 뜻합니다. (=응답 시간) 성공된 요청과 실패된 요청의 latency를 구분하는 것이 중요합니다. 예를 들어 db나 다른 critical 한 backend로의 connection loss로부터 발생된 500 에러는 매우 빠르게 서빙될 수 있습니다. 반면 해당 실패된 요청으로 발생된 latency들은 전체 레이턴시를 misleading 하도록 만들 수 있습니다. 또한 느린 에러는 빠른 에러보다 안 좋습니다. 따라서 error요청에 대한 latency를 따로 트래킹 하는 것이 중요합니다.
Traffic
트래픽을 측정하는 것은 모니터링 중인 시스템에 얼마나 많은 수요가 있는지 측정하는 것을 뜻합니다. 웹 서비스에 대해서는, 보통 초당 HTTP 요청 수 (RPS)로 측정을 하고 요청의 성격에 따라 구분될 수 있습니다. audio streaming 시스템에 대해서는, 네트워크 I/O나 concurrent session수로 측정될 수 있습니다. key-value 스토리지 시스템에 대해서는 초당 transaction과 검색 수로 측정될 수 있습니다.
Errors
explicit 한 에러와 implicit 한 에러 요청과 정책에 따른 요청 비율을 측정해야 합니다. 예를 들어, explicit 한 에러는 5XX HTTP요청을, implicit 한 에러는 200 요청이지만, 잘못된 콘텐츠를 포함하고 있는 경우를, policy는 응답시간이 1초 내로 기대되는데 1초 이상의 모든 요청을 error로 간주할 수 있습니다. response code의 프로토콜이 모든 실패 상태를 표현하기에 불충분할 때, 이차적인(내부) 프로토콜이 부분적 실패 모드들을 트래킹 하는데 필요할 수 있습니다. 이 케이스들을 모니터링하는 것은 크게 다를 수 있습니다. 로드벨런서에서 500 에러들을 잡는 것은 모든 완전히 실패한 request들을 잡는 것의 괜찮은 작업이 될 수 있습니다. 다만, 잘못된 컨텐츠를 서빙하는 것을 감지하는 것은 오직 e2e 시스템 테스트에서만 가능합니다.
Saturation
얼마나 서비스가 찼는지를 측정해야 합니다. 가장 제약이 큰 리소스를 강조해서 시스템을 비율로 표현하는 것입니다. 예를 들어 메모리에 bound 된 시스템은, 메모리의 포화율을 비율로 보여주고, I/O에 bound 시스템은 I/O 포화율을 비율로 표현해야 합니다. 많은 시스템이 퍼포먼스가 100% utilization이 되기 전에 악화된다는 점을 꼭 명심해야 합니다. 따라서 utilization target을 갖는 것은 매우 필수적입니다.
복잡한 시스템에서 saturation은 더 높은 수준의 부하 측정을 통해 보완될 수 있습니다. 현재 서비스가 현재 요청에 대비해서 어느 정도 요청을 처리할 수 있는지는 알기 쉽지 않습니다. 충분히 단순한 (요청의 복잡성을 변경하는 매개변수가 없는) 서비스들은 드물게 configuration이 변경되기 때문에, 부하 테스트에서 나온 고정된 값이 충분할 수 있습니다. 하지만 대부분의 서비스는 충분히 복잡합니다. 따라서 대부분의 서비스는 알려진 upperbound가 있는 CPU utilization이나 네트워크 대역폭과 같은 간접적인 신호를 사용할 필요가 있습니다. latency의 증가는 종종 saturation의 앞선 지표로 볼 수 있습니다. 작은 윈도우(ex 1 min)에서 99번째 응답시간을 측정하는 것은 saturation 포화 전에 우선 적인 빠른 시그널을 줄 수 있습니다.
마지막으로, saturation은 또한 임박한 saturation의 예측을 포함할 수 있습니다. 예를 들어 "DB가 4시간 내에 하드드라이브가 꽉 찰 예정인 상황" 같은 상황을 예측할 수 있습니다.
모든 4개의 golden signal을 측정하고, 한 시그널이 문제 있을 때, 사람에게 알람을 보낸다면, 서비스는 모니터링에 의해 어느 정도 제대로 보호받을 것입니다.
Worrying About Your Tail (or, Instrumentation and Performance)
모니터링 시스템을 처음부터 구축해야 할 때, 몇 quantity(ex. latency, node의 CPU usage, DB의 fullness)의 평균에 기반해 시스템을 디자인하려 시도합니다. CPU와 DB의 fullness의 평균을 보는 것의 위험성은 자명합니다. CPU와 DB는 쉽게 불균형한 방식으로 utilized 될 수 있습니다. latency에 대해서도 동일합니다. 웹사이트의 RPS1000에 평균 latency가 100ms이면, 1%의 요청은 쉽게 5초 (*포아송 분포)가 걸릴 수 있습니다. 만약 유저들이 여러 해당 웹 서비스에 의존해서 페이지를 랜더링한다면, 백앤드 중 하나가 99%의 응답시간으로 응답하는 것이 쉽게 프론트엔드의 median response가 될 수 있습니다.
느린 평균과 매우 느린 tail 요청을 구분하는 가장 간단한 방법은 실제 latency 값을 구하는 것보다 latency별 버킷으로 request들의 수를 세는 것입니다. (ex. 0ms~10ms 10ms~30ms 30ms~100ms 100ms~300ms). 히스토그램의 경계를 exponential 하게 분포(이 케이스에서는 3의 배수)시키는 것이 요청의 분포를 시각화하는 쉬운 방법입니다.
Choosing an Appropriate Resolution for Measurements
시스템의 다양한 측면은 다른 수준의 세밀함으로 통해 측정돼야 합니다.
- 분단위의 CPU load를 관측하는 것은 high-tail latency를 유발하는 long-lived spike를 나타내지 않습니다.
- 다른 의미로, 1년에 9시간 이하의 다운타임을 보장하는 웹 서비스에 대해 200 status code를 1분에 1~2번 probing 하는 것은 불필요한 반복입니다.
- 비슷하게 99.9% availability를 의도한 서비스에서 하드 드라이브의 가득 찬 정도를 1~2분마다 체크하는 것은 아마 불필요합니다.
각 메트릭에 대해 측정의 정밀도를 어떻게 구성하는지에 주의를 기울여야 합니다. CPU 로드를 매 초마다 측정하는 것은 흥미로운 데이터를 보여줄 것입니다. 하지만 해당 측정은 측정, 저장, 분석에 매우 많은 비용이 필요합니다. 만약 모니터링의 목표가 고해상도가 필요하지만, 낮은 수준의 latency를 요구하지 않는 경우, 이러한 비용을 내부 샘플링을 시행하고, 외부 시스템에서 분포를 시간 또는 서버 간에 수집, 집계하도록 구성함으로써 줄일 수 있습니다.
- 매 초 CPU utilization을 기록합니다.
- 5%의 세밀함을 갖는 bucket을 사용해, 매 초 적절한 CPU utilization bucket을 더합니다.
- 매 분마다 해당 값들을 집계합니다.
이 전략은 수집과 관측에서 많은 비용을 일으키지 않으면서 신뢰할 수 있는 CPU hotspot들을 관측할 수 있게 해 줍니다.
As Simple as Possible, No Simpler
이 모든 요구사항을 겹쳐놓는 것은 매우 복잡한 모니터링 시스템이 될 수 있습니다. 아마 시스템은 다음과 같은 복잡성 수준에 도달하게 될 겁니다.
- 다양한 latency threshold, 다양한 퍼센트, 다양한 종류에 메트릭에 대해 알람
- 가능한 원인을 감지하거나 드러내기 위한 추가적인 코드
- 각 가능한 cause에 대한 대시보드
가능한 복잡성의 원천은 끝나지 않습니다. 모든 소프트웨어 시스템과 같이, 모니터링은 매우 복잡해서 부서지기 쉽고, 변경 사항을 적용하기 어렵고, 유지보수하기 힘들어질 수 있습니다.
따라서 모니터링 시스템을 설계할 때 simplicity를 염두에 두고 설계해야 합니다. 무엇을 모니터링할지 선택함에 있어서, 다음 가이드를 꼭 생각하세요.
- 진짜 사고를 캐치할 수 있는 규칙은 거의 단순하고, 예측 가능하고, 가능한 믿을만해야 합니다.
- 드물게 실행되는 데이터 수집, 집계, 알람 설정은 제거 대상이어야 합니다.
- 수집되지만, 대시보드나 알람에 사용되지 않는 signal들은 제거 대상입니다.
Tying These Principles Together
위 내용들에서 언급된 원칙들은 Google SRE팀에서 널리 지지되고 따르는 모니터링, 알람 철학으로 결합될 수 있습니다. 이 모니터링 철학들이 약간 열망적인 느낌이 있지만, 이는 새로운 알람을 작성하고, 리뷰하는데 좋은 시작 포인트입니다. 그리고 이것은 서비스나 시스템의 복잡도나 조직의 크기에 무관하게 조직이 적절한 질문에 답변하게 해 줍니다.
모니터링이나 알람에 대한 규칙을 만들 때, 다음 질문들을 묻는 것은 false positive 한 알람이나 pager이 burnout 오는 것을 막아줍니다.
- 이 규칙이 긴급하고, 조치 가능하고, 즉시 유저에게 노출되는 미탐 된 상태를 감지할 수 있는지?
- 알람이 심각하지 않은 것을 알았을 때, 무시할 수 있는지? 언제 그리고 왜 이 알람을 무시할 수 있는지? 그리고 어떻게 그 시나리오를 피할 수 있는지?
- 이 알람이 유저들이 부정적인 영향을 받고 있다는 것을 확실히 의미하는지? 트래픽 감소나 테스트 배포와 같이 유저들이 부정적인 영향을 받지 않는 경우, 필터링되어야 하는 감지 가능한 경우가 있는지?
- 이 알람에 대응하는 액션을 취할 수 있는지? 그 액션이 긴급한지? 혹은 아침까지 기다릴 수 있는지? 그 액션이 안전하게 자동화될 수 있는지? 그 액션이 오랜 기간 fix 되어야 하는지 혹은 짧은 기간 동안 처리될 수 있는지?
- 적어도 하나의 불필요한 page를 랜더링 하기 위해, 다른 사람들이 이 이슈에 대해 page 받고 있는지?
이 질문들이 page와 pagers에 대한 근본적인 철학을 반영하고 있습니다. :
- 페이저가 울릴 때마다, 긴급하게 반응할 수 있어야 합니다. 하루에 몇 번 이상 긴급하게 반응하기 전에 피로해질 수 있습니다.
- 모든 page는 대응 가능해야 합니다.
- 모든 page 응답은 지능을 요구해야 합니다. page가 단순히 기계적인 반응을 요구한다면, page로 구성되면 안 됩니다.
- page들은 새로운 문제이거나, 전에 보지 못한 이벤트에 관련된 것이어야 합니다.
이러한 관점은 특정 구분들을 희석시킵니다. 만약 page가 앞서 언급된 4가지 요건들을 충족시킨다면, 페이지가 화이트박스 모니터링에 의해 트리거 되었는지 블랙박스 모니터링에 의해 트리거 되었는지는 중요하지 않습니다. 이 관점은 특정한 구분을 강화합니다: 원인에 대한 경우, 확실하고 임박한 원인에만 신경 써야 합니다.
Monitoring for the Long Term
현대 production system에서, 모니터링 시스템은 소프트웨어구조, 부하 특성, 성능 목표가 바뀌는 지속적으로 발전하는 시스템을 모니터링합니다. 매우 드물고 자동화하기 어려운 알람이 자주 발생할 수 있습니다. 심지어 해결을 위해 스크립트가 필요할 수도 있습니다. 이 시점에서, 누군가는 문제의 근본적인 원인을 찾아서 제거해야 합니다. 이러한 해결이 불가능한 경우, 경고에 대한 대응은 완전히 자동화되어야 합니다.
모니터링에 관헌 결정은 장기적인 목표를 염두에 두고 결정되는 것은 중요합니다. 모든 오늘 발생한 page는 누군가 내일 시스템을 개선하는 것을 방해가 됩니다. 따라서, 장기적인 시스템의 전망을 개선하기 위해 가용성이나 성능을 단기적으로 희생하는 것이 종종 필요합니다. trade-off를 설명하는 두 케이스를 봅시다.
Bigtable SRE: A Tale of Over-Alerting
구글의 내부 인프라 구조는 일반적으로 서비스 수준 목표(SLO; Service Level Objective)에 대해 제공되고 측정됩니다. 수년 전에, Bigtable service의 SLO는 합성적이고 원활하게 작동되는 클라이언트의 평균 성능에 기반되었습니다. Bigtable과 저장 스택의 하위 계층에서의 문제로, 평균 성능은 "큰" 꼬리에 의해 좌우되었습니다. 종종 최악의 5% 요청이 나머지보다 훨씬 느렸습니다.
SLO에 근접할 때 이메일 경고가 발생했고, SLO를 초과하면 paging(호출) 알람이 발생했습니다. 두 종류의 알람은 대량으로 발생했고, 합리적이지 못한 양의 엔지니어링 시간을 소모했습니다. 팀은 실제로 실행 가능한 몇 가지를 찾기 위해 경고를 분류하는데 상당한 시간을 보냈으며, 실제로 사용자에게 영향을 미치는 문제를 전체 경고 중 소수였고, 종종 놓쳤습니다. paging(호출)중 대부분이 긴급하지 않았으며, 인프라에 이미 이해된 문제 때문이었고, 루틴한 대응을 하거나, 아무런 대응도 할 수 없었습니다.
해당 상황을 해결하기 위해, 팀은 3가지 접근 방법을 사용했습니다. Bigtable의 성능을 향상시키기 위해 많은 노력을 할당하면서, 일시적으로 SLO 목표를 후퇴시켜 75%의 요청 latency를 사용했습니다. 또한 너무 많은 이메일 경고가 있어 진단이 불가능했기 때문에, 이메일 알람을 비활성화했습니다.
이 전략은 적인 전술적 문제 해결만 진행하는 것 대신 Bigtable과 저장 스택의 하위 계층에서 longer-term problem을 고칠 수 있는 충분한 여유를 제공했습니다. 당직 엔지니어는 paging(호출)로 깨어있지 않은 모든 시간 동안 다른 실제 작업에 몰두할 수 있었습니다. 궁극적으로, 경고를 일시적으로 늦추는 것이 더 나은 서비스를 향한 더 빠른 진전을 가능하게 했습니다.
Gmail: Predictable, Scriptable Responses from Humans
Gmail 초창기에, 서비스는 Workqueue라 불리는 보강된 분산 프로세스 관리 시스템위에서 구축되었습니다. Workqueue는 검색 index의 일부를 배치프로세싱하기 위해 만들어졌습니다. Workqueue는 long-lived 프로세스에 적용되었고, 이후 Gmail에 적용되었습니다. 하지만 스케쥴러에서의 비교적 불투명한 코드베이스에서 특정 버그는 해결하기 까다로웠습니다.
그 당시, Gamil 모니터링은 각 개별 task가 Workqueue로 부터 de-schedule되었을 때 알람을 발생시키도록 구축되었습니다. 이 설정은 이상적이지 않습니다. 당시에 조차 Gmail은 수천개의 task를 갖고있었고, 각 task는 유저의 일부를 나타냈기 때문입니다. Gmail을 사용하는 유저들에게 좋은 유저 경험을 위해 노력하지만, 해당 알람 설정은 유지 불가능했습니다.
이 문제를 해결하기 위해, Gmail SRE는 유저에게 영향을 최소화 하도록 스케줄러를 적절한 방식으로 조작하는 것을 돕는 tool을 개발했습니다. 팀은 더 나은 long-term solution이 달성될 때 까지 문제를 감지 ~ 재스케줄링에 해당되는 전체 루프를 단순히 자동화 할지 말지를 여러번 논의했습니다. 하지만 몇몇은 이러한 해결책이 실제 문제 해결을 딜레이할 것을 걱정했습니다.
이런 긴장감은 팀 내에 흔하고, 종종 팀의 자기 조절에 대한 불신을 나타냅니다. 일부 팀원들은 적절한 fix를 위한시간을 허용하기 위한 "hack"을 구현하는 것을 원하는 반면, 일부 팀원들은 해당 "hack"이 원래 문제를 잊게 만들거나 적절한 수정이 무기한 우선순위가 낮아질 것을 걱정합니다. 이러한 걱정은 신빙성이 있습니다. 진짜 문제의 해결을 만드는 것 대신 문제 위애 패칭하는 유지 불가능한 기술 부채의 layer을 쌓는 것은 쉽습니다. 매니저들과 기술 리더들은 paging(호출)의 고통이 가라앉을 때 조차 잠재적으로 시간이 소요되는 long-term fix들에 우선순위를 높임이고 지원함으로써 , 제대로 된 long-term fix들을 구현하는데 핵심 역할을 수행합니다.
반복적이고, 알고리즘적인 반응을 해야 하는 Paging(호출)은 경고 신호가 되어야 합니다. 팀이 이런 Paging(호출)을 자동화 하려는 노력을 기울이지 않는 것은 기술 부채를 정리할 수 있다는 자신감이 부족하다는 것을 위미합니다. 이것은 확대할 가치가 있는 우선순위 높은 중요한 문제입니다.
The Long Run
Bigtable과 Gamil의 예시들에는 공통된 주제가 있습니다. short-term과 long-term사이의 긴장감 입니다. 종종 노력의 순수한 힘은 곧 무너질듯한 시스템이 high availability를 충족시키는 것을 도울 수 있습니다. 하지만 해당 방식은 보통 short-lived하고, 번아웃과 소수의 영웅적인 팀 구성원에 대한 의존성으로 가득차있습니다. 가용성을 단기간 감소시키는 것은 종종 고통스럽지만, 시스템의 장기적인 안정성과의 전략적인 교환이 될 수 있습니다. 모든 paging을 독립된 사건으로 생각하는 것이 아니라 모든 수준의 paging이 건강하고 실행 가능한 팀과 long-term 전망과 함께 건강하고, 적절하게 유효한 시스템으로 이끌 수 있는지를 고려하는 것이 중요합니다.paging 주기에 관한 통계 (보통 교대당 사건 수로 표현되고, 하나의 사건은 여러 paging으로 구성될 수 있습니다.) 에 대해 검토하여, 의사결정자들이 pager에 대한 부하와 그들의 팀의 전체적인 건강 상태를 최고로 유지하도록 해야 합니다.
Conclusion
건강한 모니터링과 알람 파이프라인은 추론하기에 간단하고 쉽습니다. 해당 모니터링은 주로 paging을 위한 symtop, cause-oriented된 문제들을 디버깅하는데 초점을 맞춘 수단으로서 휴리스틱을 서빙하는 것을 예약하는데 집중합니다. 모니터링 symptop(증상)은 stack을 "위"에서 모니터링할 수록 더 모니터링 하기 쉽지만, DB와 같은 subsystem의 포화와 성능을 모니터링 하는 것은 종종 subsystem 자체에서 실행되어야 합니다. 이메일 알람은 매우 제한적인 가치로 이루어져 있고, 쉽게 잡음으로 넘처납니다. 대신 일반적으로 이메일 경고에 들어가는 종류의 정보와 관련된 모든 중요도가 낮은 문제들을 모니터링하는 dashboard를 선호해야 합니다. 대시보드는 시간에 따른 상관관계를 분석하기 위해 로그와 함께 사용될 수 있습니다. 장기적인 관점에서, 성공적인 on-call 로테이션과 제품을 달성하는 것은 실제 달성 가능한 목적으로 목표를 조정하고, 모니터링이 빠른 진단을 도와주는 것을 확실히 하면서 symtom이나 임박한 실제 문제를 알람하는 것을 선택하는 것을 포함합니다.