MongoDB Ops Manager는 단순히 “서버가 살아 있는지”만 보는 도구가 아닙니다.
배포 단위, 프로세스 단위, 실시간 성능 패널, 알림, 로그, API까지 연결해서 MongoDB 운영 상태를 한 화면에서 추적할 수 있도록 설계되어 있습니다. Ops Manager는 서버, 데이터베이스, MongoDB 프로세스에 대한 메트릭을 수집·표시하며, 하드웨어 메트릭은 자동화가 프로세스를 관리하는 경우에만 수집됩니다. 모니터링 에이전트만 있는 경우에는 데이터베이스 메트릭만 수집됩니다.

이번 글에서는 다음 두 가지를 중심으로 정리합니다.

  1. Ops Manager를 실제로 어떻게 보는가
  2. 운영자가 꼭 봐야 할 핵심 메트릭은 무엇인가

1. Ops Manager에서 메트릭을 보는 기본 구조

Ops Manager에서 메트릭은 크게 4가지 관점으로 봅니다.

  • Deployment Metrics: 배포 전체 기준
  • MongoDB Process Metrics: 개별 mongod 또는 mongos 기준
  • DB Stats: 특정 데이터베이스 기준
  • Real-Time Metrics: 실시간 성능 확인용 패널

공식 문서 기준으로 Ops Manager는 배포 메트릭을 Replica Set, Sharded Cluster, MongoDB Process, Real-Time Performance 방식으로 나누어 볼 수 있습니다. 또한 개별 프로세스 화면에는 Status / Hardware / DB Stats 세 개의 탭이 제공됩니다.

2. 가장 먼저 익혀야 할 화면 이동 경로

실제로 많이 쓰는 화면 이동은 아래 순서입니다.

배포 전체 메트릭 보기

  • Deployment 화면
  • 대상 Replica Set 또는 Sharded Cluster 선택
  • Metrics 클릭

특정 mongod / mongos 프로세스 보기

  • Deployment > List 탭
  • 원하는 프로세스 선택
  • Status / Hardware / DB Stats 탭 확인

실시간 성능 보기

  • 대상 배포에서 Metrics
  • Real Time 클릭

MongoDB 공식 문서에 따르면 Real-Time Metrics는 mongod(replica set, shard)와 mongos에 대해 지원되며, 화면 우측 상단에서 Table 또는 Graph 보기로 전환할 수 있습니다. 또한 이 기능은 기본적으로 프로젝트에 활성화되어 있으며, 프로젝트 오너는 Settings에서 Real-Time Performance Panel을 켜거나 끌 수 있습니다.

3. Ops Manager를 사용할 때 먼저 알아둘 점

운영 중 헷갈리기 쉬운 포인트가 있습니다.

3-1. 하드웨어 메트릭이 안 보일 수 있다

Ops Manager는 Automation이 프로세스를 관리할 때만 하드웨어 메트릭을 수집합니다.
Monitoring Agent만 붙어 있으면 DB 쪽 메트릭은 보여도, 호스트 하드웨어 메트릭은 제한될 수 있습니다.

3-2. DB Stats는 실시간이 아니다

개별 프로세스의 DB Stats 탭은 기본적으로 20분마다 데이터베이스 메트릭을 수집합니다. 성능 영향이 우려되면 프로젝트 설정에서 Collect Database Specific Statistics를 No로 바꿔 비활성화할 수 있습니다.

3-3. 메트릭은 저장 주기와 보관 기간이 있다

Ops Manager는 기본적으로 10초 granularity로 메트릭을 수집하며, 상위 granularity 데이터는 이전 granularity의 평균값을 기반으로 집계합니다. 다만 Replication Lag와 Replication Headroom은 프로젝트 기본 granularity와 무관하게 85초 granularity로 수집됩니다.

4. Ops Manager에서 가장 먼저 봐야 하는 주요 메트릭

이제 핵심입니다.
Ops Manager에는 메트릭 종류가 많지만, 실무에서는 아래 메트릭부터 우선 보면 됩니다.

5. Connections: 현재 연결 수가 적정한가

