모니터링에 대한 정의를 할 수 있어서 좋았음. 어떤 것이 좋은 모니터링이고, 나쁜 것인지 판단할 수 있는 기준이 좀 더 명확해졌고 여러가지 모니터링 종류를 파악할 수 있어서 도움이 되었다.
정의
모니터링
- 쿼리의 수와 종류, 에러의 수와 종류, 처리 시간 및 서버의 활동 시간 등 시스템에 대한 정량적 실시간 데이터를 보여줌
화이트박스 모니터링
- 시스템 내부 지표들을 토대로 하는 모니터링. 내부의 통계 지표
- 중요도가 낮은 서비스들에 대해서는 화이트박스 모니터링 수행
- 로그나 HTTP endpoint 와 같은 시스템의 내부 동작들을 규범에 따라 살펴보는 기법
블랙박스 모니터링
- 사용자가 보게 되는 확인 가능한 동작들을 외부에서 테스트하는 과정을 의미
- 중요한 서비스들에 대해서는 블랙박스 모니터링을 수행
- 서버 상에 나타나는 증상을 기본으로 하며
현재문제가 발생하는 상황을 모니터링 (발생 할 X) - “
시스템이 지금 현재 올바르게 동작하지 않고 있는” 상황 파악
대시보드
- 중요한 지표들을 사용자에게 보여줌
알림
- 노티
근본 원인과 노드, 머신
푸시
- 서비스에 대한 변경사항들
모니터링의 필요성
- 장기적인 트렌드 분석
- 시간순 혹은 실험 그룹에 대한 비교
- 알림
- 당장 수정이 필요하거나, 살펴봐야할 때를 위해
- 대시보드
- 임시적인 회고 분석의 수행 (디버깅)
→ 모니터링이 사람을 호출하는 경우 해당 부분은 비용이 정말 많이 드는 일임!!!
(워치타워 너무 피곤하고 비용이 많이 든다.)
모니터링에 대한 적절한 기대치 설정하기
- 모니터링 시스템에 있어 중요한 것은 최대한 간결하면서도 팀 모두가 이해할 수 있도록 유지하는 것
- →
잘못된 알람(noise) 비율을 낮게 유지하고, 시스템은간결하며안정적이어야 함
- →
증상과 원인
증상: 어떤 장애가 발생했는가- ex) HTTP 500 이나 404 오류
원인: 왜 장애가 발생했는가- ex) 데이터베이스 서버가 연결 요청을 거부함
네 가지 결정적인 지표
지연응답
- 요청이 서비스에 의해 처리되기까지의 시간을 말함
트래픽
- 시스템에 얼마나 많은 요청이 들어오는지를 측정하는 것.
- 초당 HTTP 요청 개수, 성질 등
에러
- 실패한 요청의 비율
- 백엔드 프론트엔드의 케이스가 많이 다를 것 같음
- 우리 서비스에서 4XX 에러는 사용자 에러로 정의하고 응답을 받지않았음. 서비스 설계할 때 5XX 에러를 우리 서버 에러로 판단하였다.
- 다른 사람들은 어떻게?
서비스 포화 상태
- 서비스가 얼마나 포화 상태로 동작하는지를 의미함
- 리소스를 집중해서 측정해야 함
더욱 단순하게가 아니라 최대한 단순하게
- 모니터링 시스템은 일반적으로 고려할 것들이 매우 많기 때문에 복잡해짐. 사용자, 개발자, 기획자들의 요구사항들이 많기 때문에 시스템이 커질 수 밖에 없음.
- 따라서 모니터링 시스템을 디자인할 때는 최대한 간결함을 추구해야함
- 규칙은 최대한 간결하고 예측 가능해야함
- 수정 빈도가 높지 않은 데이터의 수집, 집계, 알림에 관련된 설정을 제거하자
- 수집은 되지만 사용되지 않는 데이터도 제거하자
결론
- 제대로 구성된 모니터링과 알림 파이프라인은 간결하고 명료함.
- 알림을 통해서 증상을 탐지하고, 문제를 디버깅하기 위한 방안을 제시하고, 원인 분석을 통해 스스로 학습하고 성장할 수 있는 기회를 제공해야함
- 이메일 알림은 그다치 큰 가치가 없고 소음처럼 간주되는 경우가 많음.
- 이메일로는 비교적 덜 심각하지만 현재 발생 중인 문제들을 모두 모니터링하는 대시보드로 제공하는게 좋음