☰

syslog-ng를 사용하여 Mongodb 로그 구문 분석

tag-icon • tag-icon json syslog-ng mongodb
syslog-ng를 사용하여 Mongodb 로그 구문 분석

Syslog-ng를 사용하여 많은 Mongodb 로그를 받습니다. 다음은 구문 분석되어 저장된 로그의 예입니다.

2016-10-18 19:01:08 f:local1.p:info h:10.133.126.81 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:02.439+0330 I COMMAND  [conn71796] command CLM.TroubleTicket command: find { find: "TroubleTicket", filter: { $and: [ { troubleTicket.serviceCode: "8118415922" } ] }, projection: { troubleTicket.referenceNumber: 1, troubleTicket.ticketGenerationDate: 1, troubleTicket.ticketCreatedDate: 1, troubleTicket.currentStatus: 1, troubleTicket.currentStatusReason: 1, troubleTicket.thirdPartyIncidentNumber: 1, troubleTicket.troubleTicketCatId: 1, troubleTicket.troubleTicketSubCatId: 1, troubleTicket.troubleTicketSubSubCatId: 1, troubleTicket.serviceCode: 1, troubleTicket.lastUpdateDate: 1, $sortKey: { $meta: "sortKey" } }, sort: { troubleTicket.ticketCreatedDate: -1 }, ntoreturn: 5, shardVersion: [ Timestamp 232000|1, ObjectId('578fb3a6e0f9dacf6705e34c') ] } planSummary: IXSCAN { troubleTicket.serviceCode: 1.0 }, IXSCAN { troubleTicket.serviceCode: 1.0 } cursorid:85032809863 keysExamined:97798 docsExamined:97798 hasSortStage:1 keyUpdates:0 writeConflicts:0 numYields:764 nreturned:5 reslen:2354 locks:{ Global: { acquireCount: { r: 1530 } }, Database: { acquireCount: { r: 765 } }, Collection: { acquireCount: { r: 765 } } } protocol:op_command 572ms
2016-10-18 19:01:17 f:local1.p:info h:10.133.126.80 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:10.226+0330 I SHARDING [conn6447] request split points lookup for chunk CLM.ActionLevelDetails { : MinKey } -->> { : MaxKey }
2016-10-18 19:01:17 f:local1.p:info h:10.133.126.80 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:10.229+0330 W SHARDING [conn6447] possible low cardinality key detected in CLM.ActionLevelDetails - key is { actionLevelDetails.activityType: "CNFRMREG" }
2016-10-18 19:01:17 f:local1.p:info h:10.133.126.80 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:10.229+0330 W SHARDING [conn6447] possible low cardinality key detected in CLM.ActionLevelDetails - key is { actionLevelDetails.activityType: "DOCSUPLOAD" }
2016-10-18 19:01:17 f:local1.p:info h:10.133.126.80 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:10.234+0330 I SHARDING [conn6447] request split points lookup for chunk CLM.ActionLevelDetails { : MinKey } -->> { : MaxKey }
2016-10-18 19:01:17 f:local1.p:info h:10.133.126.80 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:10.237+0330 W SHARDING [conn6447] possible low cardinality key detected in CLM.ActionLevelDetails - key is { actionLevelDetails.activityType: "CNFRMREG" }
2016-10-18 19:01:17 f:local1.p:info h:10.133.126.80 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:10.237+0330 W SHARDING [conn6447] possible low cardinality key detected in CLM.ActionLevelDetails - key is { actionLevelDetails.activityType: "DOCSUPLOAD" }
2016-10-18 19:01:17 f:local1.p:info h:10.133.126.80 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:10.350+0330 I SHARDING [conn6447] request split points lookup for chunk CLM.ActionLevelDetails { : MinKey } -->> { : MaxKey }
2016-10-18 19:01:17 f:local1.p:info h:10.133.126.80 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:10.353+0330 W SHARDING [conn6447] possible low cardinality key detected in CLM.ActionLevelDetails - key is { actionLevelDetails.activityType: "CNFRMREG" }
2016-10-18 19:01:18 f:local1.p:info h:10.133.126.81 prog:sharmongo-log m:sharmongo-log 2016-10-18T19:01:16.762+0330 I ACCESS   [conn6012] Successfully authenticated as principal dba_admin on admin

Mongodb 로그 메시지에는 로그에 표시된 대로 JSON 형식이 포함되어 있습니다. 이러한 로그에 대한 syslog-ng 구성은 다음과 같습니다.

source s_all {
                udp(ip("0.0.0.0") port(514));
                tcp(ip("0.0.0.0") port(514) keep-alive(no) max-connections(1000));
};


destination d_clm_mongodb {
   file("/storage/sensage/incoming/mtn/syslog-ng/clm_mongodb/clm_mongodb.log"
   template("$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC f:$FACILITY.p:$PRIORITY h:$HOST_FROM prog:$PROGRAM m:$MSG\n")
   template_escape(no) );
};

filter f_clm_mongodb          { program("sharmongo-log"); };

log { source(s_all); filter(f_clm_mongodb);       destination(d_clm_mongodb);       flags(final); };

이러한 로그를 형식(쉼표로 구분)으로 구문 분석해야 합니다. CSV즉, 이벤트 JSON 부분을 쉼표로 구분해야 합니다. 이 문제에 대해 많이 검색했습니다. 이제 JSON 로그(Smaples)를 구문 분석하고 이를 형식으로 저장하려면 syslog-ng에 함수가 필요합니다 CSV.

참고: mongodb 로그 형식은 다음과 같습니다. https://github.com/rueckstiess/mongodb-log-spec

답변1

이것은 어려운 질문입니다. 문제는 JSON 개체가 일반 텍스트 필드와 혼합되어 있다는 것입니다. 다음과 같은 옵션이 있다고 생각합니다(json 및 kv 파서를 사용하려면 최신 syslog-ng 버전이 필요합니다. 저는 버전 3.8을 선택합니다).

  • 가능하다면 순수 json에 로그인하도록 mongodb를 구성하고 구문 분석을 위해 syslog-ng의 json-parser를 사용하십시오. (mongodb가 이것을 할 수 있는지는 모르겠습니다.)

  • 당신은 할 수스키마 데이터베이스 만들기개별 메시지를 다루되 시간이 많이 걸릴 수 있음

  • 하지만 가장 가능성이 높은 옵션은syslog-ng 파서 조합 사용. 즉, 다음을 시도해 보세요.

    • 사용하다CSV 파서처음 { 문자에서 메시지를 두 개의 열로 분할
    • 키-값 구문 분석기를 사용하여 첫 번째 열을 구문 분석합니다. 콜론은 메시지에서 이 부분의 구분 기호입니다.
    • json 파서를 사용하여 메시지의 두 번째 부분을 구문 분석합니다(일부 메시지에는 여러 json 부분이 있으므로 여기에 다른 csv+json 조합을 추가해야 할 수도 있습니다). 이 파서는 값을 구문 분석하는 이름-값 쌍을 생성합니다. 템플릿을 사용하거나 필요에 따라 출력하는 템플릿 함수입니다(예: format-welf 템플릿 함수 사용).

  • 아니면 이제 생각해 보니 JSON 구조(플랫 이름 + 값만)가 필요하지 않다면 간단히 재작성 규칙을 사용하여 메시지에서 {} 문자를 제거하고 키-값을 사용해 볼 수 있습니다. 파서.

  • 위의 옵션이 작동하지 않으면 Python으로 사용자 정의 파서를 작성하고 거기에서 메시지를 처리할 수 있습니다.

HTH.

성공하시면 꼭 알려주세요.

관련 정보