Connections는 현재 배포에 연결된 활성 커넥션 수를 보여줍니다. 공식 문서도 이 지표를 통해 현재 connection limit가 충분한지 판단할 수 있다고 설명합니다.

이 메트릭을 볼 때 해석 포인트

  • 연결 수가 지속적으로 높게 유지되는가
  • 특정 시간대에 급증하는가
  • 애플리케이션 풀링 설정 문제는 없는가
  • 커넥션 증가와 함께 응답속도 저하가 발생하는가

이런 상황이면 의심

  • 애플리케이션에서 커넥션 반환이 안 됨
  • 커넥션 풀 수가 비정상적으로 큼
  • 장애 시 재시도 로직 때문에 연결 폭증

운영 초반에는 CPU보다 먼저 Connections가 이상 신호를 주는 경우가 많습니다.

6. OpCounters: 어떤 작업이 부하를 만드는가

OpCounters는 프로세스가 마지막 시작 이후 수행한 작업의 초당 수를 보여줍니다. 문서에는 command/cmd, query, insert, delete, update, getmore 등을 확인할 수 있다고 나와 있습니다. 이 지표는 고부하의 원인이 어떤 타입의 작업인지 확인하는 데 유용합니다.

해석 포인트

  • query가 급증하면 읽기 부하
  • insert가 높으면 유입량 증가
  • update가 높으면 쓰기 경쟁 가능성
  • getmore가 높으면 커서 기반 대량 조회 가능성
  • command/cmd 비중이 높으면 관리성 또는 내부 명령 확인 필요

예를 들어 CPU가 높은데 OpCounters에서 query와 getmore가 함께 증가하면,
대량 조회나 비효율적인 페이징 패턴을 먼저 의심해볼 수 있습니다.

7. Memory / Cache 계열: 메모리로 버티는지, 디스크로 밀리는지

Memory는 resident, virtual, mapped 같은 메모리 사용량을 보여줍니다.
공식 문서 기준으로 resident는 MongoDB 프로세스가 실제로 소비하는 메모리이며, virtual은 디스크를 스왑 공간처럼 예약한 메모리, mapped는 MMAPv1 관련 메모리 맵 크기입니다. WiredTiger는 memory-mapped files를 사용하지 않으므로 mapped는 보통 0이어야 합니다. 또한 최신 Ops Manager 릴리스에는 cache ratio metrics가 추가되었습니다.

해석 포인트

  • resident 메모리가 꾸준히 높은데도 성능이 안정적이면 정상일 수 있음
  • page fault, disk read, swap과 같이 봐야 진짜 문제 판단 가능
  • cache ratio가 높게 유지되면 working set이 cache 크기를 넘을 가능성 점검

특히 WiredTiger 환경에서는 CPU만 볼 게 아니라
cache가 꽉 차는지, 메모리 부족으로 디스크 I/O가 늘어나는지를 함께 확인해야 합니다.

8. Page Faults: 메모리가 부족한지 보는 신호

Page Faults는 선택한 샘플 기간 동안 프로세스의 page fault 평균 발생률을 보여줍니다. 비 Windows 환경에서는 hard page fault 기준입니다. 공식 문서는 이 지표를 보고 메모리를 늘려야 하는지 판단하라고 안내합니다.

해석 포인트

  • page fault가 증가하면 디스크 접근 증가 가능성
  • resident memory, swap, CPU와 같이 봐야 함
  • 읽기 지연이나 응답 시간 증가와 함께 발생하면 위험 신호

Page Faults는 혼자 보기보다
Memory + Process CPU + Disk 성격 지표와 같이 묶어서 해석하는 것이 좋습니다.

9. CPU: MongoDB 프로세스가 바쁜지, 서버 전체가 바쁜지 구분하기

Ops Manager는 Process CPU, System CPU, 그리고 normalized CPU 계열 지표를 제공합니다.
문서에서는 Process CPU가 MongoDB 프로세스가 CPU를 얼마나 사용하는지 보여주고, System CPU는 노드 전체의 CPU 사용량을 보여준다고 설명합니다. CPU 지표는 데이터가 메모리가 아니라 디스크에서 읽히는지 판단하는 데도 활용할 수 있습니다.

