자체 관리 MongoDB 배포 모니터링
모니터링은 모든 데이터베이스 관리의 중요한 구성 요소입니다. MongoDB의 보고를 확실히 이해하면 데이터베이스 상태를 평가하고 위기 없이 배포를 유지할 수 있습니다. 또한 MongoDB의 정상적인 작동 매개 변수를 파악하면 문제가 실패로 확대되기 전에 진단할 수 있습니다.
이 문서에서는 MongoDB에서 사용할 수 있는 모니터링 유틸리티 및 보고 통계에 대한 개요를 제공합니다. 또한 복제본 세트 및 샤딩된 클러스터를 모니터링하기 위한 진단 전략 및 제안 사항을 소개합니다.
모니터링 전략
MongoDB는 실행 중인 MongoDB 인스턴스의 상태에 대한 데이터를 수집하기 위한 다양한 방법을 제공합니다.
MongoDB는 데이터베이스 활동에 대한 실시간 보고 기능을 제공하는 일련의 유틸리티를 배포합니다.
MongoDB는 현재 데이터베이스 상태에 대한 통계를 보다 충실하게 반환하는 다양한 데이터베이스 명령을 제공합니다.
MongoDB Atlas는 MongoDB deployment를 실행, 모니터링 및 유지 관리하기 위한 클라우드 기반의 서비스형 데이터베이스입니다.
MongoDB Cloud Manager는 실행 중인 MongoDB 배포를 모니터링하여 데이터를 수집하고 해당 데이터를 기반으로 시각화 및 경고를 제공하는 호스팅 서비스입니다.
MongoDB Ops Manager는 실행 중인 MongoDB 배포를 모니터링하여 데이터를 수집하고 해당 데이터를 기반으로 시각화 및 경고를 제공하는 MongoDB Enterprise Advanced에서 사용할 수 있는 온프레미스 솔루션입니다.
각 전략은 서로 다른 질문에 답변하는 데 도움이 될 수 있으며 다양한 컨텍스트에서 유용하게 사용할 수 있습니다. 이러한 방법은 상호 보완적입니다.
MongoDB 보고 도구
이 섹션에서는 MongoDB와 함께 분산된 보고 방법에 대한 개요를 제공합니다. 또한 각 방법이 해결하는 데 가장 적합한 질문 유형의 예를 제공합니다.
유틸리티
MongoDB 배포에는 인스턴스의 성능 및 활동에 대한 통계를 신속하게 반환하는 여러 유틸리티가 포함되어 있습니다. 일반적으로 이는 문제를 진단하고 정상적인 작동을 평가하는 데 가장 유용합니다.
mongostat
mongostat
유형별로 데이터베이스 작업의 수를 캡처하고 반환합니다(예: 삽입, 쿼리, 업데이트, 삭제 등). 이 작업의 수는 서버의 부하 분산에 대해 보고합니다.
mongostat
을 사용하여 작업 유형 분포를 파악하고 용량 계획에 정보를 제공합니다. 자세한 내용은 mongostat
참조 페이지를 확인하세요.
mongotop
mongotop
MongoDB 인스턴스의 현재 읽기 및 쓰기 활동을 추적 및 보고하고 컬렉션별로 이러한 통계를 보고합니다.
mongotop
을 사용하여 데이터베이스 활동과 사용이 예상과 일치하는지 확인합니다. 자세한 내용은 mongotop
참조 페이지에서 확인하세요.
명령.
MongoDB에는 데이터베이스 상태를 보고하는 여러 명령이 포함되어 있습니다.
이러한 데이터는 위에서 설명한 유틸리티보다 더 세분화된 수준의 정보를 제공할 수 있습니다. 스크립트 및 프로그램에서 해당 출력을 사용하여 사용자 지정 알림을 개발하거나 인스턴스의 활동에 따라 애플리케이션의 동작을 수정하는 것을 고려해 보세요. db.currentOp()
메서드도 데이터베이스 인스턴스에서 진행 중인 작업을 식별하는 데 유용한 도구입니다.
serverStatus
셸에서 serverStatus
명령 또는 db.serverStatus()
를 실행하면 디스크 사용량, 메모리 사용량, 연결, 저널링 및 인덱스 액세스를 자세히 설명하는 데이터베이스 상태에 대한 일반적인 개요가 반환됩니다. 이 명령은 빠르게 반환되며 MongoDB 성능에 영향을 주지 않습니다.
serverStatus
는 MongoDB 인스턴스의 상태에 대한 설명을 출력합니다. 이 명령은 직접 실행되는 경우는 거의 없습니다. 대부분의 경우 MongoDB Cloud Manager 및 Ops Manager를 포함한 모니터링 도구에서 볼 수 있듯이 데이터는 집계될 때 더 의미가 있습니다. 그럼에도 불구하고 모든 관리자는 serverStatus
에서 제공하는 데이터를 숙지하고 있어야 합니다.
dbStats
셸에서 dbStats
명령 또는 db.stats()
를 입력하면 스토리지 사용량 및 데이터 볼륨을 다루는 문서가 반환됩니다. dbStats
에는 사용된 저장소의 양, 데이터베이스에 포함된 데이터의 양, 객체, 컬렉션 및 인덱스 카운터가 반영됩니다.
이 데이터를 사용하여 특정 데이터베이스의 상태와 저장 용량을 모니터링하세요. 이 출력을 통해 데이터베이스 간의 사용량을 비교하고 데이터베이스의 평균 문서 크기를 확인할 수도 있습니다.
collStats
셸에서 collStats
또는 db.collection.stats()
를 호출하여 컬렉션의 객체 수, 컬렉션의 크기, 컬렉션에서 사용하는 디스크 공간의 양, 인덱스에 대한 정보 등 컬렉션 수준에서 dbStats
과 유사한 통계를 제공할 수 있습니다.
replSetGetStatus
replSetGetStatus
명령(셸의 rs.status()
)은 복제본 세트의 상태에 대한 개요를 반환합니다. replSetGetStatus 문서에는 복제본 세트의 상태 및 구성과 멤버에 대한 통계가 자세히 나와 있습니다.
이 데이터를 사용하여 복제가 올바르게 구성되었는지 확인하고 현재 호스트와 복제본 세트의 다른 멤버 간의 연결을 확인합니다.
호스팅(SaaS) 모니터링 도구
이는 일반적으로 유료 구독을 통해 호스팅 서비스로 제공되는 모니터링 도구입니다.
이름 | 참고 사항 |
---|---|
MongoDB Cloud Manager는 MongoDB deployment를 관리하기 위한 클라우드 기반 서비스 제품군입니다. MongoDB Cloud Manager는 모니터링, 백업, 자동화 기능을 제공합니다. 온프레미스 솔루션에 대한 자세한 내용은 MongoDB Enterprise Advanced에서 사용할 수 있는 Ops Manager에서도 확인할 수 있습니다. | |
VividCortex는 1초 단위의 해상도로 MongoDB 프로덕션 데이터베이스 워크로드 및 쿼리 성능에 대한 심층적인 인사이트를 제공합니다. 지연 시간, 처리량, 오류 등을 추적하여 MongoDB에서 애플리케이션의 확장성과 탁월한 성능을 보장합니다. | |
MongoDB 대시보드, MongoDB 지정 경고, 복제 페일오버 타임라인 및 iPhone, iPad, Android 모바일 앱. | |
IBM은 MongoDB 및 기타 애플리케이션과 미들웨어에 대한 모니터를 포함하는 애플리케이션 성능 관리 SaaS 제품을 제공합니다. | |
New Relic은 애플리케이션 성능 관리를 완벽하게 지원합니다. 또한, New Relic Plugins 및 Insights를 통해 New Relic의 Cloud Manager에서 모니터링 지표를 확인할 수 있습니다. | |
인프라 모니터링으로 MongoDB deployment의 성능을 시각화합니다. | |
모니터링, 이상 징후 탐지 및 알림 SPM은 인프라를 포함한 모든 주요 MongoDB 지표를 함께 모니터링합니다. Docker 및 기타 애플리케이션 메트릭(예 Node.js Java, NGINX, Apache, HAProxy 또는 Elasticsearch. SPM은 지표와 로그의 상관 관계를 제공합니다. | |
Pandora FMS는 MongoDB를 모니터링하기 위해 PandoraFMS-mongodb-monitoring 플러그인을 제공합니다. |
프로세스 로깅
정상 작동 중에 mongod
및 mongos
인스턴스는 모든 서버 활동 및 작업에 대한 실시간 계정을 표준 출력 또는 로그 파일에 보고합니다. 다음 런타임 설정은 이러한 옵션을 제어합니다.
quiet
. 로그 또는 출력에 기록되는 정보의 양을 제한합니다.verbosity
. 로그 또는 출력에 기록되는 정보의 양을 늘립니다. 셸에서logLevel
매개변수 또는db.setLogLevel()
메서드를 사용하여 런타임 중에 로깅 상세도를 수정할 수도 있습니다.path
. 표준 출력이 아닌 파일에 로깅할 수 있도록 설정합니다. 이 설정을 조정할 때 로그 파일의 전체 경로를 지정해야 합니다.logAppend
. 파일을 덮어쓰는 대신 로그 파일에 정보를 추가합니다.
참고
다음 데이터베이스 명령도 로깅에 영향을 미칩니다.
로그 편집
MongoDB Enterprise에서만 사용할 수 있습니다.
mongod
또는 mongos
가 redactClientLogData
와 함께 실행되는 경우, 주어진 로그 이벤트를 로깅하기 전에 모든 메시지를 삭제하여 이벤트와 관련된 메타데이터, 소스 파일 또는 줄 번호만 남깁니다. redactClientLogData
는 진단 세부 정보를 희생하여 잠재적으로 민감한 정보가 시스템 로그에 입력되는 것을 방지합니다.
예를 들어, 다음 작업은 로그 편집 없이 실행 중인 mongod
에 문서를 삽입합니다. mongod
에는 로그 세부 정보 표시 수준이 1
으로 설정되어 있습니다.
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, ... } ... } }
mongod
가 redactClientLogData
와 함께 실행되어 동일한 삽입 작업을 수행하면 다음과 같은 로그 이벤트가 생성됩니다.
{ "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": "###", ... } ... } }
redactClientLogData
를 저장 시 암호화 및 TLS/SSL(전송 암호화)과 함께 사용하면 규제 요건을 준수하는 데 도움이 됩니다.
성능 문제 진단
MongoDB를 사용하여 애플리케이션을 개발하고 운영할 때 애플리케이션으로서 데이터베이스의 성능을 분석할 수 있습니다. MongoDB 성능에서는 성능에 영향을 미칠 수 있는 몇 가지 운영 요인에 대해 설명합니다.
복제 및 모니터링
모든 MongoDB 인스턴스에 대한 기본 모니터링 요구 사항 외에도, 복제본 세트의 경우 관리자는 복제 지연을 모니터링해야 합니다. 복제 지연은 복사( 복제)를 통해 프라이머리에서 보조로 쓰기 작업을 수행하는 데 걸리는 시간을 나타냅니다. 약간의 지연은 허용될 수 있지만 복제 지연이 증가하면 다음과 같은 심각한 문제가 발생합니다.
프라이머리에 대한 캐시 압박이 커지고 있습니다.
지연 기간 동안 발생한 작업은 하나 이상의 세컨더리 서버에 복제되지 않습니다. 데이터 지속성을 보장하기 위해 복제를 사용하는 경우, 예외적으로 긴 지연은 데이터 세트의 무결성에 영향을 줄 수 있습니다.
복제 지연이 작업 로그(oplog)의 길이를 초과하는 경우, MongoDB는 세컨더리에서 초기 동기화를 수행하여 프라이머리에서 모든 데이터를 복사하고 모든 인덱스를 다시 빌드해야 합니다. [1] 일반적인 상황에서는 흔하지 않지만, oplog를 기본값보다 작게 구성하면 문제가 발생할 수 있습니다.
참고
oplog의 크기는 첫 실행 중에
mongod
명령의--oplogSize
인수를 사용해야지만 가능하며, 혹은 가급적이면 MongoDB 구성 파일의oplogSizeMB
설정을 사용하여 구성하는 것이 좋습니다.--replSet
옵션으로 실행하기 전에 명령줄에서 이를 지정하지 않으면mongod
에서 기본 크기의 oplog를 생성합니다.기본적으로 oplog는 64비트 시스템에서 사용 가능한 총 디스크 공간의 5 %입니다. oplog 크기 변경에 대한 자세한 내용은 자체 관리형 복제 세트 멤버의 Oplog 크기 변경을참조하십시오.
흐름 제어
MongoDB 4.2부터 관리자는 majority
committed
지연을 구성 가능한 최대값 flowControlTargetLagSeconds
이하로 유지하는 것을 목표로 기본이 쓰기를 적용하는 속도를 제한할 수 있습니다.
기본적으로 흐름 제어는 enabled
입니다.
참고
흐름 제어가 작동하려면 복제본 세트/샤딩된 클러스터에 4.2
의 featureCompatibilityVersion(fCV) 과 majority enabled
의 읽기 우려 사항이 있어야 합니다. 즉, fCV가 4.2
가 아니거나 읽기 문제 과반수가 비활성화된 경우 활성화된 흐름 제어는 효과가 없습니다.
참조: 복제 지연 확인.
복제본 세트 상태
복제 문제는 대부분 구성원 간의 네트워크 연결 문제로 인해 발생하거나 애플리케이션 및 복제 트래픽을 지원할 리소스가 없는 프라이머리 계정으로 인해 발생하는 경우가 많습니다. 복제본의 상태를 확인하려면 셸에서 replSetGetStatus
또는 다음 도우미를 사용합니다.
rs.status()
replSetGetStatus
참조는 이 출력에 대한 보다 심층적인 개요를 제공합니다. 일반적으로 optimeDate
값을 확인하고 프라이머리 노드와 세컨더리 노드 간의 시간 차이에 특히 유의하세요.
[1] | 2}가 삭제되는 것을 방지하기 위해 oplog가 구성된 크기 제한을 초과하여 커질 수 majority commit point 있습니다. |
Oplog 항목 지연 적용
이제 복제본 세트의 세컨더리 멤버가 느린 작업 임곗값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다.
diagnostic log
에 세컨더리 멤버에 대해 기록합니다.applied op: <oplog entry> took <num>ms
텍스트와 함께REPL
구성 요소 아래에 기록됩니다.로그 수준(시스템 또는 구성 요소 수준)에 의존하지 않습니다.
프로파일링 수준에 의존하지 않습니다.
slowOpSampleRate
의 영향을 받습니다.
프로파일러는 느린 oplog 항목을 캡처하지 않습니다.
샤딩 및 모니터링
대부분의 경우 샤딩된 클러스터의 구성 요소는 다른 모든 MongoDB 인스턴스와 동일한 모니터링 및 분석의 이점을 누릴 수 있습니다. 또한 클러스터에는 데이터가 노드 간에 효과적으로 분산되고 샤딩 작업이 적절하게 작동하도록 하기 위한 추가적인 모니터링이 필요합니다.
Config 서버
config 데이터베이스는 어떤 문서가 어떤 샤드에 있는지 식별하는 맵을 유지 관리합니다. 클러스터는 청크가 샤드 사이를 이동할 때 이 맵을 업데이트합니다. 구성 서버에 액세스할 수 없게 되면 청크 이동 및 mongos
인스턴스 시작과 같은 특정 샤딩 작업을 사용할 수 없게 됩니다. 그러나 클러스터는 이미 실행 중인 mongos
인스턴스에서 계속 액세스할 수 있습니다.
구성 서버에 액세스할 수 없으면 샤딩된 클러스터의 가용성에 심각한 영향을 미칠 수 있으므로, 구성 서버를 모니터링하여 클러스터의 균형이 잘 유지되고 mongos
인스턴스가 다시 시작될 수 있도록 해야 합니다.
MongoDB Cloud Manager 및 Ops Manager는 config 서버를 모니터링하고 config 서버에 액세스할 수 없는 경우 알림을 생성할 수 있습니다. 자세한 내용은 MongoDB Cloud Manager 설명서 및 Ops Manager 설명서를 참조하세요.
밸런싱 및 청크 배포
가장 효과적인 샤딩된 클러스터 배포는 샤드 간에 청크 균형을 균등하게 유지합니다. 이를 용이하게 하기 위해, MongoDB는 청크가 항상 샤드 간에 최적으로 분산되도록 데이터를 분산하는 백그라운드 밸런서 프로세스를 갖추고 있습니다.
mongosh
내에서 mongos
에 db.printShardingStatus()
또는 sh.status()
명령을 실행합니다. 그러면 데이터베이스 이름과 청크 목록을 포함해 클러스터의 개요가 반환됩니다.
스테일(Stale) 잠금 장치
데이터베이스의 잠금 상태를 확인하려면 mongosh
를 사용하여 mongos
인스턴스에 연결합니다. 다음 명령 시퀀스를 실행하여 config
데이터베이스로 전환하고 샤드 데이터베이스에서 미해결 잠금을 모두 표시합니다.
use config db.locks.find()
밸런싱 프로세스에는 다른 밸런싱 활동이 발생하지 않도록 하는 특수 '밸런서' 잠금이 사용됩니다. config
데이터베이스에서 다음 명령을 사용하여 '밸런서' 잠금을 확인합니다.
db.locks.find( { _id : "balancer" } )
CSRS 구성 서버의 프라이머리 서버는 "ConfigServer"라는 프로세스 ID를 사용하여 '밸런서' 잠금을 유지합니다. 이 잠금은 절대 해제되지 않습니다. 밸런서가 실행 중인지 확인하려면 밸런서가 실행 중인지 확인을 참조하세요.
Storage Node Watchdog
참고
Storage Node Watchdog는 커뮤니티 및 MongoDB Enterprise 에디션 모두에서 사용할 수 있습니다.
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
가 종료되면 동일한 컴퓨터에서 완전히 다시 시작하지 못할 수 있습니다.
참고
Symlinks
모니터링되는 디렉토리 중 하나가 다른 볼륨에 대한 심볼릭 링크인 경우 Storage Node Watchdog은 심볼릭 링크 대상을 모니터링하지 않습니다.
예를 들어, mongod
가 storage.directoryPerDB: true
(또는 --directoryperdb
)를 사용하고 데이터베이스 디렉토리를 다른 볼륨에 심볼릭 링크하는 경우 Storage Node Watchdog은 심볼릭 링크를 따라 타깃을 모니터링하지 않습니다.
Storage Node Watchdog가 응답하지 않는 파일 시스템을 감지하고 종료하는 데 걸리는 최대 시간은 watchdogPeriodSeconds
값의 거의 두 배에 달합니다.