parsing - 编写用于 syslog-ng 的自定义模板/解析器/过滤器

Question

我的应用程序生成日志并将它们发送到 syslog-ng。
我想编写一个自定义模板/解析器/过滤器以在 syslog-ng 中使用，以正确地将字段存储在 SQLite 数据库(MyDatabase)的表中。

这是我日志的传说:

unique-record-id usename date Quantity BOQ possible,item,profiles Count Vendor applicable,vendor,categories known,request,types vendor_code credit

所有这 12 个字段都是制表符分隔的，解析器必须将它们存储到 MyDatabase 中表 MyTable1 的 12 列中。
部分字段: 然而，第 6、第 9 和第 10 也包含“子字段”作为逗号分隔值 .
每个子字段中的值的数量是可变的，并且可以在日志的每一行中更改。

I need these fields to be stored in respective separate tables MyItem_type, MyVendor_groups, MyReqs

这些“辅助”表有 3 列，记录 Unique-Record-ID 和 Quantity 在日志中的每次出现
所以 MyItem_type 表中的模式如下所示:

Unique-Record-ID | item_profile | Quantity

类似地，MyVendor_groups 的架构如下所示:

Unique-Record-ID | vendor_category | Quantity

MyReqs 的架构如下所示:

Unique-Record-ID | req_type | Quantity

考虑日志中的这些示例行:

唯一记录 ID 使用名称 日期 数量 BOQ 可能，项目，配置文件计数供应商适用，供应商，已知类别，请求，类型供应商代码信用

234.44.tfhj Sam 22-03-2016  22  prod1   cat1,cat22,cat36,cat44  66  ven1    t1,t33,t43,t49  req1,req2,req3,req4 blue    64.22

234.45.tfhj Alex    23-03-2016  100 prod2   cat10,cat36,cat42   104 ven1    t22,t45 req1,req2,req33,req5    red 66

234.44.tfhj Vikas   24-03-2016  88  prod1   cat101,cat316,cat43 22  ven2    t22,t43 req1,req23,req3,req6    red 77.12

234.47.tfhj Jane    25-03-2016  22  prod7   cat10,cat36,cat44   43  ven3    t77 req1,req24,req3,req7    green   45.89

234.48.tfhj John    26-03-2016  97  serv3   cat101,cat36,cat45  69  ven5    t1  req11,req2,req3,req8    orange  33.04

234.49.tfhj Ruby    27-03-2016  85  prod58  cat10,cat38,cat46   88  ven9    t33,t55,t99 req1,req24,req3,req9    white   46.04

234.50.tfhj Ahmed   28-03-2016  44  serv7   cat110,cat36,cat47  34  ven11   t22,t43,t77 req1,req20,req3,req10   red 43

我的解析器应该将上述日志存储到 MyDatabase.Mytable1 中:

unique-record-id    |   usename |   date    |   Quantity    |   BOQ |   item_profile    |   Count   |   Vendor  |   vendor_category |   req_type    |   vendor_code |   credit
234.44.tfhj |   Sam |   22-03-2016  |   22  |   prod1   |   cat1,cat22,cat36,cat44  |   66  |   ven1    |   t1,t33,t43,t49  |   req1,req2,req3,req4 |   blue    |   64.22
234.45.tfhj |   Alex    |   23-03-2016  |   100 |   prod2   |   cat10,cat36,cat42   |   104 |   ven1    |   t22,t45 |   req1,req2,req33,req5    |   red |   66
234.44.tfhj |   Vikas   |   24-03-2016  |   88  |   prod1   |   cat101,cat316,cat43 |   22  |   ven2    |   t22,t43 |   req1,req23,req3,req6    |   red |   77.12
234.47.tfhj |   Jane    |   25-03-2016  |   22  |   prod7   |   cat10,cat36,cat44   |   43  |   ven3    |   t77 |   req1,req24,req3,req7    |   green   |   45.89
234.48.tfhj |   John    |   26-03-2016  |   97  |   serv3   |   cat101,cat36,cat45  |   69  |   ven5    |   t1  |   req11,req2,req3,req8    |   orange  |   33.04
234.49.tfhj |   Ruby    |   27-03-2016  |   85  |   prod58  |   cat10,cat38,cat46   |   88  |   ven9    |   t33,t55,t99 |   req1,req24,req3,req9    |   white   |   46.04
234.50.tfhj |   Ahmed   |   28-03-2016  |   44  |   serv7   |   cat110,cat36,cat47  |   34  |   ven11   |   t22,t43,t77 |   req1,req20,req3,req10   |   red |   43

并且还解析“可能，项目，配置文件”以记录到 MyDatabase.MyItem_type 为:

Unique-Record-ID | item_profile | Quantity
234.44.tfhj |   cat1    |   22
234.44.tfhj |   cat22   |   22
234.44.tfhj |   cat36   |   22
234.44.tfhj |   cat44   |   22
234.45.tfhj |   cat10   |   100
234.45.tfhj |   cat36   |   100
234.45.tfhj |   cat42   |   100
234.44.tfhj |   cat101  |   88
234.44.tfhj |   cat316  |   88
234.44.tfhj |   cat43   |   88
234.47.tfhj |   cat10   |   22
234.47.tfhj |   cat36   |   22
234.47.tfhj |   cat44   |   22
234.48.tfhj |   cat101  |   97
234.48.tfhj |   cat36   |   97
234.48.tfhj |   cat45   |   97
234.48.tfhj |   cat101  |   97
234.48.tfhj |   cat36   |   97
234.48.tfhj |   cat45   |   97
234.49.tfhj |   cat10   |   85
234.49.tfhj |   cat38   |   85
234.49.tfhj |   cat46   |   85
234.50.tfhj |   cat110  |   44
234.50.tfhj |   cat36   |   44
234.50.tfhj |   cat47   |   44

We also need to similarly parse "applicable,vendor,categories" and store them into MyDatabase.MyVendor_groups. And parse "known,request,types" for storage into MyDatabase.MyReqs The first column for MyDatabase.MyItem_type, MyDatabase.MyVendor_groups and MyDatabase.MyReqs will always be the Unique-Record-ID that was witnessed in the log.

因此，是的，此列不包含这三个表中的其他列一样的唯一数据。
第三列将始终是日志中见证的数量。

我知道一点 PCRE，但正是在 syslog-ng 中使用嵌套解析器让我完全困惑。

Syslog-ng 的文档表明这是可能的，但根本没有找到一个好的例子。如果这里有任何类型的 hack 有一些引用或示例可以分享，那将非常有用。

提前致谢。

Answer 1

我认为所有这些都可以使用 csv-parser 完成几次。
首先，使用带有制表符分隔符(“\t”)的 csv 解析器将初始字段拆分为命名列。对整个消息使用此解析器。
然后，您必须在需要进一步解析的列上使用 csv-parser 的其他实例来解析具有子字段的字段。
您可以在 https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/csv-parser.html 找到一些示例。和 https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/reference-parsers-csv.html

(如果您将制表符和逗号都指定为分隔符，则可以使用单个解析器完成它，但它可能不适用于具有可变数量字段的字段。)。