해석 포인트

  • Process CPU만 높다 → MongoDB 자체 작업량 증가
  • System CPU도 높다 → 서버 전체 자원 경쟁 가능성
  • kernel 비중이 높다 → OS 호출, I/O 관련 부담 가능성
  • CPU 상승과 함께 query, queue, page fault 증가 여부 확인

운영에서는 “CPU 90%” 숫자 하나보다
누가 CPU를 쓰는지를 보는 것이 더 중요합니다.

10. Queues: 락 대기나 병목이 생기는지 확인

Queues는 락을 기다리는 작업 수를 보여줍니다. 문서 기준으로 total, readers, writers 큐를 확인할 수 있고, 이 지표는 잠재적 병목과 대기 문제를 식별하는 데 유용합니다.

해석 포인트

  • writers 대기가 높으면 쓰기 경쟁 가능성
  • readers 대기가 높으면 읽기 처리 병목 가능성
  • 전체 큐가 계속 누적되면 락 또는 디스크 문제 의심

특히 응답 시간이 느린데 Connections는 정상이면
Queues를 먼저 확인해보는 것이 좋습니다.

11. Network: 트래픽 급증과 요청량 변화 파악

Ops Manager의 Network 메트릭은 bytesIn, bytesOut, numRequests를 보여줍니다.
이는 데이터베이스 서버로 들어오고 나가는 물리적 바이트 수와 요청 수를 추적하는 용도입니다. 시스템 네트워크 기준으로는 System Network 지표도 제공됩니다.

해석 포인트

  • bytesIn 급증 → 쓰기 유입 또는 대량 요청 증가 가능성
  • bytesOut 급증 → 대량 조회 또는 응답 데이터 증가 가능성
  • numRequests 급증 → 애플리케이션 트래픽 증가
  • 네트워크 증가와 CPU/OpCounters를 같이 보면 원인 파악이 쉬움

트래픽 장애는 CPU보다 먼저
Network + Requests 패턴 변화로 보이는 경우가 많습니다.

12. Query Targeting / Scan and Order: 인덱스가 잘못됐는지 보는 지표

Query Targeting은 스캔한 문서 수 대비 반환 문서 수 비율을 보여주며, 문서는 이를 통해 읽기 효율과 쿼리/인덱스 최적화 필요성을 판단하라고 설명합니다. Scan and Order는 인메모리 정렬이 필요한 작업 수를 초당 단위로 보여주며, 공식 문서도 이 지표를 통해 인덱스 필요 여부를 확인할 수 있다고 안내합니다.

해석 포인트

  • scanned objects / returned 비율이 나쁘다 → 쿼리가 너무 많은 문서를 훑음
  • scan and order가 높다 → 정렬용 인덱스 부족 가능성
  • CPU 높음 + query 높음 + query targeting 나쁨 → 인덱스 점검 우선

이 메트릭은 개발팀과 운영팀이 함께 보기에 가장 좋은 지표입니다.
왜냐하면 서버 증설보다 쿼리 수정이나 인덱스 추가가 먼저일 수 있기 때문입니다.

13. Replication Lag / Headroom: 복제 지연을 꼭 확인해야 하는 이유

Replica Set 운영에서는 Replication Lag와 Replication Headroom이 매우 중요합니다. Ops Manager 설정 문서와 경고 조건 문서에서는 Replication Lag가 secondary가 primary를 얼마나 뒤따르는지 보여주며, Replication Headroom은 sync source의 oplog window와 secondary lag 간 차이를 의미한다고 설명합니다. 이 값이 0에 가까워지면 secondary가 RECOVERING 상태로 갈 수 있습니다.

해석 포인트

  • lag가 계속 커진다 → secondary가 따라가지 못함
  • headroom이 줄어든다 → oplog 여유가 부족함
  • 백업, 배치, 대량 인덱스 작업 시간과 같이 봐야 함

단, 공식 문서도 replica set이 거의 쓰이지 않는 경우에는
Replication Lag가 실제 장애가 아니라 마지막 쓰기 이후 시간처럼 보일 수 있다고 설명합니다. 즉, 쓰기가 드문 시스템에서는 숫자 자체보다 패턴을 봐야 합니다.

