Docs Menu
Docs Home
/
MongoDB 매뉴얼
/

로그 메시지

이 페이지의 내용

  • 개요
  • 구조화된 로깅
  • 로그 메시지 필드 유형
  • 상세도 수준
  • 로그 편집
  • 구조화된 로그 메시지 구문 분석
  • 로그 메시지 예시
  • Linux 시스로그 제한 사항
  • 로그 다운로드

정상 작동의 일환으로, MongoDB는 들어오는 연결, 명령 실행, 발생한 문제 등의 항목을 포함한 이벤트의 실행 로그를 유지합니다. 일반적으로 로그 메시지는 문제를 진단하고, 배포를 모니터링하고, 성능을 조정하는 데 유용합니다.

로그 메시지를 얻으려면 다음 방법 중 하나를 사용할 수 있습니다.

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 형식으로 출력됩니다.

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, the
attributes are escaped
according to the JSON specification.

tags

문자열 배열

로그 문에 적용 가능한 모든 태그를 나타내는 문자열입니다. 예를 들어 ["startupWarnings"]입니다.

truncated

객체

해당하는 경우 로그 메시지 잘라내기에 대한 정보입니다. 로그 항목에 잘린 속성이 하나 이상 포함된 경우에만 attr 포함됩니다.

size

객체

messageattributes 필드는 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"}}}

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 (표준 출력)으로 출력할 수 있습니다.

로그 출력 대상을 구성하려면 구성 파일 또는 명령줄에서 다음 설정 중 하나를 사용합니다.

구성 파일:
명령줄:

파일이나 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가 메시지를 발행할 때는 생성하지 않습니다. 이로 인해 특히 시스템 부하가 심한 경우 로그 항목에 잘못된 타임스탬프가 표시될 수 있습니다.

심각도 필드 유형은 기록된 이벤트와 관련된 심각도 수준을 나타냅니다.

