로그 메시지
개요
정상 작동의 일환으로, MongoDB는 들어오는 연결, 명령 실행, 발생한 문제 등의 항목을 포함한 이벤트의 실행 로그를 유지합니다. 일반적으로 로그 메시지는 문제를 진단하고, 배포를 모니터링하고, 성능을 조정하는 데 유용합니다.
로그 메시지를 얻으려면 다음 방법 중 하나를 사용할 수 있습니다.
구성된 로그 대상에서 로그를 봅니다.
getLog
명령을 실행합니다.MongoDB Atlas를 통해 로그를 다운로드하세요. 자세히 알아보려면 로그 다운로드를 참조하세요.
구조화된 로깅
mongod
/ mongos
인스턴스는 모든 로그 메시지를 구조화된 JSON 형식으로 출력합니다. 로그 항목은 일련의 키-값 쌍으로 작성되고 각 키는 '심각도'와 같이 로그 메시지 필드 유형을 나타내며 각 해당 값은 '정보'와 같이 해당 필드 유형에 대한 관련 로깅 정보를 기록합니다. 이전에는 로그 항목이 일반 텍스트로 출력되었습니다.
예시
다음은 MongoDB 로그 파일에 표시되는 JSON 형식의 로그 메시지 예시입니다.
{"t":{"$date":"2020-05-01T15:16:17.180+00:00"},"s":"I", "c":"NETWORK", "id":12345, "ctx":"listener", "svc": "R", "msg":"Listening on", "attr":{"address":"127.0.0.1"}}
JSON 로그 항목은 가독성을 위해 Prettyprint 할 수 있습니다. 다음은 동일한 로그 항목이 Prettyprint 것입니다.
{ "t": { "$date": "2020-05-01T15:16:17.180+00:00" }, "s": "I", "c": "NETWORK", "id": 12345, "ctx": "listener", "svc": "R", "msg": "Listening on", "attr": { "address": "127.0.0.1" } }
예를 들어 이 로그 항목에서 s
키는 심각도를 의미하며 I
값은 '정보'를 의미합니다. c
는 구성 요소를 나타내며 NETWORK
는 특정 메시지가 '네트워크' 구성 요소와 관련이 있음을 나타냅니다. 다양한 필드 유형은 로그 메시지 필드 유형 섹션에 설명되어 있습니다.
키-값 쌍을 사용한 구조화된 로깅을 사용하면 자동화된 도구나 로그 수집 서비스에서 효율적으로 구문 분석할 수 있으며, 로그 메시지에 대한 프로그래밍 방식의 검색과 분석을 더 쉽게 수행할 수 있습니다. 구조화된 로그 메시지 분석의 예시는 구조화된 로그 메시지 구문 분석하기 섹션에서 확인할 수 있습니다.
참고
로그 파일에 쓸 수 없는 경우 mongod
은 종료됩니다. mongod
가 로그 파일에 쓸 수 있도록 하려면 로그 볼륨의 디스크 공간이 있고 로그가 회전하는지 확인하십시오.
JSON 로그 출력 형식
다음으로 전송되는 출력을 포함해 모든 로그는 JSON 형식으로 출력됩니다.
로그 파일
syslog
스탯아웃(표준 아웃) 로그 대상
getLog
명령의 출력도 JSON 형식입니다.
각 로그 항목은 다음과 같은 레이아웃과 필드 순서를 따르는 Relaxed Extended JSON v2.0 사양을 따르는 독립된 JSON 객체로 출력됩니다.
{ "t": <Datetime>, // timestamp "s": <String>, // severity "c": <String>, // component "id": <Integer>, // unique identifier "ctx": <String>, // context "svc": <String>, // service "msg": <String>, // message body "attr": <Object>, // additional attributes (optional) "tags": <Array of strings>, // tags (optional) "truncated": <Object>, // truncation info (if truncated) "size": <Object> // original size of entry (if truncated) }
필드 설명:
필드 이름 | 유형 | 설명 |
---|---|---|
t | Datetime | ISO-8601 형식의 로그 메시지 타임스탬프입니다. 예시는 타임스탬프를 참조하세요. |
s | 문자열 | 로그 메시지의 짧은 심각도 코드입니다. 예시는 심각도에서 확인하세요. |
c | 문자열 | 로그 메시지의 전체 구성 요소 문자열입니다. 예시는 컴포넌트를 참조하세요. |
id | Integer | 로그 문의 고유 식별자입니다. 예시는 알려진 로그 ID로 필터링을 참조하세요. |
ctx | 문자열 | 로그 문을 생성한 스레드의 이름입니다. |
svc | 문자열 | 컨텍스트에서 로그 성명서 이 작성된 서비스의 이름입니다. ' 샤드'는 S , '라우터'는 R , '알 수 없음' 또는 '없음'은 - 로 표시합니다. |
msg | 문자열 | 서버 또는 드라이버에서 전달된 로그 출력 메시지입니다. 필요한 경우 JSON 사양에 따라 메시지가 이스케이프 처리됩니다. |
attr | 객체 | One or more key-value pairs for additional log attributes. If a log message does not include any additional attributes, the attr object is omitted.Attribute values may be referenced by their key name in the msg message body, depending on the message. If necessary, theattributes are escaped according to the JSON specification. |
tags | 문자열 배열 | 로그 문에 적용 가능한 모든 태그를 나타내는 문자열입니다. 예를 들어 ["startupWarnings"] 입니다. |
truncated | 객체 | 해당되는 경우 로그 메시지 잘림에 대한 정보입니다. 로그 항목에 잘린 attr 속성이 하나 이상 포함된 경우에만 포함됩니다. |
size | 객체 | 로그 항목이 잘린 경우 로그 항목의 원래 크기입니다. 로그 항목에 잘린 attr 속성이 하나 이상 포함된 경우에만 포함됩니다. |
이스케이핑
message 및 attributes 필드는 Relaxed Extended JSON v2.0 사양에 따라 필요에 따라 제어 문자를 이스케이프합니다.
대체 문자 | 시퀀스 이스케이프 |
---|---|
따옴표 ( " ) | \" |
백슬래시 ( \ ) | \\ |
백스페이스 ( 0x08 ) | \b |
폼피드 ( 0x0C ) | \f |
뉴라인 ( 0x0A ) | \n |
캐리지 리턴 ( 0x0D ) | \r |
가로 탭 ( 0x09 ) | \t |
위에 나열되지 않은 제어 문자는 \uXXXX
로 이스케이프됩니다. 여기서 " XXXX " 는 16진수의 유니코드 코드 포인트입니다. 잘못된 UTF-8 인코딩이 있는 바이트는 \ufffd
로 표시되는 유니코드 대체 문자로 대체됩니다.
메시지 이스케이프의 예는 예시 섹션에나와 있습니다.
잘라내기
버전 7.3에서 변경되었습니다.
속성이 maxLogSizeKB
(기본값: 10KB)로 정의된 최대 크기를 초과하는 경우 해당 속성은 잘려나갑니다. 잘린 속성은 구성된 제한을 초과하는 로그 데이터를 생략하지만 항목의 JSON 형식을 유지하여 항목이 파싱 가능한 상태로 유지되도록 합니다.
예를 예시, 다음 JSON 객체 는 $in
필드 에 5000 요소가 잘리지 않고 포함된 command
속성을 나타냅니다.
참고
로그 항목 예시는 가독성을 위해 서식이 변경되었습니다.
{ "command": { "find": "mycoll", "filter": { "value1": { "$in": [0, 1, 2, 3, ... 4999] }, "value2": "foo" }, "sort": { "value1": 1 }, "lsid":{"id":{"$uuid":"80a99e49-a850-467b-a26d-aeb2d8b9f42b"}}, "$db": "testdb" } }
이 예시에서는 command
속성의 크기가 후속 요소를 포함할 경우 maxLogSizeKB
를 초과하므로 $in
배열은 376번째 요소에서 잘립니다. command
속성의 나머지는 생략됩니다. 잘린 로그 항목은 다음 출력과 유사합니다.
{ "t": { "$date": "2021-03-17T20:30:07.212+01:00" }, "s": "I", "c": "COMMAND", "id": 51803, "ctx": "conn9", "msg": "Slow query", "attr": { "command": { "find": "mycoll", "filter": { "value1": { "$in": [ 0, 1, ..., 376 ] // Values in array omitted for brevity } } }, ... // Other attr fields omitted for brevity }, "truncated": { "command": { "truncated": { "filter": { "truncated": { "value1": { "truncated": { "$in": { "truncated": { "377": { "type": "double", "size": 8 } }, "omitted": 4623 } } } }, "omitted": 1 } }, "omitted": 3 } }, "size": { "command": 21692 } }
하나 이상의 잘린 속성이 포함된 로그 항목에는 로그 항목의 각 잘린 속성에 대해 다음 정보를 제공하는 중첩된 truncated
객체가 포함됩니다.
잘린 속성
잘라내기를 트리거한 해당 속성의 특정 하위 객체(해당되는 경우)
잘린 필드의 데이터
type
입니다.잘림을 트리거하는 요소의
size
(바이트 단위)잘림으로 인해 각 하위 객체 아래에
omitted
있던 요소 수입니다.
잘린 속성이 있는 로그 항목은 항목 끝에 잘리기 전 속성의 원래 크기(이 경우 21692
또는 약 22KB)를 나타내는 추가 size
필드 를 포함할 수도 있습니다. 이 마지막 size
필드 는 truncated
객체 의 size
필드 와 다른 경우, 즉 속성의 총 객체 크기가 잘린 하위 객체의 크기와 다른 경우에만 표시됩니다. 위의 예시 경우입니다.
패딩
파일 또는 syslog 로그 대상으로 출력할 때 고정 너비 글꼴로 볼 때 가독성을 높이기 위해 심각도, 컨텍스트 및 ID 필드 뒤에 패딩이 추가됩니다.
다음 MongoDB 로그 파일 발췌는 이 패딩을 보여줍니다.
{"t":{"$date":"2020-05-18T20:18:12.724+00:00"},"s":"I", "c":"CONTROL", "id":23285, "ctx":"main", "svc": "R", "msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"} {"t":{"$date":"2020-05-18T20:18:12.734+00:00"},"s":"W", "c":"ASIO", "id":22601, "ctx":"main", "svc": "R", "msg":"No TransportLayer configured during NetworkInterface startup"} {"t":{"$date":"2020-05-18T20:18:12.734+00:00"},"s":"I", "c":"NETWORK", "id":4648601, "ctx":"main", "svc": "R", "msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOpenServer, tcpFastOpenClient, and tcpFastOpenQueueSize."} {"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"STORAGE", "id":4615611, "ctx":"initandlisten", "svc": "R", "msg":"MongoDB starting", "attr":{"pid":10111,"port":27001,"dbPath":"/var/lib/mongo","architecture":"64-bit","host":"centos8"}} {"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"CONTROL", "id":23403, "ctx":"initandlisten", "svc": "R", "msg":"Build Info", "attr":{"buildInfo":{"version":"4.4.0","gitVersion":"328c35e4b883540675fb4b626c53a08f74e43cf0","openSSLVersion":"OpenSSL 1.1.1c FIPS 28 May 2019","modules":[],"allocator":"tcmalloc","environment":{"distmod":"rhel80","distarch":"x86_64","target_arch":"x86_64"}}}} {"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"CONTROL", "id":51765, "ctx":"initandlisten", "svc": "R", "msg":"Operating System", "attr":{"os":{"name":"CentOS Linux release 8.0.1905 (Core) ","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}
Pretty Printing
MongoDB 구조화된 로깅으로 작업할 때 타사 jq 명령줄 유틸리티는 로그 항목을 쉽고 예쁘게 인쇄하고 강력한 키 기반 매칭 및 필터링을 하는 데 유용한 도구입니다.
jq
는 오픈 소스 JSON 파서이며 Linux, Windows, macOS에서 사용할 수 있습니다.
jq
를 사용하여 다음과 같이 로그 항목을 pretty-print 할 수 있습니다.
전체 로그 파일을 pretty-print 합니다.
cat mongod.log | jq 가장 최근 로그 항목을 pretty-print 합니다.
cat mongod.log | tail -1 | jq
MongoDB 구조화된 로그로 작업하는 더 많은 예는 구조화된 로그 메시지 구문 분석하기 섹션에서 확인할 수 있습니다.
로그 메시지 대상 구성
MongoDB 로그 메시지는 파일, syslog 또는 stdout (표준 출력)으로 출력할 수 있습니다.
로그 출력 대상을 구성하려면 구성 파일 또는 명령줄에서 다음 설정 중 하나를 사용합니다.
- 구성 파일:
파일 또는
systemLog.destination
시스템 로그를 위한 옵션
- 명령줄:
파일이나 syslog 중 하나를 지정하지 않으면 모든 로깅 출력이 stdout으로 전송됩니다.
로깅 설정 및 옵션의 전체 목록은 다음을 참조하세요.
- 구성 파일:
- 명령줄:
참고
파일 또는 syslog 로그 대상을 사용하지 않을 때 시작 중 치명적인 오류 또는 잘못 구성된 로깅 설정과 관련된 메시지와 같이 stderr
(표준 오류)로 전송되는 오류 메시지는 로그 출력 대상 설정의 영향을 받지 않으며 일반 텍스트 형식으로 stderr
에 인쇄됩니다.
로그 메시지 필드 유형
타임스탬프
타임스탬프 필드 유형은 기록된 이벤트가 발생한 정확한 날짜와 시간을 나타냅니다.
{ "t": { "$date": "2020-05-01T15:16:17.180+00:00" }, "s": "I", "c": "NETWORK", "id": 12345, "ctx": "listener", "svc": "R", "msg": "Listening on", "attr": { "address": "127.0.0.1" } }
파일 또는 syslog [1]에 로깅할 때 타임스탬프의 기본 형식은 iso8601-local
입니다. 타임스탬프 형식을 수정하려면 --timeStampFormat
런타임 옵션 또는 systemLog.timeStampFormat
설정을 사용합니다.
타임스탬프 필드를 기준으로 필터링하는 로그 구문 분석 예는 날짜 범위별 필터링을 참조하세요.
참고
ctime
타임스탬프 형식은 더 이상 지원되지 않습니다.
[1] | syslog에 로깅하는 경우, syslog 데몬은 메시지를 로깅할 때 타임스탬프를 생성하며, MongoDB가 메시지를 발행할 때는 생성하지 않습니다. 이로 인해 특히 시스템 부하가 심한 경우 로그 항목에 잘못된 타임스탬프가 표시될 수 있습니다. |
심각도 (Severity)
심각도 필드 유형은 기록된 이벤트와 관련된 심각도 수준을 나타냅니다.
{ "t": { "$date": "2020-05-01T15:16:17.180+00:00" }, "s": "I", "c": "NETWORK", "id": 12345, "ctx": "listener", "svc": "R", "msg": "Listening on", "attr": { "address": "127.0.0.1" } }
심각도 수준은 "치명적" (가장 심각함)에서 "디버그" (가장 덜 심각함)까지 다양합니다.
수준 | 설명 |
---|---|
F | 치명적 |
E | 오류 |
W | 경고 |
I | 정보 제공, 상세도 수준 0 의 경우 |
D1 - D5 |
다양한 구성 요소의 상세 수준을 지정하여 MongoDB가 출력하는 정보 및 디버그 메시지의 양을 결정할 수 있습니다. 이 수준 이상의 심각도 카테고리는 항상 표시됩니다. [2] 상세 수준을 설정하려면 로그 상세 수준 구성을 참조합니다.
구성 요소
컴포넌트 필드 유형은 네트워크 또는 명령과 같이 로깅된 이벤트가 속해 있는 카테고리를 나타냅니다.
{ "t": { "$date": "2020-05-01T15:16:17.180+00:00" }, "s": "I", "c": "NETWORK", "id": 12345, "ctx": "listener", "svc": "R", "msg": "Listening on", "attr": { "address": "127.0.0.1" } }
각 구성 요소는 자체 상세도 필터를 통해 개별적으로 구성할 수 있습니다. 사용 가능한 구성 요소는 다음과 같습니다:
ACCESS
인증 등 액세스 제어와 관련된 메시지입니다.
ACCESS
구성 요소의 로그 수준을 지정하려면systemLog.component.accessControl.verbosity
설정을 사용하세요.
COMMAND
데이터베이스 명령과 관련된 메시지(예:
count
)입니다.COMMAND
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.command.verbosity
설정을 사용합니다.
CONTROL
초기화와 같은 제어 활동과 관련된 메시지입니다.
CONTROL
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.control.verbosity
설정을 사용합니다.
ELECTION
특히 복제본 세트 투표와 관련된 메시지입니다.
ELECTION
구성 요소의 로그 수준을 지정하려면systemLog.component.replication.election.verbosity
매개 변수를 설정하세요.REPL
는ELECTION
의 상위 구성 요소입니다.systemLog.component.replication.election.verbosity
가 설정되지 않은 경우 MongoDB는ELECTION
구성요소에 대해REPL
상세 수준을 사용합니다.
FTDC
서버 통계, 상태 메시지 등 진단 데이터 수집 메커니즘과 관련된 메시지입니다.
FTDC
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.ftdc.verbosity
설정을 사용합니다.
GEO
GeoJSON 모양 확인 등 지리공간 모양 분석과 관련된 메시지입니다.
GEO
구성 요소의 로그 수준을 지정하려면systemLog.component.geo.verbosity
매개변수를 설정하세요.
INDEX
인덱스 생성과 같은 인덱싱 작업과 관련된 메시지입니다.
INDEX
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.index.verbosity
매개 변수를 설정합니다.
INITSYNC
초기 동기화 작업과 관련된 메시지입니다.
INITSYNC
구성 요소의 로그 수준을 지정하려면systemLog.component.replication.initialSync.verbosity
매개변수를 설정하세요.REPL
는INITSYNC
의 상위 구성 요소입니다.systemLog.component.replication.initialSync.verbosity
가 설정되지 않은 경우 MongoDB는INITSYNC
구성요소에 대해REPL
상세 수준을 사용합니다.
JOURNAL
특히 스토리지 저널링 작업과 관련된 메시지입니다.
JOURNAL
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.journal.verbosity
설정을 사용합니다.STORAGE
는JOURNAL
의 상위 구성 요소입니다.systemLog.component.storage.journal.verbosity
가 설정되지 않은 경우 MongoDB는JOURNAL
구성요소에 대해STORAGE
상세 수준을 사용합니다.
NETWORK
연결 수락과 같은 네트워크 활동과 관련된 메시지입니다.
NETWORK
구성 요소의 로그 수준을 지정하려면systemLog.component.network.verbosity
매개변수를 설정하세요.
QUERY
쿼리 플래너 활동을 포함하여 쿼리와 관련된 메시지입니다.
QUERY
구성 요소의 로그 수준을 지정하려면systemLog.component.query.verbosity
매개변수를 설정하세요.
QUERYSTATS
$queryStats
작업과 관련된 메시지입니다.QUERYSTATS
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.queryStats.verbosity
매개 변수를 설정하다 합니다.
RECOVERY
스토리지 복구 활동과 관련된 메시지입니다.
RECOVERY
구성 요소의 로그 수준을 지정하려면systemLog.component.storage.recovery.verbosity
설정을 사용하세요.STORAGE
는RECOVERY
의 상위 구성 요소입니다.systemLog.component.storage.recovery.verbosity
가 설정되지 않은 경우 MongoDB는RECOVERY
구성요소에 대해STORAGE
상세 수준을 사용합니다.
REPL
초기 동기화, 하트비트, 안정적인 상태 복제, 롤백 등 복제본 세트와 관련된 메시지입니다. [2]
REPL
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.replication.verbosity
매개 변수를 설정합니다.REPL
은ELECTION
,INITSYNC
,REPL_HB
및ROLLBACK
구성 요소의 상위 구성 요소입니다.
REPL_HB
특히 복제본 세트 하트비트와 관련된 메시지입니다.
REPL_HB
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.replication.heartbeats.verbosity
매개 변수를 설정합니다.REPL
는REPL_HB
의 상위 구성 요소입니다.systemLog.component.replication.heartbeats.verbosity
가 설정되지 않은 경우 MongoDB는REPL_HB
구성요소에 대해REPL
상세 수준을 사용합니다.
ROLLBACK
롤백 작업과 관련된 메시지입니다.
ROLLBACK
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.replication.rollback.verbosity
매개 변수를 설정합니다.REPL
는ROLLBACK
의 상위 구성 요소입니다.systemLog.component.replication.rollback.verbosity
가 설정되지 않은 경우 MongoDB는ROLLBACK
구성요소에 대해REPL
상세 수준을 사용합니다.
SHARDING
mongos
스타트업과 같은 샤딩 활동과 관련된 메시지입니다.SHARDING
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.sharding.verbosity
설정을 사용합니다.
STORAGE
fsync
명령과 관련된 프로세스 등 저장소 활동과 관련된 메시지입니다.STORAGE
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.verbosity
설정을 사용합니다.
TXN
다중 문서 트랜잭션과 관련된 메시지입니다.
TXN
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.transaction.verbosity
설정을 사용합니다.
WRITE
update
명령과 같은 쓰기 작업과 관련된 메시지입니다.WRITE
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.write.verbosity
설정을 사용합니다.
WT
버전 5.3에 추가.
WiredTiger 스토리지 엔진과 관련된 메시지입니다.
WT
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.verbosity
설정을 사용합니다.
WTBACKUP
버전 5.3에 추가.
WiredTiger 스토리지 엔진에서 수행한 백업 작업과 관련된 메시지입니다.
WTBACKUP
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtBackup.verbosity
설정을 사용합니다.
WTCHKPT
버전 5.3에 추가.
WiredTiger 스토리지 엔진이 수행하는 체크포인트 작업과 관련된 메시지입니다.
WTCHKPT
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtCheckpoint.verbosity
설정을 사용합니다.
WTCMPCT
버전 5.3에 추가.
WiredTiger 스토리지 엔진에서 수행하는 압축 작업과 관련된 메시지입니다.
WTCMPCT
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtCompact.verbosity
설정을 사용합니다.
WTEVICT
버전 5.3에 추가.
WiredTiger storage engine에서 수행한 제거 작업과 관련된 메시지입니다.
WTEVICT
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtEviction.verbosity
설정을 사용합니다.
WTHS
버전 5.3에 추가.
WiredTiger storage engine의 기록 저장과 관련된 메시지입니다.
WTHS
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtHS.verbosity
설정을 사용합니다.
WTRECOV
버전 5.3에 추가.
WiredTiger 스토리지 엔진에서 수행한 복구 작업과 관련된 메시지입니다.
WTRECOV
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtRecovery.verbosity
설정을 사용합니다.
WTRTS
버전 5.3에 추가.
WiredTiger storage engine이 수행하는 안정화 롤백(RTS) 작업과 관련된 메시지입니다.
WTRTS
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtRTS.verbosity
설정을 사용합니다.
WTSLVG
버전 5.3에 추가.
WiredTiger storage engine에서 수행되는 회수 작업과 관련된 메시지입니다.
WTSLVG
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtSalvage.verbosity
설정을 사용합니다.
WTTS
버전 5.3에 추가.
WiredTiger storage engine에서 사용하는 타임스탬프와 관련된 메시지입니다.
WTTS
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtTimestamp.verbosity
설정을 사용합니다.
WTTXN
버전 5.3에 추가.
WiredTiger storage engine에서 수행되는 트랜잭션과 관련된 메시지입니다.
WTTXN
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtTransaction.verbosity
설정을 사용합니다.
WTVRFY
버전 5.3에 추가.
WiredTiger storage engine에서 수행한 검증 작업과 관련된 메시지입니다.
WTVRFY
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtVerify.verbosity
설정을 사용합니다.
WTWRTLOG
버전 5.3에 추가.
WiredTiger 스토리지 엔진이 수행하는 로그 쓰기 작업과 관련된 메시지입니다.
WTWRTLOG
구성 요소에 대한 로그 수준을 지정하려면systemLog.component.storage.wt.wtWriteLog.verbosity
설정을 사용합니다.
-
명명된 컴포넌트와 연결되지 않은 메시지. 명명되지 않은 구성 요소의 기본 로그 수준은
systemLog.verbosity
설정에 지정되어 있습니다.systemLog.verbosity
설정은 명명된 구성 요소와 명명되지 않은 구성 요소 모두에 대한 기본 설정입니다.
컴포넌트 필드를 필터링하는 로그 구문 분석 예시는 컴포넌트별 필터링을 참조하세요.
고객 데이터
MongoDB 드라이버 및 클라이언트 애플리케이션(mongosh
포함)은 서버에 연결할 때 식별 정보를 보내는 기능이 있습니다. 연결이 설정된 후 클라이언트는 연결을 제거했다가 다시 설정하지 않는 한 식별 정보를 다시 전송하지 않습니다.
이 식별 정보는 로그 항목의 attributes 필드에 포함되어 있습니다. 포함되는 정확한 정보는 클라이언트마다 다릅니다.
다음은 mongosh
연결에서 전송된 클라이언트 데이터 문서가 포함된 샘플 로그 메시지입니다. 클라이언트 데이터는 attributes 필드의 doc
객체에 포함되어 있습니다.
{"t":{"$date":"2020-05-20T16:21:31.561+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn202", "svc": "R", "msg":"client metadata", "attr":{"remote":"127.0.0.1:37106","client":"conn202","doc":{"application":{"name":"MongoDB Shell"},"driver":{"name":"MongoDB Internal Client","version":"4.4.0"},"os":{"type":"Linux","name":"CentOS Linux release 8.0.1905 (Core) ","architecture":"x86_64","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}}
복제 세트의 보조 구성원이 주 구성원에 대한 연결을 시작하면 유사한 데이터를 전송합니다. 이 시작 연결이 포함된 샘플 로그 메시지는 다음과 같이 나타날 수 있습니다. 클라이언트 데이터는 attributes 필드의 doc
객체에 포함되어 있습니다.
{"t":{"$date":"2020-05-20T16:33:40.595+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn214", "svc": "R", "msg":"client metadata", "attr":{"remote":"127.0.0.1:37176","client":"conn214","doc":{"driver":{"name":"NetworkInterfaceTL","version":"4.4.0"},"os":{"type":"Linux","name":"CentOS Linux release 8.0.1905 (Core) ","architecture":"x86_64","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}}
클라이언트 데이터를 보여주는 pretty-printed 예시는 예시 섹션을 참조하세요.
클라이언트 정보 및 필수 필드에 대한 전체 설명은 MongoDB 핸드셰이크 사양을 참조하세요.
상세도 수준
로깅 상세도 수준을 지정하여 MongoDB가 출력하는 로그 메시지의 양을 늘리거나 줄일 수 있습니다. 상세도 수준은 모든 구성 요소에 대해 함께 조정하거나 특정 명명된 구성 요소에 대해 개별적으로 조정할 수 있습니다.
자세한 정도는 심각도 범주 Informational(정보) 및 Debug(디버그)의 로그 항목에 영향을 줍니다. 이 수준 이상의 심각도 범주는 항상 표시됩니다.
상세 수준을 높은 값으로 설정하여 디버깅 또는 개발을 위한 세부 로깅을 표시하거나, 검증된 프로덕션 배포에서 로그에 대한 쓰기를 최소화하려면 낮은 값으로 설정할 수 있습니다. [2]
현재 로그 상세도 수준 보기
현재 상세도 수준을 보려면 db.getLogComponents()
메서드를 사용합니다:
db.getLogComponents()
출력은 다음과 비슷할 수 있습니다.
{ "verbosity" : 0, "accessControl" : { "verbosity" : -1 }, "command" : { "verbosity" : -1 }, ... "storage" : { "verbosity" : -1, "recovery" : { "verbosity" : -1 }, "journal" : { "verbosity" : -1 } }, ...
초기 verbosity
항목은 모든 구성 요소에 대한 상위 상세 수준을 나타냅니다. accessControl
과 같이 뒤에 오는 개별 명명된 구성 요소는 해당 구성 요소에 대한 특정 상세 수준을 나타내며 설정된 경우 해당 특정 구성 요소에 대한 전역 상세 수준을 재정의합니다.
값 -1
은 구성 요소가 상위 구성 요소를 상속한 경우(위의 recovery
와 마찬가지로 storage
에서 상속받음), 그렇지 않은 경우 전역 상세 수준(위의 command
와 마찬가지)을 상속함을 나타냅니다. 상속 관계는 구성 요소 섹션에서 확인할 수 있습니다.
로그 상세도 수준 구성
systemLog.verbosity
및 systemLog.component.<name>.verbosity
설정, logComponentVerbosity
매개변수 또는 db.setLogLevel()
방법을 사용하여 상세도 수준을 구성할 수 있습니다. [2]
systemLog
상세도 설정
모든 구성 요소에 대한 기본 로그 수준을 구성하려면 systemLog.verbosity
설정을 사용합니다. 특정 구성 요소의 수준을 구성하려면 systemLog.component.<name>.verbosity
설정을 사용하세요.
예를 들어, 다음 구성은 systemLog.verbosity
를 1
로, systemLog.component.query.verbosity
를 2
로, systemLog.component.storage.verbosity
를 2
로, systemLog.component.storage.journal.verbosity
를 1
로 설정합니다.
systemLog: verbosity: 1 component: query: verbosity: 2 storage: verbosity: 2 journal: verbosity: 1
mongod
또는 mongos
인스턴스의 구성 파일 또는 명령줄에서 이러한 값을 설정할 수 있습니다.
구성에 명시적으로 지정되지 않은 모든 구성 요소의 상세도 수준은 -1
이며, 이는 상위 구성 요소가 있는 경우 상위 구성 요소의 상세도 수준을 상속하고, 없는 경우 전역 상세도 수준(systemLog.verbosity
)을 상속함을 나타냅니다.
logComponentVerbosity
Parameter
logComponentVerbosity
매개 변수를 설정하려면 변경할 상세도 설정이 있는 문서를 전달합니다.
예를 들어 다음은 default verbosity level
를 1
으로,query
을 2
로, 을 storage
2
11}로, 을 storage.journal
1
15}로 설정합니다.
db.adminCommand( { setParameter: 1, logComponentVerbosity: { verbosity: 1, query: { verbosity: 2 }, storage: { verbosity: 2, journal: { verbosity: 1 } } } } )
이러한 값은 mongosh
에서 설정합니다.
db.setLogLevel()
db.setLogLevel()
메서드를 사용하여 단일 컴포넌트 로그 수준을 업데이트합니다. 구성 요소의 경우 0
~ 5
의 상세 수준을 지정하거나 -1
를 지정하여 상위 구성 요소의 상세도를 상속할 수 있습니다. 예를 들어 다음은 systemLog.component.query.verbosity
을 상위 상세도로 설정합니다(기본 상세도).
db.setLogLevel(-1, "query")
이 값은 mongosh
에서 설정합니다.
[2] | (1, 2, 3, 4, 5) 이제 복제본 세트의 세컨더리 멤버가 느린 작업 임계값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다.
|
느린 작업 로깅
클라이언트 작업(예: 쿼리)은 그 기간이 느린 작업 임계값을 초과하거나 로그 상세도 수준이 1 이상인 경우 로그에 표시됩니다. [2] 이러한 로그 항목에는 작업과 관련된 전체 명령 객체가 포함됩니다.
읽기/쓰기 작업에 대한 프로파일러 항목 및 진단 로그 메시지(예: mongod/mongos logmessages) 에는 다음이 포함됩니다.
planCacheShapeHash
는 동일한 플랜 캐시 쿼리 형태를 갖는 느린 쿼리를 식별하는 데 도움이 됩니다.MongoDB 8.0 부터 기존
queryHash
필드 의 이름이planCacheShapeHash
로 변경되었습니다. 이전 MongoDB 버전을 사용하는 경우planCacheShapeHash
queryHash
가 표시됩니다.planCacheKey
느린 쿼리에 대한 쿼리 계획 캐시에 관해 더 많은 인사이트를 제공합니다.
MongoDB 5.0부터 느린 작업 로그 메시지에는 클라이언트 IP 주소를 지정하는 remote
필드가 포함됩니다.
MongoDB 6.2부터 저속 작업 로그 메시지에는 쿼리를 실행한 쿼리 엔진을 나타내는 queryFramework
필드가 포함됩니다.
queryFramework: "classic"
는 클래식 엔진이 쿼리를 실행했음을 나타냅니다.queryFramework: "sbe"
는 슬롯 기반 쿼리 실행 엔진이 쿼리를 완료했음을 나타냅니다.
MongoDB 6.1부터 느린 작업 로그 메시지에는 캐시 새로 고침 시간 필드가 포함됩니다.
MongoDB 6.3부터 느린 작업 로그 메시지와 데이터베이스 프로파일러 항목에 쿼리 작업에 소요된 총 CPU 시간(나노초)을 지정하는 cpuNanos
필드가 포함됩니다. cpuNanos
필드는 Linux 시스템에서만 사용할 수 있습니다.
MongoDB 7.0 (및 6.0.13)부터 5.0.24), 느린 쿼리 로그 메시지의 totalOplogSlotDurationMicros
는 쓰기 작업에서 커밋 타임스탬프를 가져와 스토리지 엔진 쓰기를 커밋한 후 실제로 커밋하기까지의 시간을 보여줍니다. mongod
는 병렬 쓰기를 지원합니다. 그러나 커밋 타임스탬프가 있는 쓰기 작업은 순서에 관계없이 커밋합니다.
예시
커밋 타임스탬프가 있는 다음 쓰기를 생각해 보세요.
타임스탬프1이 있는 writeA
타임스탬프2를 사용한 writeB
타임스탬프3을 사용한 writeC
writeB가 Timestamp2에서 처음으로 커밋한다고 가정합니다. 복제에서 oplog를 보조 복제 세트 멤버로 복제하려면 Timestamp1이 포함된 WriteA의 oplog 항목이 필요하기 때문에 WriteA가 커밋할 때까지 복제가 일시 중지됩니다.
느린 작업 로그 항목의 pretty-printed 예시는 로그 메시지 예시를 참조하세요.
MongoDB 8.0 부터 쿼리 형태의 queryShapeHash
필드도 사용 가능한 경우 느린 쿼리 로그에 포함됩니다.
MongoDB 8.0부터 느린 쿼리 출력에는 작업 대기열에 대한 정보가 포함된 queues
문서가 포함됩니다. queues
필드의 각 대기열에는 해당 대기열에서 작업에 소요된 총 누적 시간을 마이크로초 단위로 포함하는 totalTimeQueuedMicros
필드가 포함되어 있습니다.
필드에 로그인한 샤드를 기다리는 remoteOpWaitMillis
시간
버전 5.0에 추가.
MongoDB 5.0부터는 remoteOpWaitMillis
로그 필드를 사용하여 샤드에서 결과를 얻기 위한 대기 시간(밀리초)을 얻을 수 있습니다.
remoteOpWaitMillis
만 기록됩니다.
병합 작업이나 샤드 문제로 인해 쿼리 속도가 느려지는지 확인하려면 로그의 workingMillis
및 remoteOpWaitMillis
시간 필드를 비교하세요. workingMillis
는 쿼리를 완료하는 데 걸린 총 시간입니다. 구체적으로 다음과 같습니다.
workingMillis
가remoteOpWaitMillis
보다 약간 길면 샤드 응답을 기다리는 데 대부분의 시간이 소요된 것입니다. 예를 들어 17의workingMillis
, 15의remoteOpWaitMillis
입니다.workingMillis
가remoteOpWaitMillis
보다 상당히 긴 경우 대부분의 시간이 병합을 수행하는 데 소비된 것입니다. 예를 들어 100의workingMillis
, 15의remoteOpWaitMillis
입니다.
로그 편집
Queryable Encryption 로그 삭제
Queryable Encryption 사용하는 경우, 암호화된 컬렉션에 대한 CRUD 작업은 느린 쿼리 로그에서 생략됩니다. 자세한 내용은 Queryable Encryption편집을 참조하십시오.
엔터프라이즈 로그 삭제
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 JSON 로그 출력을 사용할 때의 일반적인 로그 구문 분석 워크플로를 보여줍니다.
로그 구문 분석 예시
MongoDB 구조화된 로깅으로 작업할 때 타사 jq 명령줄 유틸리티는 로그 항목을 쉽게 인쇄하고 강력한 키 기반 일치 및 필터링을 허용하는 유용한 도구입니다.
jq
는 오픈 소스 JSON 파서이며 Linux, Windows, macOS에서 사용할 수 있습니다.
이 예시에서는 jq
을 사용하여 로그 구문 분석을 간소화합니다.
고유 메시지 수 계산
다음 예에서는 지정된 로그 파일의 상위 10개 고유 메시지 값을 빈도별로 정렬하여 보여 줍니다.
jq -r ".msg" /var/log/mongodb/mongod.log | sort | uniq -c | sort -rn | head -10
연결 모니터링
원격 클라이언트 연결은 속성 객체의 "remote" 키 아래에 있는 로그에 표시됩니다. 다음은 로그 파일 과정에서 모든 고유 연결을 계산하고 발생 횟수에 따라 내림차순으로 표시합니다.
jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | sort | uniq -c | sort -r
이 명령은 동일한 IP 주소에서 연결하지만 다른 포트를 통해 연결하는 경우 다른 연결로 취급된다는 점에 유의하십시오. 다음과 같이 변경하여 IP 주소만 고려하도록 출력을 제한할 수 있습니다:
jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | awk -F':' '{print $1}' | sort | uniq -c | sort -r
드라이버 연결 분석
다음 예시에서는 모든 원격 MongoDB 드라이버 연결을 계산하여 각 드라이버 유형 및 버전을 발생 횟수에 따라 내림차순으로 표시합니다.
jq -cr '.attr.doc.driver' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn
클라이언트 유형 분석
다음 예시에서는 mongosh
을 포함한 원격 MongoDB 드라이버 연결 및 클라이언트 애플리케이션의 보고된 클라이언트 데이터를 분석하여 연결한 각 고유 운영 체제 유형에 대한 총계를 빈도별로 정렬하여 인쇄합니다.
jq -r '.attr.doc.os.type' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn
이 로그 필드에 보고된 문자열 "Darwin"은 macOS 클라이언트를 나타냅니다.
느린 쿼리 분석
느린 작업 로깅을 활성화하면 다음은 추가 분석을 위해 2000 밀리초 이상 걸린 느린 작업만 반환합니다.
jq 'select(.attr.workingMillis>=2000)' /var/log/mongodb/mongod.log
이 예시에 표시된 jq
필터에 대한 자세한 내용은 jq 문서에서 확인하세요.
구성 요소별 필터링
로그 구성 요소(JSON 로그 출력 형식의 세 번째 필드)는 지정된 로그 메시지가 속하는 일반 범주를 나타냅니다. 구성 요소별 필터링은 관련 이벤트에 대한 로그 메시지를 분석할 때 좋은 출발점인 경우가 많습니다.
다음 예시는 컴포넌트 유형 REPL의 로그 메시지만 인쇄합니다.
jq 'select(.c=="REPL")' /var/log/mongodb/mongod.log
다음 예시에서는 컴포넌트 유형 REPL을 제외한 모든 로그 메시지를 인쇄합니다.
jq 'select(.c!="REPL")' /var/log/mongodb/mongod.log
다음 예시는 컴포넌트 유형 REPL 또는 STORAGE의 로그 메시지를 인쇄하는 예시입니다:
jq 'select( .c as $c | ["REPL", "STORAGE"] | index($c) )' /var/log/mongodb/mongod.log
이 예시에 표시된 jq
필터에 대한 자세한 내용은 jq 문서에서 확인하세요.
알려진 로그 ID로 필터링
로그 ID( JSON 로그 출력 형식의 다섯 번째 필드)는 특정 로그 이벤트에 매핑되며, 연속적인 MongoDB 릴리스에 걸쳐 안정적으로 유지될 수 있도록 신뢰할 수 있습니다.
예를 들어 클라이언트 연결 후 연결 끊김을 보여주는 다음 두 가지 로그 이벤트에 관심이 있을 수 있습니다.
{"t":{"$date":"2020-06-01T13:06:59.027-0500"},"s":"I", "c":"NETWORK", "id":22943, "ctx":"listener", "svc": "R", "msg":"connection accepted from {session_remote} #{session_id} ({connectionCount}{word} now open)", "attr":{"session_remote":"127.0.0.1:61298", "session_id":164,"connectionCount":11,"word":" connections"}} {"t":{"$date":"2020-06-01T13:07:03.490-0500"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn157", "svc": "R", "msg":"end connection {remote} ({connectionCount}{word} now open)", "attr":{"remote":"127.0.0.1:61298","connectionCount":10,"word":" connections"}}
이 두 항목의 로그 ID는 각각 22943
및 22944
입니다. 그런 다음 다음 jq
구문을 사용하여 이러한 로그 ID만 표시하도록 로그 출력을 필터링하여 클라이언트 연결 활동만 효과적으로 표시할 수 있습니다.
jq 'select( .id as $id | [22943, 22944] | index($id) )' /var/log/mongodb/mongod.log
이 예시에 표시된 jq
필터에 대한 자세한 내용은 jq 문서에서 확인하세요.
날짜 범위별 필터링
타임스탬프 필드를 필터링하여 반환되는 로그 항목을 특정 날짜 범위로 제한하여 로그 출력을 더욱 세분화할 수 있습니다. 예를 들어 다음은 2020년 4월 15일에 발생한 모든 로그 항목을 반환합니다:
jq 'select(.t["$date"] >= "2020-04-15T00:00:00.000" and .t["$date"] <= "2020-04-15T23:59:59.999")' /var/log/mongodb/mongod.log
이 구문에는 밀리초를 포함하지만 시간대 오프셋을 제외한 전체 타임스탬프가 포함됩니다.
날짜 범위별 필터링은 위의 예와 결합하여 주간 보고서나 연간 요약 등을 생성할 수 있습니다. 다음 구문은 " 모니터링 연결 " 예시를 이전 버전에서 확장하여 결과를 2020년 5월로 제한합니다.
jq 'select(.t["$date"] >= "2020-05-01T00:00:00.000" and .t["$date"] <= "2020-05-31T23:59:59.999" and .attr.remote)' /var/log/mongodb/mongod.log
이 예시에 표시된 jq
필터에 대한 자세한 내용은 jq 문서에서 확인하세요.
로그 수집 서비스
로그 수집 서비스는 일반적으로 분산된 시스템 클러스터에서 로그 파일을 가져와 집계하여 중앙 위치에서 해당 데이터에 대한 지속적인 분석을 제공하는 타사 제품입니다.
JSON 로그 형식은 로그 수집 및 분석 서비스 작업 시 더욱 유연하게 사용할 수 있습니다. 일반 텍스트 로그는 일반적으로 이러한 제품에서 사용하기 전에 어떤 방식으로든 변환이 필요하지만, JSON 파일은 서비스에 따라 즉시 사용할 수 있는 경우가 많습니다. 또한 키-값 구조는 관심 있는 필드만 구체적으로 가져오고 나머지는 생략할 수 있는 기능을 제공하므로 이러한 서비스 필터링을 수행할 때 JSON 형식의 로그를 더 효과적으로 제어할 수 있습니다.
자세한 내용은 선택한 타사 로그 수집 서비스에 대한 설명서를 참조하세요.
로그 메시지 예시
다음 예에서는 JSON 출력 형식의 로그 메시지를 보여줍니다.
이러한 로그 메시지는 편의를 위해 pretty-printed 형식으로 표시됩니다.
시작 경고
이 예는 시작 경고를 보여줍니다.
{ "t": { "$date": "2020-05-20T19:17:06.188+00:00" }, "s": "W", "c": "CONTROL", "id": 22120, "ctx": "initandlisten", "svc": "R", "msg": "Access control is not enabled for the database. Read and write access to data and configuration is unrestricted", "tags": [ "startupWarnings" ] }
클라이언트 연결
이 예시는 클라이언트 데이터를 포함하는 클라이언트 연결을 보여 줍니다.
{ "t": { "$date": "2020-05-20T19:18:40.604+00:00" }, "s": "I", "c": "NETWORK", "id": 51800, "ctx": "conn281", "svc": "R", "msg": "client metadata", "attr": { "remote": "192.168.14.15:37666", "client": "conn281", "doc": { "application": { "name": "MongoDB Shell" }, "driver": { "name": "MongoDB Internal Client", "version": "4.4.0" }, "os": { "type": "Linux", "name": "CentOS Linux release 8.0.1905 (Core) ", "architecture": "x86_64", "version": "Kernel 4.18.0-80.11.2.el8_0.x86_64" } } } }
느린 작동
MongoDB 8.0부터는 작업의 총 대기 시간이 아니라 MongoDB가 해당 작업에 소요한 시간을 기준으로 느린 작업이 기록됩니다.
느린 작업 로그의 지표를 사용하여 작업의 수명 주기에서 작업이 시간을 소비하는 위치를 파악하면 성능 개선 가능성을 파악하는 데 도움이 됩니다.
다음 예시 로그 메시지에서:
쿼리를 실행하는 동안 리소스를 기다리는 데 소요된 시간은 다음 지표에 표시됩니다.
queues.execution.totalTimeQueuedMicros
timeAcquiringMicros
workingMillis
MongoDB가 작업에 소요하는 시간입니다.durationMillis
작업의 총 대기 시간입니다.
{ "t":{ "$date":"2024-06-01T13:24:10.034+00:00" }, "s":"I", "c":"COMMAND", "id":51803, "ctx":"conn3", "msg":"Slow query", "attr":{ "type":"command", "isFromUserConnection":true, "ns":"db.coll", "collectionType":"normal", "appName":"MongoDB Shell", "command":{ "find":"coll", "filter":{ "b":-1 }, "sort":{ "splitPoint":1 }, "readConcern":{ }, "$db":"db" }, "planSummary":"COLLSCAN", "planningTimeMicros":87, "keysExamined":0, "docsExamined":20889, "hasSortStage":true, "nBatches":1, "cursorExhausted":true, "numYields":164, "nreturned":99, "planCacheShapeHash":"9C05019A", "planCacheKey":"C41063D6", "queryFramework":"classic", "reslen":96, "locks":{ "ReplicationStateTransition":{ "acquireCount":{ "w":3 } }, "Global":{ "acquireCount":{ "r":327, "w":1 } }, "Database":{ "acquireCount":{ "r":1 }, "acquireWaitCount":{ "r":1 }, "timeAcquiringMicros":{ "r":2814 } }, "Collection":{ "acquireCount":{ "w":1 } } }, "flowControl":{ "acquireCount":1, "acquireWaitCount":1, "timeAcquiringMicros":8387 }, "readConcern":{ "level":"local", "provenance":"implicitDefault" }, "storage":{ }, "cpuNanos":20987385, "remote":"127.0.0.1:47150", "protocol":"op_msg", "queues":{ "ingress":{ "admissions":7, "totalTimeQueuedMicros":0 }, "execution":{ "admissions":328, "totalTimeQueuedMicros":2109 } }, "workingMillis":89, "durationMillis":101 } }
MongoDB 8.0 부터 기존 queryHash
필드 의 이름이 planCacheShapeHash
로 변경되었습니다. 이전 MongoDB 버전을 사용하는 경우 planCacheShapeHash
queryHash
가 표시됩니다.
이스케이핑
이 예시는 속성 객체의 setName
필드에 표시된 것처럼 문자 이스케이프에 대해 설명합니다.
{ "t": { "$date": "2020-05-20T19:11:09.268+00:00" }, "s": "I", "c": "REPL", "id": 21752, "ctx": "ReplCoord-0", "svc": "R", "msg": "Scheduling remote command request", "attr": { "context": "vote request", "request": "RemoteCommand 229 -- target:localhost:27003 db:admin cmd:{ replSetRequestVotes: 1, setName: \"my-replica-name\", dryRun: true, term: 3, candidateIndex: 0, configVersion: 2, configTerm: 3, lastAppliedOpTime: { ts: Timestamp(1589915409, 1), t: 3 } }" } }
보기
MongoDB 5.0에서 시작하는 뷰에 대한 느린 쿼리 로그 메시지에는 뷰 세부 정보가 들어있는 resolvedViews
필드가 포함됩니다.
"resolvedViews": [ { "viewNamespace": <String>, // namespace and view name "dependencyChain": <Array of strings>, // view name and collection "resolvedPipeline": <Array of documents> // aggregation pipeline for view } ]
다음 예에서는 test
데이터베이스를 사용하여 myCollection
문서를 firstName
필드별로 정렬하는 myView
뷰를 만듭니다.
use test db.createView( "myView", "myCollection", [ { $sort: { "firstName" : 1 } } ] )
myView
에서 느린 쿼리가 실행된다고 가정합니다. 다음 예시 로그 메시지에는 myView
에 대한 resolvedViews
필드가 포함되어 있습니다.
{ "t": { "$date": "2021-09-30T17:53:54.646+00:00" }, "s": "I", "c": "COMMAND", "id": 51803, "ctx": "conn249", "svc": "R", "msg": "Slow query", "attr": { "type": "command", "ns": "test.myView", "appName": "MongoDB Shell", "command": { "find": "myView", "filter": {}, "lsid": { "id": { "$uuid": "ad176471-60e5-4e82-b977-156a9970d30f" } }, "$db": "test" }, "planSummary":"COLLSCAN", "resolvedViews": [ { "viewNamespace": "test.myView", "dependencyChain": [ "myView", "myCollection" ], "resolvedPipeline": [ { "$sort": { "firstName": 1 } } ] } ], "keysExamined": 0, "docsExamined": 1, "hasSortStage": true, "cursorExhausted": true, "numYields": 0, "nreturned": 1, "planCacheShapeHash": "3344645B", "planCacheKey": "1D3DE690", "queryFramework": "classic" "reslen": 134, "locks": { "ParallelBatchWriterMode": { "acquireCount": { "r": 1 } }, "ReplicationStateTransition": { "acquireCount": { "w": 1 } }, "Global": { "acquireCount": { "r": 4 } }, "Database": { "acquireCount": {"r": 1 } }, "Collection": { "acquireCount": { "r": 1 } }, "Mutex": { "acquireCount": { "r": 4 } } }, "storage": {}, "remote": "127.0.0.1:34868", "protocol": "op_msg", "workingMillis": 0, "durationMillis": 0 } } }
MongoDB 8.0 부터 기존 queryHash
필드 의 이름이 planCacheShapeHash
로 변경되었습니다. 이전 MongoDB 버전을 사용하는 경우 planCacheShapeHash
queryHash
가 표시됩니다.
권한 부여
MongoDB 5.0부터 느린 쿼리에 대한 로그 메시지에는 system.profile.authorization
섹션이 포함됩니다. 이러한 메트릭은 사용자 권한 부여 캐시에 대한 경합으로 인해 요청이 지연되는지 여부를 확인하는 데 도움이 됩니다.
"authorization": { "startedUserCacheAcquisitionAttempts": 1, "completedUserCacheAcquisitionAttempts": 1, "userCacheWaitTimeMicros": 508 },
세션 워크플로 로그 메시지
MongoDB 6.3부터 작업 응답을 보내는 시간이 Slowms 임계값 옵션을 초과하면 로그에 메시지가 추가됩니다.
이 메시지를 세션 워크플로 로그 메시지라고 하며 데이터베이스 세션에서 작업을 수행하는 데 필요한 다양한 시간을 포함합니다.
세션 워크플로 로그 메시지 예시:
{ "t": { "$date": "2022-12-14T17:22:44.233+00:00" }, "s": "I", "c": "EXECUTOR", "id": 6983000, "ctx": "conn1", "svc": "R", "msg": "Slow network response send time", "attr": { "elapsed": { "totalMillis": 109, "activeMillis": 30, "receiveWorkMillis": 2, "processWorkMillis": 10, "sendResponseMillis": 22, "yieldMillis": 15, "finalizeMillis": 30 } } }
시간은 밀리초 단위로 측정됩니다.
sendResponseMillis
이 느려짐 임계값 옵션을 초과하면 세션 워크플로 메시지가 로그에 추가됩니다.
필드 | 설명 |
---|---|
totalMillis | 메시지가 수신될 때까지 대기하는 데 소요된 시간을 포함하여 세션에서 작업을 수행하는 데 소요된 총 시간입니다. |
activeMillis | 메시지 수신과 해당 메시지와 관련된 작업 완료 사이의 시간입니다. 응답을 보내고 정리를 수행하는 데 걸리는 시간도 포함됩니다. |
receivedWorkMillis | 네트워크를 통해 작업 정보를 수신할 시간입니다. |
processWorkMillis | 작업을 처리하고 응답을 생성할 시간입니다. |
sendResponseMillis | 응답을 보낼 시간입니다. |
yieldMillis | 작업자 스레드를 해제한 후 다시 사용되는 스레드 사이의 시간입니다. |
finalize | 세션 워크플로를 종료하고 닫을 시간입니다. |
와이어 로그 메시지에 대한 연결 획득
MongoDB 6.3부터 서버 연결 획득과 네트워크를 통해 서버에 전송할 바이트를 쓰는 사이에 작업이 대기한 시간이 1밀리초를 초과하면 메시지가 로그에 추가됩니다.
기본적으로 메시지는 "I"
정보 수준에서 기록되며 너무 많은 로그 메시지를 방지하기 위해 최대 1초에 한 번 기록됩니다. 모든 로그 메시지를 확보해야 하는 경우 로그 수준을 디버그로 변경하세요.
작업 대기 시간이 1밀리초를 초과하고 최근 1초 이내에 정보 수준에서 메시지가 기록된 경우 다음 메시지는 디버그 수준에서 기록됩니다. 그렇지 않으면 다음 메시지가 정보 수준에서 기록됩니다.
로그 메시지 예시:
{ "t": { "$date":"2023-01-31T15:22:29.473+00:00" }, "s": "I", "c": "NETWORK", "id": 6496702, "ctx": "ReplicaSetMonitor-TaskExecutor", "svc": "R", "msg": "Acquired connection for remote operation and completed writing to wire", "attr": { "durationMicros": 1683 } }
다음 표에서는 durationMicros
필드(attr
안에 있는)에 대해 설명합니다.
필드 | 설명 |
---|---|
durationMicros | 서버 연결을 획득하고 네트워크를 통해 서버에 전송할 바이트를 쓸 때까지 작업이 대기한 시간 (마이크로초) 입니다. |
캐시 새로 고침 시간
MongoDB 6.1부터 느린 쿼리에 대한 로그 메시지에는 다음과 같은 캐시 새로 고침 시간 필드가 포함됩니다.
catalogCacheDatabaseLookupDurationMillis
catalogCacheCollectionLookupDurationMillis
databaseVersionRefreshDurationMillis
shardVersionRefreshMillis
MongoDB 7.0부터 느린 쿼리에 대한 로그 메시지에는 작업이 인덱스 캐시에서 정보를 가져오는 데 소요된 시간을 나타내는 catalogCacheIndexLookupDurationMillis
필드도 포함됩니다. 또한 이 릴리스에서는 shardVersionRefreshMillis
필드의 이름을 placementVersionRefreshMillis
로 변경합니다.
다음 예는 다음을 포함합니다.
catalogCacheDatabaseLookupDurationMillis
catalogCacheCollectionLookupDurationMillis
catalogCacheIndexLookupDurationMillis
{ "t": { "$date": "2023-03-17T09:47:55.929+00:00" }, "s": "I", "c": "COMMAND", "id": 51803, "ctx": "conn14", "svc": "R", "msg": "Slow query", "attr": { "type": "command", "ns": "db.coll", "appName": "MongoDB Shell", "command": { "insert": "coll", "ordered": true, "lsid": { "id": { "$uuid": "5d50b19c-8559-420a-a122-8834e012274a" } }, "$clusterTime": { "clusterTime": { "$timestamp": { "t": 1679046398, "i": 8 } }, "signature": { "hash": { "$binary": { "base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "subType": "0" } }, "keyId": 0 } }, "$db": "db" }, "catalogCacheDatabaseLookupDurationMillis": 19, "catalogCacheCollectionLookupDurationMillis": 68, "catalogCacheIndexLookupDurationMillis": 16026, "nShards": 1, "ninserted": 1, "numYields": 232, "reslen": 96, "readConcern": { "level": "local", "provenance": "implicitDefault", }, "cpuNanos": 29640339, "remote": "127.0.0.1:48510", "protocol": "op_msg", "remoteOpWaitMillis": 4078, "workingMillis": 20334, "durationMillis": 20334 } }
Linux 시스로그 제한 사항
Linux 시스템에서 메시지는 Linux 구성 파일 /etc/systemd/journald.conf
에 정의된 규칙을 따릅니다. 기본적으로 로그 메시지 버스트는 30초 동안 1000개의 메시지로 제한됩니다. 더 많은 메시지를 보려면 /etc/systemd/journald.conf
에서 RateLimitBurst
매개 변수를 늘리세요.
로그 다운로드
MongoDB Atlas를 사용하여 데이터베이스 배포에서 선택한 호스트 이름 또는 프로세스에 대한 로그가 포함된 압축 파일을 다운로드할 수 있습니다. 자세한 내용은 MongoDB 로그 보기 및 다운로드를 참조하세요.