проанализировать журналы Mongodb с syslog-ng

Я получаю много журналов Mongodb с моим Syslog-ng. ниже приведен пример анализа журналов и их сохранение следующим образом:

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 события должна быть разделена запятой. Я много искал об этой проблеме. Мне нужно, чтобы в syslog-ng появилась возможность анализировать журналы JSON (Smaples) и хранить в CSV ?

Примечание. Формат журнала mongodb выглядит следующим образом: https://github.com/rueckstiess/mongodb-log-spec

это сложно. Проблема imho заключается в том, что существуют объекты JSON, смешанные с полями обычного текста. Я думаю, у вас есть следующие параметры (обратите внимание, что вам понадобится последняя версия syslog-ng для использования парсеров json и kv, я бы пошел на версию 3.8):

  • Если вы можете, настройте mongodb для входа в чистый json и проанализируйте его с помощью json-parser syslog-ng. (Не знаю, сможет ли это сделать mongodb).

  • Вы можете создать базу данных шаблонов для покрытия отдельных сообщений, но это может занять много времени

  • Но наиболее вероятным вариантом было бы использовать комбинацию syslog-ng parsers . А именно, попробуйте следующее:

    • используйте csv-parser, чтобы разделить сообщение на два столбца на первый символ {
    • проанализируйте первый столбец с помощью анализатора ключевых значений (двоеточие является разделителем в этой части сообщения)
    • используйте json-parser для синтаксического анализа второй части сообщения (так как в некоторых сообщениях есть несколько частей json, вам может потребоваться добавить еще одну комбинацию csv + json). Эти синтаксические анализаторы создадут пары имени-значения проанализированных значений, и вы можете используйте шаблон или функцию шаблона для вывода их по мере необходимости (например, используя функцию шаблона формата welf).
  • Или теперь, когда я думаю об этом, если вам не нужна структура JSON (только плоские имена + значения), тогда вы можете попытаться просто использовать правило перезаписи для удаления {} символов из сообщений и использовать ключ- синтаксический анализатор.

  • Если вышеуказанный параметр не работает, вы можете написать собственный парсер в python и обработать там сообщения.

НТН.

Пожалуйста, дайте мне знать, если вам удастся.