자체 관리 MongoDB 배포 모니터링

모니터링 전략

MongoDB는 실행 중인 MongoDB 인스턴스의 상태에 대한 데이터를 수집하기 위한 다양한 방법을 제공합니다.

• MongoDB는 데이터베이스 활동에 대한 실시간 보고 기능을 제공하는 일련의 유틸리티를 배포합니다.

• MongoDB는 현재 데이터베이스 상태에 대한 통계를 보다 충실하게 반환하는 다양한 데이터베이스 명령을 제공합니다.

• MongoDB Atlas는 MongoDB deployment를 실행, 모니터링 및 유지 관리하기 위한 클라우드 기반의 서비스형 데이터베이스입니다.

• MongoDB Cloud Manager는 실행 중인 MongoDB 배포를 모니터링하여 데이터를 수집하고 해당 데이터를 기반으로 시각화 및 경고를 제공하는 호스팅 서비스입니다.

• MongoDB Ops Manager는 실행 중인 MongoDB 배포를 모니터링하여 데이터를 수집하고 해당 데이터를 기반으로 시각화 및 경고를 제공하는 MongoDB Enterprise Advanced에서 사용할 수 있는 온프레미스 솔루션입니다.

각 전략은 서로 다른 질문에 답변하는 데 도움이 될 수 있으며 다양한 컨텍스트에서 유용하게 사용할 수 있습니다. 이러한 방법은 상호 보완적입니다.

MongoDB 보고 도구

이 섹션에서는 MongoDB와 함께 분산된 보고 방법에 대한 개요를 제공합니다. 또한 각 방법이 해결하는 데 가장 적합한 질문 유형의 예를 제공합니다.

프로세스 로깅

정상 작동 중에 mongod 및 mongos 인스턴스는 모든 서버 활동 및 작업에 대한 실시간 계정을 표준 출력 또는 로그 파일에 보고합니다. 다음 런타임 설정은 이러한 옵션을 제어합니다.

• quiet. 로그 또는 출력에 기록되는 정보의 양을 제한합니다.

• verbosity. 로그 또는 출력에 기록되는 정보의 양을 늘립니다. 셸에서 logLevel 매개변수 또는 db.setLogLevel() 메서드를 사용하여 런타임 중에 로깅 상세도를 수정할 수도 있습니다.

• path. 표준 출력이 아닌 파일에 로깅할 수 있도록 설정합니다. 이 설정을 조정할 때 로그 파일의 전체 경로를 지정해야 합니다.

• logAppend. 파일을 덮어쓰는 대신 로그 파일에 정보를 추가합니다.

mongod -v --logpath /var/log/mongodb/server1.log --logappend

다음 데이터베이스 명령도 로깅에 영향을 미칩니다.

• getLog. mongod 프로세스 로그의 최근 메시지를 표시합니다.

• logRotate. mongod 프로세스에 대해서만 로그 파일을 순환합니다. 로그 파일 회전을 참조하세요.

db.clients.insertOne( { "name" : "Joe", "PII" : "Sensitive Information" } )

{
   "t": { "$date": "2024-07-19T15:36:55.024-07:00" },
   "s": "I",
   "c": "COMMAND",
   ...
   "attr": {
      "type": "command",
      ...
      "appName": "mongosh 2.2.10",
      "command": {
         "insert": "clients",
         "documents": [
            {
               "name": "Joe",
               "PII": "Sensitive Information",
               "_id": { "$oid": "669aea8792c7fd822d3e1d8c" }
            }
         ],
         "ordered": true,
         ...
      }
      ...
   }
}

{
   "t": { "$date": "2024-07-19T15:36:55.024-07:00" },
   "s": "I",
   "c": "COMMAND",
   ...
   "attr": {
      "type": "command",
      ...
      "appName": "mongosh 2.2.10",
      "command": {
         "insert": "###",
         "documents": [
            {
               "name": "###",
               "PII": "###",
               "_id": "###"
            }
         ],
         "ordered": "###",
         ...
      }
      ...
   }
}

성능 문제 진단

MongoDB를 사용하여 애플리케이션을 개발하고 운영할 때 애플리케이션으로서 데이터베이스의 성능을 분석할 수 있습니다. MongoDB 성능에서는 성능에 영향을 미칠 수 있는 몇 가지 운영 요인에 대해 설명합니다.

