[모니터링] 모니터링의 필요성 및 주요 지표

모니터링을 하는 이유

• 모든 IT 시스템은 사용자를 대상으로 원활한 서비스를 제공하는 것을 목표로 한다.
• 사용자가 서비스를 통해 만족을 얻도록 시스템은 상시 안정적으로 운영될 필요가 있고, 시스템의 이상 징후를 상시 감시할 수 있어야 한다.
• 시스템 이상의 원인 파악을 위한 정보를 제공할 수 있어야 한다.
• 시스템을 상시 유지 보수하여 최적화할 수 있도록 정보를 추출할 수 있어야 한다.
• 안정적으로 운영되고 있는 시스템의 성능을 향상시킬 수 있어야 한다.

모니터링을 통해 추구하는 결과

• 관측된 결과를 기반으로 시스템을 최적화한다.
• 인적 비용 투입을 최소화한다.
• 머신 파워에 투입되는 비용을 절감한다.
• 장애에 대한 빠른 분석을 통해 서비스 중단 시간을 최소화한다.
• 이상 징후를 상시 탐지하여 예방 정비를 수행한다.

Observability란?

Monitoring

• 사용자의 적극적 행위와 무관하게 시스템을 바라보는 행위를 의미한다.

  Observability (가시성, 관측 가능성)

• Observe(관찰하다) : 모니터링 보다 적극적인 사용자의 행위를 의미한다.
• 시스템의 상황을 관측이 가능한 수준으로 제공할 수 있는지의 여부가 Observability (관측가능성) 을 의미한다.
• Trace, Metrics, Log, Event 4가지를 모두 함께 볼 수 있어야 observability가 높다고 이야기 할 수 있다.

모니터링 도구 선정 방법

1. 통합 서버 모니터링 가능 여부
   • 전체 서버의 규모와 자원 현황을 한 눈에 모니터링 할 수 있는가?
2. 서버 및 프로세스 성능 모니터링
   • 특정 서버의 자원 문제가 식별된 경우, 프로세스 레벨의 자원 상황까지 원인 분석이 가능한가?
   • 몇 초(혹은 분) 단위로 프로세스의 정보를 수집하는가?
     • 해당 정보 수집을 통해 문제를 발생시킨 프로세스를 특정시킬 수 있는가?

서버 모니터링의 주요 지표

• CPU 전체 사용률
  • Idle 사용률은 얼마나 되는가?
  • system 자체에서 사용하는 CPU 비율은 얼마나 되는가?
  • User가 실행시킨 Process가 사용하는 CPU 비율을 얼마나 되는가?
  • 우선순위 (Nice)를 설정 했는가?
  • IOWait (IO)하기 위해 기다린 비율은 얼마나 되는가?
  • CPU Load : core 하나가 일을 얼마나 하고 있는가?
    • 1 → 할 수 있는 일을 계속 함
    • 0.5 → 할 수 있는 일의 절반 정도
    • CPU 증설의 기준이 될 수 있음
• Mem 사용률
  • Slab : 커널에서 사용하는 mem은 얼마나 되는가?
• Network
  • 송/수신량의 차이가 많이 나지는 않는가?
• Disk I/O
  • IO를 얼마나 빠르게 처리할 수 있는가?
  • 계속해서 업로드를 해야할 때, Queue Length는 얼마로 잡는 것이 좋은가?
    • 2~4를 넘지 않으면 OK
  • system이 어느정도의 처리 상태를 가지고 있는지 확인해볼 수 있음
• TPS (중요)
  • 초당 transection 수
• 동시 접속 사용자
  • 실제로 서비스를 사용하고 있는 사용자
• 평균 응답 시간
  • active user가 request 를 얼마만에 처리받는가

주요 지표에 따른 인사이트

TPS가 갑자기 뛴다

- why?
    - 동시 접속 사용자 수가 갑자기 들었다.
    - 한 명의 사용자가 갑자기 많은 양의 request를 밀어 넣는다.        
        → 특정 트랜잭션이 다발로 들어왔을 가능성이 높음

응답 시간이 갑자기 뛴다

- TPS와 사용자 수를 순서대로 확인해 볼 것
- 둘 다 변화가 없다면
    - Heap Memory를 볼 것
        → GC를 하느라 일을 못하는 상태가 되거나, CPU 사용률이 늘었을 수 있음