14. Alerts: 메트릭을 보는 것에서 끝내지 말고 알림까지 연결해야 한다

Ops Manager는 조건과 임계값을 기준으로 알림을 발생시키며, 조건이 충족되면 일정 간격으로 알림을 보내고, 해소되거나 비활성화될 때까지 추적합니다. 알림은 조직 수준 또는 프로젝트 수준으로 설정할 수 있고, 프로젝트에는 기본 알림이 제공됩니다.

공식 문서에서 추천하는 호스트/운영 관련 알림 예시는 다음과 같습니다.

  • Host is down
  • Host is recovering
  • Replication Lag
  • Replication Oplog
  • Tickets Available: Writes/Reads
  • Queues: Readers/Writers

이 추천 항목들은 성능 저하, 복제 문제, 호스트 장애를 빠르게 감지하는 데 유용합니다.

실무 팁

대시보드를 매번 열어보는 것보다,

  • Connections
  • Queues
  • Replication Lag
  • Host Down
  • Tickets Available
  • Network Requests 급증

이 정도는 먼저 알림으로 설정해두는 편이 좋습니다.

15. 로그와 같이 봐야 정확하다

Ops Manager는 메트릭뿐 아니라 MongoDB 프로세스와 에이전트의 로그도 수집합니다. MongoDB 프로세스에 대해서는 실시간 로그와 디스크 로그에 접근할 수 있습니다. 따라서 메트릭에서 이상 징후를 본 뒤 로그와 맞춰보면 원인 분석이 훨씬 빨라집니다.

예를 들어:

  • CPU 급등 → 느린 쿼리 로그 확인
  • Replication Lag 증가 → 복제 관련 로그 확인
  • Connection 폭증 → 애플리케이션 재시도/풀링 로그 확인

이렇게 메트릭과 로그를 같이 보는 습관이 중요합니다.

16. API로도 메트릭을 뽑을 수 있다

Ops Manager는 Measurements API를 통해 모니터링과 자동화가 수집한 프로세스, 데이터베이스, 디스크 측정값을 가져올 수 있습니다. 이 데이터는 serverStatus, dbStats 같은 진단 명령을 기반으로 수집됩니다. 즉, 대시보드만 보는 것이 아니라 외부 리포트, 자동 분석, 사내 모니터링 연동도 가능합니다.

또한 Ops Manager는 Prometheus 연동도 지원하므로, 기존 관측 스택과 결합해서 사용할 수도 있습니다.

17. 운영자가 추천하는 Ops Manager 체크 순서

초보 운영자라면 아래 순서대로 보면 됩니다.

평소 점검

  1. Deployment 상태 확인
  2. Open Alerts 확인
  3. Connections / CPU / Memory / Network 확인
  4. Replica Set이면 Replication Lag 확인
  5. Query Targeting / Scan and Order 확인

장애 징후가 있을 때

  1. Real-Time Metrics 열기
  2. OpCounters로 어떤 작업이 늘었는지 확인
  3. Queues와 CPU 확인
  4. Page Faults와 Memory 확인
  5. Logs와 대조

이 순서가 좋은 이유는
문제의 성격을 빠르게 좁힐 수 있기 때문입니다.
읽기 문제인지, 쓰기 문제인지, 메모리 문제인지, 복제 문제인지가 비교적 빨리 보입니다.

18. 결론

MongoDB Ops Manager를 잘 쓰는 핵심은
“메트릭이 많다”는 사실에 압도되지 않는 것입니다.

처음부터 모든 차트를 다 보는 것이 아니라,
아래 핵심 축만 먼저 보면 됩니다.

  • Connections: 연결 수 이상 여부
  • OpCounters: 어떤 작업이 부하를 만드는지
  • Memory / Cache / Page Faults: 메모리 부족 여부
  • CPU / Queues: 병목과 대기 여부
  • Network: 유입·유출과 요청량 변화
  • Query Targeting / Scan and Order: 인덱스 문제 여부
  • Replication Lag / Headroom: 복제 안정성 여부

즉, Ops Manager는 단순한 모니터링 화면이 아니라
MongoDB의 성능, 병목, 복제, 장애를 입체적으로 해석하는 운영 도구라고 보면 됩니다.