> For the complete documentation index, see [llms.txt](https://teamsmiley.gitbook.io/devops/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://teamsmiley.gitbook.io/devops/monitoring/0.what-is-monitoring.md).

# 0. What is Monitoring

오늘날의 최신 시스템에서는 방대한 수의 메트릭이 생성 및 수집될 수 있어 문제를 효과적으로 진단하는 데 어려움이 있습니다. 데이터의 양이 너무 많으면 어디서부터 조사를 시작해야 할지 결정하기 어려울 수 있습니다. 적극적으로 진단하지 않는 경우에도 사용 가능한 데이터의 양이 압도적으로 많기 때문에 문제가 존재하는지 여부를 파악하는 것 역시 마찬가지로 어려울 수 있습니다.

다음 방법을 시도해 보세요.

* USE
* RED
* Four Golden Signals

## USE

브렌든 그레그의 사용 제안

"중요한 부분을 간과하지 않고 일반적인 성능 문제를 신속하게 해결하는 방법을 다른 사람들에게 가르치기 위해 USE 방법을 개발했습니다. 비행 매뉴얼의 비상 체크리스트처럼 간단하고, 간단하며, 완전하고, 빠르도록 고안되었습니다."

* Utilization (활용도): 사용률은 리소스(예: CPU, 메모리, 디스크 또는 네트워크)가 사용되는 정도를 측정합니다. 현재 사용 중인 사용 가능한 리소스의 비율 또는 백분율을 나타냅니다. 사용률이 높으면 리소스 병목 현상 및 잠재적인 성능 문제를 나타낼 수 있습니다.
* Saturation(포화도): 포화도는 시스템 내에서 발생하는 리소스 혼잡 또는 대기열의 수준을 나타냅니다. 리소스가 최대 용량까지 활용되고 있는 정도를 나타냅니다. 포화 수준이 높으면 리소스에 부하가 많이 걸려 응답 시간이 지연되거나 늘어날 수 있습니다.
* Errors(오류): 오류는 시스템 내에서 발생한 오류 또는 장애의 수를 나타냅니다. 여기에는 애플리케이션 오류, 시스템 충돌 또는 네트워크 장애와 같은 비정상적이거나 예기치 않은 이벤트가 모두 포함됩니다. 오류를 모니터링하면 시스템 안정성 문제와 개선이 필요한 잠재적 영역을 파악하는 데 도움이 됩니다.

관리자와 시스템 운영자는 사용량 지표를 모니터링함으로써 리소스 사용률을 종합적으로 파악하고, 잠재적인 병목 현상을 파악하고, 성능 문제를 사전에 해결할 수 있습니다. 이 정보는 용량 계획, 리소스 할당 최적화, 시스템의 전반적인 상태와 효율성 보장에 유용합니다.

## RED

<https://www.slideshare.net/weaveworks/monitoring-microservices>

* Rate(비율): 비율은 특정 기간 동안 처리된 요청의 수를 나타냅니다. 시스템의 트래픽 부하를 평가하고 특정 시간 간격 동안 요청량의 증가 또는 감소를 추적하는 데 도움이 됩니다. 비율이 급격히 증가하면 시스템에 부하 또는 수요가 많다는 것을 나타낼 수 있습니다.
* Errors(오류): 오류는 처리 중에 발생한 오류의 수를 나타냅니다. 이를 통해 시스템의 오류 빈도를 추적하고 오류의 유형과 원인을 파악할 수 있습니다. 오류 수가 증가하면 시스템 안정성 및 신뢰성에 문제가 있음을 나타낼 수 있습니다.
* Duration(지속 시간): 지속 시간은 작업 또는 작업을 수행하는 데 걸리는 시간을 측정합니다. 시스템 처리 속도를 평가하고 지연 또는 성능 저하를 식별하는 데 도움이 됩니다. 지속 시간이 예기치 않게 길거나 증가하면 성능 개선이 필요한 영역을 강조 표시할 수 있습니다.

이는 USE 메서드처럼 리소스 범위가 아닌 요청 범위로 제한됩니다. 기간은 평균이 아닌 분포를 의미하는 것으로 명시적으로 간주됩니다.

## Four Golden Signals

<https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals>

모니터링의 Four Golden Signals는 지연 시간, 트래픽, 오류, 포화 상태입니다. 사용자 대면 시스템의 네 가지 지표만 측정할 수 있다면 이 네 가지 지표에 집중하세요.

* 지연 시간(Latency) 요청을 처리하는 데 걸리는 시간입니다. 성공적인 요청의 지연 시간과 실패한 요청의 지연 시간을 구분하는 것이 중요합니다. 예를 들어 데이터베이스나 기타 중요한 백엔드에 대한 연결이 끊어져 트리거된 HTTP 500 오류는 매우 빠르게 처리될 수 있지만, HTTP 500 오류는 실패한 요청을 나타내므로 전체 지연 시간에 500을 고려하면 잘못된 계산이 나올 수 있습니다. 반면에 느린 오류는 빠른 오류보다 더 심각한 문제입니다! 따라서 단순히 오류를 필터링하는 것이 아니라 오류 지연 시간을 추적하는 것이 중요합니다.
* 트래픽(Traffic) 시스템에 얼마나 많은 수요가 발생하고 있는지를 측정하는 지표로, 높은 수준의 시스템별 메트릭으로 측정됩니다. 웹 서비스의 경우 이 측정값은 일반적으로 초당 HTTP 요청 수이며, 요청의 특성(예: 정적 콘텐츠 대 동적 콘텐츠)에 따라 세분화될 수 있습니다. 오디오 스트리밍 시스템의 경우, 이 측정은 네트워크 I/O 속도 또는 동시 세션에 초점을 맞출 수 있습니다. 키-값 저장 시스템의 경우, 이 측정은 초당 트랜잭션 및 검색 수일 수 있습니다.
* 오류(Errors) 명시적으로(예: HTTP 500), 암시적으로(예: HTTP 200 성공 응답이지만 잘못된 콘텐츠와 결합된 경우) 또는 정책에 따라(예: "1초 응답 시간을 약속한 경우 1초를 초과하는 모든 요청은 오류") 실패한 요청의 비율입니다. 프로토콜 응답 코드가 모든 장애 조건을 표현하기에 불충분한 경우, 부분적인 장애 모드를 추적하기 위해 보조(내부) 프로토콜이 필요할 수 있습니다. 로드 밸런서에서 HTTP 500을 포착하면 완전히 실패한 요청을 모두 잡아낼 수 있는 반면, 엔드투엔드 시스템 테스트를 통해서만 잘못된 콘텐츠를 전송하는 것을 감지할 수 있기 때문에 이러한 경우를 모니터링하는 방법은 크게 다를 수 있습니다.
* 포화도(Saturation) 서비스가 얼마나 '꽉' 차 있는지. 가장 제약이 많은 리소스를 강조하는 시스템 비율의 측정값입니다(예: 메모리 제약이 있는 시스템에서는 메모리 표시, I/O 제약이 있는 시스템에서는 I/O 표시). 많은 시스템이 100% 사용률에 도달하기 전에 성능이 저하되므로 사용률 목표를 설정하는 것이 필수적입니다.

## Conclusion

위의 내용을 지침으로 삼아 모니터링을 시작하면 다음 단계로 성장할 수 있습니다.