지속적인 튜닝을 수행하여 의미 없는 경고 줄이기
이 단원에서는 사이트 안정성을 모니터링하기 위해 구현할 수 있는 프로세스에 대해 알아봅니다. 경고를 지속적으로 튜닝하여 의미 없는 경고를 줄이는 방법도 알아봅니다.
모니터링 및 경고
모니터링 및 경고를 통해 사용자에게 시스템이 중단된 경우를 알려주며 곧 중단될 항목을 알려줄 수도 있습니다. 사용자가 문제를 조사해야 하는 경우 경고에서 사용자가 시작할 위치를 알 수 있도록 관련 정보를 제공해야 합니다.
기존 경고를 검토하거나 새 경고 규칙을 작성하는 경우 다음 지침을 고려하여 경고 관련성을 높이고 더욱 이상적인 대기 순환 체계를 확립하세요.
- 사용자의 주의를 트리거하는 경고는 긴급하고 중요하며 작업 지향적이고 실제여야 합니다.
- 경고는 서비스에 대한 진행 중이거나 임박한 문제가 있음을 나타내야 합니다.
- 노이즈 경고를 제거합니다. 과도한 모니터링은 부족한 모니터링보다 해결하기 어려운 문제입니다.
- 다음 범주 중 하나로 문제를 분류합니다.
- 사용 가능성 및 기본 기능.
- Latency.
- 정확성.
- 기능 관련 문제.
- 증상은 더 적은 노력으로 문제를 포괄적이고 강력하게 캡처하는 더 좋은 방법입니다.
- 증상 기반 페이지 또는 대시보드에 원인 기반 정보를 포함하지만 원인에 대한 직접적으로 경고하지는 않습니다.
- 제공 스택이 늘어날수록 단일 규칙으로 고유한 문제를 더 많이 파악하게 됩니다. 하지만 현재 상황을 충분히 구분할 수 없을 정도로 많이 진행하지 마세요.
- 조용한 대기 순환을 원하는 경우 적시에 응답해야 하지만 긴급하게 중요하지는 않은 문제를 처리하는 시스템을 마련하세요.
사용자에 대한 모니터링
사용자에 대한 모니터링은 증상 기반 모니터링이라고도 합니다. 이 모니터링은 원인 기반 모니터링과는 다릅니다. 사용자는 데이터 푸시 실패 여부는 중요하게 생각하지 않지만 해당 결과가 최신인지는 중요하게 생각합니다.
일반적으로 사용자는 다음을 중요하게 생각합니다.
- 기본 사용 가능성 및 정확성: 어떤 방식으로든 핵심 서비스가 중단되게 하는 모든 사항은 사용 불가능으로 분류되어야 합니다.
- 대기 시간: 페이지가 빠르게 로드되어야 합니다.
- 완전함, 최신 및 내구성: 사용자의 데이터는 안전하고 빠르게 다시 제공되어야 하며 검색 인덱스는 최신 상태여야 합니다.
- 작동 시간: 서비스를 일시적으로 사용할 수 없는 경우에도 사용자는 서비스가 곧 백업될 것이라는 완전한 확신이 있어야 합니다.
- 기능: 사용자는 서비스의 모든 기능이 작동하는지를 중요하게 생각합니다. 핵심 기능이 아닌 경우에도 서비스의 중요한 측면에 해당하는 모든 사항을 모니터링합니다.
데이터베이스 서버를 사용할 수 없는 경우와 사용자 데이터를 사용할 수 없는 경우에는 미묘하지만 중요한 차이가 있습니다. 전자는 직접적인 원인이며 후자는 증상입니다.
제자리가 있는 원인 기반 경고
경고할 증상은 없지만 상황에 대한 경고를 받아야 하는 경우도 있습니다. 메모리가 부족한 상태를 예로 들 수 있습니다. 증상이 발생하기 전에 문제가 될 수 있는 이슈를 알리는 규칙을 원합니다. 이러한 경우 해당 조건에 대해 경고하는 규칙을 작성할 수 있습니다.
그러나 다른 방법으로 파악할 수 있는 증상에 대해 호출 경고를 트리거하는 원인 기반 규칙을 작성하지 마세요.
티켓, 보고서, 메일
곧 주의를 기울여야 하지만 당장은 아닌 경고는 ‘결정적으로 중요하지 않은 경고’입니다. 다음은 나중에 후속 조치가 필요한 임계 미만의 경고를 로그하기 위한 몇 가지 제안 사항입니다.
- 버그 또는 티켓 추적 시스템은 이러한 유형의 경고에 유용할 수 있습니다: 동일한 경고가 단일 티켓 또는 버그에 올바르게 배치되는 한 경고가 버그를 열 수 있습니다. 그런 다음 해당 버그는 후속 조치를 수행하기 위해 다른 사용자에게 할당될 심사 프로세스를 거칠 수 있습니다. 이러한 유형의 문제는 심각해지기 전에 해결해야 합니다. 버그를 수정하는 데 사용할 수 있는 팀원의 시간이 어느 정도인지 고려하세요.
- 일일(또는 더 잦은 빈도의) 보고서가 유용할 수 있습니다: 모든 활성 경고를 표시하는 보고서에 데이터베이스가 90% 넘게 찬 상태와 같이 오래 지속되는 임계 미만의 경고를 작성하세요. 해당 보고서를 매일 심사하도록 사람을 배정합니다.
- 모든 경고는 워크플로 시스템을 통해 추적되어야 합니다: 이것은 경고가 표시되고 처리되도록 합니다.
일반적으로 응답성에 대한 책임을 승격하지만 즉각적인 사용자 개입에 대한 높은 비용은 수반하지 않는 시스템을 만듭니다.
플레이북
Runbook이라고도 하는 플레이북은 경고 시스템의 중요한 부분입니다. 플레이북에 증상을 파악하는 각 경고 또는 경고 모음에 대해 수행할 작업을 설명하는 항목을 두세요.
추적 및 책임
다른 사람이 경고를 수신하고 문제가 없다고 확인하는 경우 이는 해당 규칙을 제거하거나 수준을 내리거나 다른 방법으로 데이터를 수집하라는 신호입니다. 정확도가 50% 미만인 경고는 중단된 것으로 간주됩니다. 10%의 시간에 가양성을 트리거하는 경고도 다시 평가해야 합니다.
모든 트리거된 대기 경고를 매주 검토하고 분기별 경고 통계를 분석하면 개별 경고에 집중하느라 잃어버린 패턴을 확인할 수 있습니다.
언제 규칙에서 예외를 검색하나요?
위의 지침을 중단하는 몇 가지 이유는 다음과 같습니다.
실제로 증상의 노이즈에 숨겨진 알려진 원인이 있습니다: 예를 들어 서비스의 사용 가능성이 99.99%이지만 0.001%의 요청이 실패하도록 하는 공통 이벤트가 있는 경우 이는 노이즈이므로 증상으로 경고할 수는 없지만 원인이 되는 이벤트를 파악할 수는 있습니다.
데이터 해결이 손실되므로 진입점에서 모니터링할 수 없습니다: 예를 들어 신용 카드 유효성 검사와 같은 일부 엔드포인트가 느려지는 것을 허용합니다. 부하 분산 장치에서 이러한 구분이 손실될 수 있습니다. 스택을 검토하고 구별할 수 있는 최고의 위치에서 경고해야 합니다.
증상이 너무 늦을 때까지 나타나지 않습니다: 예를 들어 할당량이 부족합니다. 너무 늦기 전에 누군가에게 경고해야 하는데 경우에 따라 이는 경고할 원인을 찾는 것을 의미합니다. 예를 들어 사용량이 80%를 초과하므로 지난 1시간의 증가율에 따르면 4시간 이내에 부족해질 것입니다.
하지만 덜 긴급하지만 유사한 원인을 찾을 수도 있습니다. 예를 들어 할당량은 90%를 초과하며 마지막 날의 증가율에 따르면 4일 이내에 부족해질 것입니다. 이러한 상황 세트는 대부분의 경우를 파악합니다. 그러면 경고가 나타내는 마지막 에스컬레이션이 아닌 티켓 또는 메일 경고나 일일 문제 보고서로 해당 문제를 처리할 수 있습니다.
경고 설정은 검색하려는 문제보다 더 복잡합니다: 간단하고 강력하며 자체적으로 보호하는 시스템을 만드는 것이 목표가 되어야 합니다.