{
"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

디버그, 상세도 수준 > 0

MongoDB 는 특정 디버그 상세 수준을 나타냅니다. 예를 예시, 상세도 수준이 인 2 경우 MongoDB 는 D2 를 표시합니다.

이전 버전에서는 모든 디버그 상세도 수준에 대해 D을 지정하는 MongoDB 로그 메시지가 있었습니다.

다양한 구성 요소의 상세 수준을 지정하여 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 매개 변수를 설정하세요.

REPLELECTION의 상위 구성 요소입니다. 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 매개변수를 설정하세요.

REPLINITSYNC의 상위 구성 요소입니다. systemLog.component.replication.initialSync.verbosity가 설정되지 않은 경우 MongoDB는 INITSYNC 구성요소에 대해 REPL 상세 수준을 사용합니다.

JOURNAL

특히 스토리지 저널링 작업과 관련된 메시지입니다. JOURNAL 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.storage.journal.verbosity 설정을 사용합니다.

STORAGEJOURNAL의 상위 구성 요소입니다. 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 설정을 사용하세요.

STORAGERECOVERY의 상위 구성 요소입니다. systemLog.component.storage.recovery.verbosity가 설정되지 않은 경우 MongoDB는 RECOVERY 구성요소에 대해 STORAGE 상세 수준을 사용합니다.

REPL

초기 동기화, 하트비트, 안정적인 상태 복제, 롤백 등 복제본 세트와 관련된 메시지입니다. [2] REPL 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.replication.verbosity 매개 변수를 설정합니다.

REPLELECTION, INITSYNC, REPL_HBROLLBACK 구성 요소의 상위 구성 요소입니다.

REPL_HB

특히 복제본 세트 하트비트와 관련된 메시지입니다. REPL_HB 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.replication.heartbeats.verbosity 매개 변수를 설정합니다.

REPLREPL_HB의 상위 구성 요소입니다. systemLog.component.replication.heartbeats.verbosity가 설정되지 않은 경우 MongoDB는 REPL_HB 구성요소에 대해 REPL 상세 수준을 사용합니다.

ROLLBACK

롤백 작업과 관련된 메시지입니다. ROLLBACK 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.replication.rollback.verbosity 매개 변수를 설정합니다.

REPLROLLBACK의 상위 구성 요소입니다. systemLog.component.replication.rollback.verbosity가 설정되지 않은 경우 MongoDB는 ROLLBACK 구성요소에 대해 REPL 상세 수준을 사용합니다.

SHARDING

mongos 스타트업과 같은 샤딩 활동과 관련된 메시지입니다. SHARDING 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.sharding.verbosity 설정을 사용합니다.

STORAGE

fsync 명령과 관련된 프로세스 등 저장소 활동과 관련된 메시지입니다. STORAGE 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.storage.verbosity 설정을 사용합니다.

STORAGEJOURNALRECOVERY의 상위 구성 요소입니다.

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.verbositysystemLog.component.<name>.verbosity 설정, logComponentVerbosity 매개변수 또는 db.setLogLevel() 방법을 사용하여 상세도 수준을 구성할 수 있습니다. [2]

모든 구성 요소에 대한 기본 로그 수준을 구성하려면 systemLog.verbosity 설정을 사용합니다. 특정 구성 요소의 수준을 구성하려면 systemLog.component.<name>.verbosity 설정을 사용하세요.

예를 들어, 다음 구성은 systemLog.verbosity1로, systemLog.component.query.verbosity2로, systemLog.component.storage.verbosity2로, systemLog.component.storage.journal.verbosity1로 설정합니다.

systemLog:
verbosity: 1
component:
query:
verbosity: 2
storage:
verbosity: 2
journal:
verbosity: 1

mongod 또는 mongos 인스턴스의 구성 파일 또는 명령줄에서 이러한 값을 설정할 수 있습니다.

구성에 명시적으로 지정되지 않은 모든 구성 요소의 상세도 수준은 -1이며, 이는 상위 구성 요소가 있는 경우 상위 구성 요소의 상세도 수준을 상속하고, 없는 경우 전역 상세도 수준(systemLog.verbosity)을 상속함을 나타냅니다.

logComponentVerbosity 매개 변수를 설정하려면 변경할 상세도 설정이 있는 문서를 전달합니다.

예를 들어 다음은 default verbosity level1 으로,query2 로, 을 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() 메서드를 사용하여 단일 컴포넌트 로그 수준을 업데이트합니다. 구성 요소의 경우 0 ~ 5의 상세 수준을 지정하거나 -1를 지정하여 상위 구성 요소의 상세도를 상속할 수 있습니다. 예를 들어 다음은 systemLog.component.query.verbosity을 상위 상세도로 설정합니다(기본 상세도).

db.setLogLevel(-1, "query")

이 값은 mongosh에서 설정합니다.

[2](1, 2, 3, 4, 5) 이제 복제본 세트의 세컨더리 멤버가 느린 작업 임계값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다.
  • diagnostic log에 세컨더리 멤버에 대해 기록합니다.
  • applied op: <oplog entry> took <num>ms 텍스트와 함께 REPL 구성 요소 아래에 기록됩니다.
  • 로그 수준(시스템 또는 구성 요소 수준)에 의존하지 않습니다.
  • 프로파일링 수준에 의존하지 않습니다.
  • slowOpSampleRate의 영향을 받습니다.
프로파일러는 느린 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 필드가 포함되어 있습니다.

버전 5.0에 추가.

MongoDB 5.0부터는 remoteOpWaitMillis 로그 필드를 사용하여 샤드에서 결과를 얻기 위한 대기 시간(밀리초)을 얻을 수 있습니다.

remoteOpWaitMillis 만 기록됩니다.

병합 작업이나 샤드 문제로 인해 쿼리 속도가 느려지는지 확인하려면 로그의 workingMillisremoteOpWaitMillis 시간 필드를 비교하세요. workingMillis는 쿼리를 완료하는 데 걸린 총 시간입니다. 구체적으로 다음과 같습니다.

  • workingMillisremoteOpWaitMillis보다 약간 길면 샤드 응답을 기다리는 데 대부분의 시간이 소요된 것입니다. 예를 들어 17의 workingMillis, 15의 remoteOpWaitMillis입니다.

  • workingMillisremoteOpWaitMillis보다 상당히 긴 경우 대부분의 시간이 병합을 수행하는 데 소비된 것입니다. 예를 들어 100의 workingMillis, 15의 remoteOpWaitMillis입니다.

Queryable Encryption 사용하는 경우, 암호화된 컬렉션에 대한 CRUD 작업은 느린 쿼리 로그에서 생략됩니다. 자세한 내용은 Queryable Encryption편집을 참조하십시오.

MongoDB Enterprise에서만 사용할 수 있습니다.

mongod 또는 mongosredactClientLogData와 함께 실행되는 경우, 주어진 로그 이벤트를 로깅하기 전에 모든 메시지를 삭제하여 이벤트와 관련된 메타데이터, 소스 파일 또는 줄 번호만 남깁니다. 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,
...
}
...
}
}

mongodredactClientLogData와 함께 실행되어 동일한 삽입 작업을 수행하면 다음과 같은 로그 이벤트가 생성됩니다.

{
"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( 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는 각각 2294322944 입니다. 그런 다음 다음 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 구성 파일 /etc/systemd/journald.conf 에 정의된 규칙을 따릅니다. 기본적으로 로그 메시지 버스트는 30초 동안 1000개의 메시지로 제한됩니다. 더 많은 메시지를 보려면 /etc/systemd/journald.conf에서 RateLimitBurst 매개 변수를 늘리세요.

MongoDB Atlas를 사용하여 데이터베이스 배포에서 선택한 호스트 이름 또는 프로세스에 대한 로그가 포함된 압축 파일을 다운로드할 수 있습니다. 자세한 내용은 MongoDB 로그 보기 및 다운로드를 참조하세요.

돌아가기

용어집