복제 및 모니터링

모든 MongoDB 인스턴스에 대한 기본 모니터링 요구 사항 외에도, 복제본 세트의 경우 관리자는 복제 지연을 모니터링해야 합니다. 복제 지연은 복사( 복제)를 통해 프라이머리에서 보조로 쓰기 작업을 수행하는 데 걸리는 시간을 나타냅니다. 약간의 지연은 허용될 수 있지만 복제 지연이 증가하면 다음과 같은 심각한 문제가 발생합니다.

• 프라이머리에 대한 캐시 압박이 커지고 있습니다.

• 지연 기간 동안 발생한 작업은 하나 이상의 세컨더리 서버에 복제되지 않습니다. 데이터 지속성을 보장하기 위해 복제를 사용하는 경우, 예외적으로 긴 지연은 데이터 세트의 무결성에 영향을 줄 수 있습니다.

• 복제 지연이 작업 로그(oplog)의 길이를 초과하는 경우, MongoDB는 세컨더리에서 초기 동기화를 수행하여 프라이머리에서 모든 데이터를 복사하고 모든 인덱스를 다시 빌드해야 합니다. [1] 일반적인 상황에서는 흔하지 않지만, oplog를 기본값보다 작게 구성하면 문제가 발생할 수 있습니다.

  참고

  oplog의 크기는 첫 실행 중에 mongod 명령의 --oplogSize 인수를 사용해야지만 가능하며, 혹은 가급적이면 MongoDB 구성 파일의 oplogSizeMB 설정을 사용하여 구성하는 것이 좋습니다. --replSet 옵션으로 실행하기 전에 명령줄에서 이를 지정하지 않으면 mongod에서 기본 크기의 oplog를 생성합니다.

  기본적으로 oplog는 64비트 시스템에서 사용 가능한 총 디스크 공간의 5%입니다. oplog 크기 변경에 대한 자세한 내용은 자체 관리 복제본 세트 멤버의 Oplog 크기 변경을 참조하세요.

rs.status()

샤딩 및 모니터링

대부분의 경우 샤딩된 클러스터의 구성 요소는 다른 모든 MongoDB 인스턴스와 동일한 모니터링 및 분석의 이점을 누릴 수 있습니다. 또한 클러스터에는 데이터가 노드 간에 효과적으로 분산되고 샤딩 작업이 적절하게 작동하도록 하기 위한 추가적인 모니터링이 필요합니다.

use config
db.locks.find()

db.locks.find( { _id : "balancer" } )

Storage Node Watchdog

Storage Node Watchdog는 다음과 같은 MongoDB 디렉토리를 모니터링하여 파일 시스템이 응답하지 않는 것을 감지합니다.

• --dbpath 디렉토리

• journal 가 --dbpath journaling 활성화된 경우 디렉토리 내의 디렉토리

• --logpath 파일의 디렉터리

• --auditPath 파일의 디렉터리

기본적으로 Storage Node Watchdog은 비활성화되어 있습니다. watchdogPeriodSeconds 매개 변수를 60보다 크거나 같은 정수로 설정하여 시작 시 mongod에서만 Storage Node Watchdog을 활성화할 수 있습니다. 하지만 일단 활성화하면 Storage Node Watchdog을 일시 중지했다가 런타임 중에 다시 시작할 수 있습니다. 자세한 내용은 watchdogPeriodSeconds 매개변수를 참조하세요.

모니터링되는 디렉터리가 포함된 파일시스템이 응답하지 않는 경우, Storage Node Watchdog는 mongod를 상태 코드 61로 종료합니다. mongod가 복제본 세트의 프라이머리인 경우, 종료 시 페일오버가 시작되어 다른 노드가 프라이머리 노드가 될 수 있습니다.

mongod가 종료되면 동일한 컴퓨터에서 완전히 다시 시작하지 못할 수 있습니다.

Storage Node Watchdog가 응답하지 않는 파일 시스템을 감지하고 종료하는 데 걸리는 최대 시간은 watchdogPeriodSeconds 값의 거의 두 배에 달합니다.