最直观的解析几千种不同日志类型的方法(使用Python)?

时间:2016-07-06 04:49:14

标签: python regex parsing aws-lambda bigdata

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

我进入这个项目期待一些单调乏味但又易于管理的项目,但我遇到了一些问题:

  1. 分隔符在翻译中丢失了#39;在从多个来源汇总到我收到它们的日志之间的某个时刻。我没有什么可以轻易做到的,比如突破标签,4个空格,2个空格,3个空格,冒号,逗号等等,因为它会使日志在非预期的位置断裂

  2. 显然有几千种日志需要处理和分析。其中许多来自同一个" source(例如MSWinEventLog),但它们本身仍然是唯一的。 Windows日志约占随机样本的约85%。提供给我的日志类型电子表格记录了#34; 0"许多类型的日志的实例,但我认为它们的存在意味着它们已经在收集期之外的某个时间点被观察到。

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

    heading1: field1: data1 field with spaces2: data2 field3: data3 with spaces also_part_of_data3values field4: field5_after4_with_no_value: data5

    现在我的方法有些幼稚,只能解决Windows事件。它结合了正则表达式和智能对#34;解析。正则表达式得到一些我可以依赖的领域,并确定"关键元素"配对时配对是由冒号分隔的部分(或者在powershell日志的情况下' =')。我努力将所有字段和值分成一个列表。然后,对于每个元素,我检查它是否是一个键。如果是,我将它与应该的下一个元素配对。如果下一个元素也是一个键,则最后一个元素是标题或没有值的字段,并被丢弃。配对密钥和值后,如果下一个元素与以下内容不匹配:'模式,然后我认为它是一个具有多个值的键。一旦遇到另一个关键元素,关键字:直到该点的值被添加到字典中。因此,从上面的例子中我(希望)最终得到:

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

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

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

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

2 个答案:

答案 0 :(得分:1)

假设

  1. 高频输入
  2. 行分隔文字
  3. 未知语义的日志模式
    1. 由一些
    2. 主导
    3. 罕见的“其他人”的长尾
  4. 我过去在基于python生成器的分阶段处理中做了很好的扩展。不过,它不会自动进行机器学习。

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

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

    大部分将被移交给匹配的解析器并完全处理。

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

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

答案 1 :(得分:1)

我只能通过以下方式给你答案:
可以执行所有操作的多工具不是解决方案,几乎不可能编写可以解析任何日志的工具,并为您提供任意类型日志的正确信息。 您必须维护/支持您所做的事情。

做计划:

计划A:

  1. 尝试了解为什么要求您解析的原因和内容 日志:转到您的同事/经理,设置会议并弄明白 你需要做的真实事情。并且可能减少用于解析的日志量。
  2. 准备一组日志 你已经拥有并尝试找出这些日志中的哪一个 危急。从为它们编写解析器开始。
  3. 准备基础class以解析仅包含基本功能的日志(读取,解析,保存等)
  4. 使用自己的模式和方法准备类,以便解析已知的关键日志类型。继承自#3
  5. unmatched logs准备一个类,该类将保存未解析以供将来分析的所有新日志。继承自#3
  6. unmatched logs进行分析并重复#4
  7. 如果您说extremely high throughput使用cache - 您有很多类似日志的可能性很小(例如,如果您的应用无法建立连接,您可能拥有完全相同日志的GB) - 尝试将uniq部分日志保存在缓存中,并与之进行比较。

    计划B:我认为对于实习生来说,夏季可能是一个非常好的计划:
    更深入Genetic programming - 它可能有助于为新日志生成新模式(如果你愿意,请分享你的git hub链接)