使用 解析日志是一种从大量日志数据中提取基本信息的宝贵技术。通过采用这种方法，可以有效地识别模式、错误和其他关键见解，最终简化日志分析并提高系统性能。 正则表达式 先决条件 BindPlane OP 和 BindPlane 代理（自定义 OpenTelemetry 收集器） 需要自定义解析的复杂日志文件 正则表达式知识 匹配所有可能变化的日志样本选择。 （可选）regex101.com等不错的正则测试工具 以下是博客中示例的 regex101 链接： https://regex101.com/r/6hhy6K/4 复杂的日志数据样本 在这篇文章中，我们将检查类似于下面提供的示例的日志条目。通过使用脚本将这些条目写入具有当前时间戳的文件，我们可以有效地处理实时数据。 May 01 14:31:11 loggen-app10 test-system[712]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[result=Service Access Granted,service=https://portal.fakeuni.edu/uPortal/Login?...,requiredAttributes={}]|SERVICE_ACCESS_ENFORCEMENT_TRIGGERED|camillec1997|172.13.49.165|172.16.156.55 May 01 14:31:11 loggen-app10 test-system[712]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[result=Service Access Granted,service=https://portal.fakeuni.edu/uPortal/Login?...,requiredAttributes={}]|SERVICE_ACCESS_ENFORCEMENT_TRIGGERED|camillec1997|172.13.49.165|172.16.156.55 May 01 14:31:11 loggen-app10 test-system[712]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[event=success,timestamp=May 01 14:31:11 UTC 2023,source=RankedMultifactorAuthenticationProviderWebflowEventResolver]|AUTHENTICATION_EVENT_TRIGGERED|audit:unknown|172.25.178.6|172.16.156.55 May 01 14:31:11 loggen-app08 test-system[780]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|Supplied credentials: [UsernamePasswordCredential(username=dawsonb, source=null, customFields={})]|AUTHENTICATION_SUCCESS|dawsonb|172.12.154.117|172.16.156.53 May 01 14:31:11 loggen-app10 test-system[712]: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[event=success,timestamp=May 01 14:31:11 UTC 2023,source=RankedMultifactorAuthenticationProviderWebflowEventResolver]|AUTHENTICATION_EVENT_TRIGGERED|audit:unknown|172.25.178.6|172.16.156.55 剖析数据 我们现在可以获取上面的第一个日志条目，并开始将其分解为我们希望解析的部分。 首先，我们会注意到我们有两个时间戳： **May 01 14:31:11** loggen-app10 test-system[712]: **Mon May 01 14:31:11 UTC 2023**|TEST_PROC|[result=Service Access Granted,service=https://portal.fakeuni.edu/uPortal/Login?...,requiredAttributes={}]|SERVICE_ACCESS_ENFORCEMENT_TRIGGERED|camillec1997|172.13.49.165|172.16.156.55 第二个时间戳是我们将保留成为官方时间戳的那个，因为它包含更多信息（时区和年份很有用，而星期几不是真的），我们可以使用这些信息来实现最高精度。 打破这个，我们将编写一个非捕获模式来匹配第一个时间戳。 到行首。接下来是“ ”，它捕获了 3 个字母的月份缩写。月份之后是“ ”，就是抓取一个空格； 2 位数字，该月的 0 填充天数；和另一个空间。最后，我们有“ ”——代表 2 位数字小时、2 位数字分钟、2 位数字秒和 1 个或多个空格。 ^\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\s+The caret “^” \w{3} \s\d{2}\s \d{2}:\d{2}:\d{2}\s+ 对于第二个时间戳，我们需要一个命名的捕获组。这将成为解析字段的 JSON blob 中的命名字段。 (?P<timestamp>\w{3}\s\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\s\w{3}\s\d{4}) 我们将这个捕获组命名为“timestamp”。它包含与其他时间戳相同的基本正则表达式，在开始处添加“ ”以捕获星期几的缩写，以及“ ”替换末尾的“ ”以捕获 3 个字符的时区和 4 位数字的年份。 \w{3}\s \s\w{3}\s\d{4} \s+ 进一步研究日志消息，我们将要解析主机名和系统： May 01 14:31:11 **loggen-app10 test-system[712]**: Mon May 01 14:31:11 UTC 2023|TEST_PROC|[result=Service Access Granted,service=https://portal.fakeuni.edu/uPortal/Login?...,requiredAttributes={}]|SERVICE_ACCESS_ENFORCEMENT_TRIGGERED|camillec1997|172.13.49.165|172.16.156.55 在此消息中，我们的主机名是 ，我们的系统是 。当我收到这些日志时，我没有被告知 [712] 是什么。我假设它是PID（进程ID），但我选择暂时不单独解析它。解析这些字段相当简单，我们最终得到：“ ”。我们有一对命名的捕获组、主机名和系统。 **loggen-app10** **test-system[712]** (?P<hostname>[^\s]+)\s+(?P<system>.*?):\s+ 主机名的模式是“ ”，表示捕获任何非空格字符并尽可能多地捕获它们（贪婪）。接下来是“ ”，它至少捕获一个，但尽可能多（再次贪婪）空间。 [^\s]+ \s+ 系统的捕获组甚至更容易，因为在空格之后我们捕获冒号字符之前的所有内容。为此，我们使用“ ”。该模式的意思是，捕获任何字符 0 次或多次，但不要贪心。 .*? 在那之后，我们有冒号字符和另外 1 个或多个贪婪的空格。这些没有被捕获，但需要在这部分和我们上面写的时间戳部分之间填充。 这导致以下起始模式： ^\w{3}\s*\d{2}\s*\d{2}:\d{2}:\d{2}\s+(?P<hostname>[^\s]+)\s+(?P<system>.*?):\s+(?P<timestamp>\w{3}\s\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\s\w{3}\s\d{4}) 我不会经历整个模式创建过程，但我会像上面那样继续将其分块。 由此产生的最终模式是： ^\w{3}\s*\d{2}\s*\d{2}:\d{2}:\d{2}\s+(?P<hostname>[^\s]+)\s+(?P<system>.*?):\s+(?P<timestamp>\w{3}\s\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\s\w{3}\s\d{4})\|(?P<app_name>\w*)\|((?P<message_type>.*?):\s+)?\[?(?P<message>.*)\]?\|(?P<event_message>.*?)\|(?P<username>.*?)\|(?P<external_ip>[\d\.:]*)\|(?P<internal_ip>[\d\.:]*) 这个最终模式包括以下命名的捕获组，它们成为我们解析数据的 JSON blob 中的字段： 主机名 系统 时间戳 应用名称 消息类型 信息 事件消息 用户名 外部IP 内部IP 实施正则表达式 在 BindPlane 中，我创建了一个文件源。这会查看我在 /root/complex.log 中生成的日志文件。我在解析格式下选择了正则表达式。在正则表达式模式下，我输入了上面的最终模式。我选中了 Parse Timestamp 框，为格式选择了 Manual，并为我的时间戳模式输入了时间解析代码。 完成后，它看起来像这样： 发送和验证数据 要完成测试，我需要创建一个目的地并检查那里的数据。对于我的用例，我选择了一个 Google Cloud Logging 目的地。 管道配置完成后，我将其附加到代理。运行片刻后，我单击代理页面上的“查看最近的遥测按钮” 遥测视图向我显示了以下已解析的日志： 最后，我还在 Cloud Logging 控制台上进行了检查： Google 这将显示相同的日志条目，并且它具有来自最近遥测视图的我们身体的 JSON 映射对象的 JSON 有效负载。 下一步 对于接下来的步骤，我想看看解析该消息值。它通常是一个键/值集；正如上面的屏幕截图和示例所示。我可以将数据向前传递给处理器，处理器将这些键/值条目解析为另一层 JSON。在上面的示例中， 将被解析回自身，您可以拥有如下字段： body.message body.message.result=Service Access Granted body.message.service=https://innosoftfusiongo.com/sso/logi… body.message.principal=SimplePrincipal(id=dawsonb, attributes={mail=[dawson.branden@fakeuni.edu], eduPersonAffiliation=[Staff], ou=[Recreation/Student Rec Center], givenName=[Dawson], cn=[Dawson Branden], title=[Asst. Director], employeeNumber=[5000000], o=[Vice ChancellorStudent Affairs], fakeuniOrg=[Vice ChancellorStudent Affairs], casMFARequired=[YES], uid=[dawsonb], eduPersonPrimaryAffiliation=[Staff], fakeuniCid=[5000000], fakeuniSeparationDate=[99991231000000Z], UDC_IDENTIFIER=[dawsonb], sn=[Branden], organizationalStatus=[Staff]}) body.message.requiredAttributes=”” 即使这样也可以通过将 body.message.principle 放入键/值解析器来进一步解析。 现在，肯定有人会疑惑，“为什么不直接使用正则表达式解析 body.message 子字段呢？”答案是：太不一致了。当我们已经具备解析键/值对的能力时，正则表达式将变得难以置信且不合理地复杂。 结论 在日志文件中可以找到多种形式的数据。这些数据通常需要进行解析，以使其更易于人类阅读，并更易于链中后期的自动化和工具采取行动。 虽然我使用的示例是在一个简单的文件日志上执行的，但此处的技术可用于任何日志流。除了正则表达式解析，BindPlane 还支持 、 、键/值对和字符分隔值。通过使用处理器，这些解析器可以链接在一起以解析嵌入式数据，并将其全部处理成可用格式。 JSON XML 也发布 在这里。
