我今年夏天在一家小公司实习,并负责解析来自kinesis流的日志文件.这具有极高的吞吐量,因此我一直在学习如何进行“实时”解析,因为缺少更好的术语,以避免内存膨胀并在lambda中产生额外成本.

我进入该项目期待一些乏味但可管理的东西,但我遇到了几个问题：

>在从多个来源汇总到我收到它们的日志之间的某个时刻,分隔符“在翻译中丢失”.我没有什么可以轻易做到的,如标签,4个空格,2个空格,3个空格,冒号,逗号等,因为它往往会在非预期点破坏日志
>显然有几千种日志需要处理和分析.其中许多来自“相同”的来源(例如MSWinEventLog),但它们本身仍然是独一无二的. Windows日志约占随机样本的约85％.提供给我的日志类型的电子表格记录了许多类型日志的“0”实例,但我认为它们的存在意味着它们已经在该收集期之外的某个时刻被观察到.

每当我想我在特定类型的日志中找到一个模式时,一个来自不同的源并杀死它.大多数部分的字段名称不包括在Windows事件编号特定数据之外,其中附加了冒号

heading1：field1：包含spaces2的data1字段：data2 field3：包含空格的data3 also_part_of_data3values field4：field5_after4_with_no_value：data5

现在我的方法有点天真,只解决了Windows事件.它采用了正则表达式和“智能对”解析的组合.正则表达式得到一些我可以依赖的字段,并在配对时识别“关键元素”.配对是由冒号分隔的部分(或者在powershell日志的情况下为’=’).我努力将所有字段和值分成一个列表.然后,对于每个元素,我检查它是否是一个键.如果是,我将它与下一个应该是值的元素配对.如果下一个元素也是一个键,则最后一个元素是标题或没有值的字段,并被丢弃.在配对键和值之后,如果下一个元素与’something：’模式不匹配,那么我认为它是具有多个值的键.一旦遇到另一个关键元素,关键字：直到该点的值被添加到字典中.所以,从上面的例子中我(希望)最终得到：

"field1": "data1",
"field with spaces 2": "data2",
"field3": ["data3 with spaces", "also_part_of_data3values"],
"field5": "data5"

这种方法适用于Windows日志.我尝试修剪不必要的信息(例如,许多日志包括Windows中关于事件是什么的描述文本,可以是10个句子).

我担心的是,由于日志量非常大,因此很难考虑可能进入解析器的每个可能的日志,尤其是即使在一种日志类型中它们的格式也不一样(我注意到的日期/时间)在顺序和分隔符方面极不一致).编写几千个正则表达式对于一个人(我)来说似乎并不实际.

所以我想我的问题是：对于那些处理过类似杂乱情况的人来说,我该如何解决这个问题并修复我现在拥有的管道缠绕的意大利面呢？

最佳答案 假设

>高频输入
>行分隔文本
>未知语义的日志模式

>由一些人主导
>稀有“其他”的长尾

我过去在基于python生成器的阶段处理中做了很好的扩展.不过,它不会自动进行机器学习.

因此,如果输入是如此描述的高度未指定,但具有已知部分的主要核心(一个定义物种的85％,如OP状态),则有助于将“检测”与解析明确分开.

任何不适合越来越多的包装良好的规则的东西都放在“terra incognita”桶中以便手动检查(可能用阈值检测器的提示标记).

大多数将被移交给匹配的解析器并完全处理.

最好的是,有一些利益相关者,给予津贴a)最后跳过或b)简单地将未知数记录到检查我,如日志,存档或采样或其他什么.

如果你是独立的,似乎没有100％工作的解决方案(这在我的理解中意味着：“全部解析”),因为更多的自动化可能导致更多错误的检测格式 – 错误将降低您的结果质量.在你“离开建筑物”之后可能会发生罕见的模式实例,但我不打赌,并且个人不会建议这种态度;-)