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パーサー最初の{文字からメッセージを2つの列に分割する
    • Key-Value パーサーを使用して最初の列を解析します。コロンは、メッセージ内のこの部分の区切り記号です。
    • jsonパーサーを使用してメッセージの2番目の部分を解析します(一部のメッセージには複数のjson部分があるため、ここに別のcsv + jsonの組み合わせを追加する必要があるかもしれません)。このパーサは、値を解析する名前と値のペアを生成します。テンプレートを使用するか、必要に応じて出力するテンプレート関数です(例:format-welfテンプレート関数を使用)。
  • または今考えてみると、JSON構造(フラット名+値のみ)が必要ない場合は、単に書き換えルールを使用してメッセージから{}文字を削除し、Key-Valueを試してください。パーサー。

  • 上記のオプションが機能しない場合は、Pythonでカスタムパーサーを作成してそこからメッセージを処理できます。

HTH。

成功したらぜひ教えてください。

おすすめ記事