我需要加入2个日志才能获得我需要的所有信息。 summary.log包含我需要的大部分字段（其中包括很多字段）以及此事件是否适用于我的指示。 location.log只需要一个我需要的字段以及一个唯一的标识符，以便将日志绑定在一起。
首先我想使用连接命令，顾名思义，但第一次搜索的结果字段不能用于子搜索（连接使用）。然后我发现了map命令，它允许完全相同，但是地图有一个副作用，即删除刚才没有来自地图的所有字段。后来我想也许我可以使用collect或outputlookup临时存储字段。但我需要多个人才能在没有竞争条件的情况下运行此查询，因此查找是不可能的。 collect testmode = true可能有效（或者可能没有），但只能使用现有的索引，而且我不会创建空索引并确保它保持为空。经过一些在线搜索后，我找不到任何其他没有使用子搜索的命令（因此set与join有相同的问题）。所以我只想出3个选项：
选项1：
source=summary.log | xmlkv | search transactionFailed=true
| join transactionId max=0 [search
source=summary.log | xmlkv | search transactionFailed=true
| map search="search source=location.log \"[$transactionId$]\" | eval transactionId=\"$transactionId$\""
| rex "(?<locationId>\w+)$" | fields transactionId locationId]
| table *
选项2：
source=summary.log | xmlkv | search transactionFailed=true
| map search="search source=location.log \"[$transactionId$]\" | eval transactionId=\"$transactionId$\"
| eval every=\"$every$\" | eval single=\"$single$\" | eval field=\"$field$\" | eval I=\"$I$\" | eval need=\"$need$\""
| rex "(?<locationId>\w+)$" | table *
选项3：
source=location.log | rex "\[(?<transactionId>.+?)\]" | rex "(?<locationId>\w+)$"
| map search="source=summary.log \"$transactionId$\" | eval locationId=\"$locationId$\""
maxsearches=2147483647
| xmlkv | search transactionFailed=true | table *
选项1完全相同的搜索两次（这就是我考虑使用collect或outputlookup存储其结果的原因），但问题是这只是一个简化的模拟查询，实际查询很复杂并重复大事是非DRY，可能对性能不利。
选项2需要一个有效的每个字段的列表，但是很麻烦（我认为它有10个字段）。它也不灵活，但这并不是一个要求，因为这些领域不会很快改变。
选项3永远不会像以往那样完成。绝大多数事务都不是失败，map命令非常慢。不，我不需要超过几千，上面的最大搜索只是为了突出语法上最干净的方法的问题。
所有这些都很糟糕。选项3不是一种选择。选项1缓慢而混乱。选项2很杂乱，但在其他方面很好，使其成为最佳选择。我花了很多时间搜索splunk文档，但可能有一个错过的相关命令。我没有发现任何其他人的问题与我的问题相同。
让我感到惊讶的是，这似乎是map命令的一个相当正常的用例，但no option保留了所有非内部字段。
结论：有没有办法以干净合理的方式进行搜索？
我现在不上班，但我认为Splunk的版本是6.1.8（它不是Splunk Mint）。
答案 0 :(得分：0)
Splunk只支持像SQL一样管道事物，但我们想要更像PL / SQL的东西，所以我们以一种它没有设计的方式使用工具。这意味着如果Splunk没有重大改变，那么这不是一个很好的方法。
目前最好的解决方案是让应用程序计算所有感兴趣的内容并记录下来。在我的示例中，summery.log应包含locationId。在被激励了一段时间之后，不难知道所有重要的字段并将它们放在每个适用的日志中（预先根据QA进行猜测）。理想情况下，您应该为每个目的创建一个日志：performance.log，security.log，errors.log，businessMetrics.log（例如＆＃34;纽约每天有多少次成功？＆＃34;）每个都有一个漂亮的键值对格式所需的字段。同一个字段可以在多个日志中，并且单个事件可以触发多个日志。如果一切顺利，你可以放弃Splunk以获得更便宜和更好的东西，比如Elasticsearch（你可能必须运行一个脚本将旧日志转换为JSON）。
所以＆＃34;解决方案＆＃34;这个Splunk的问题是不要使用Splunk ......是的，这对Splunk来说是一个不好的迹象。为了让Splunk真正发光，它需要支持任意JavaScript（或其他语言）以及用于访问日志的预定义函数。但即便如此：为什么你需要极其复杂的搜索？如果这些字段都存在于日志中，那么您也可以将它们放在易于到达的位置。因此，即使这样，Splunk也只对回答涉及非标准字段的业务问题或调试无法使用现有字段解决的问题（两个示例都使用rex，xmlkv或spath进行解析）非常有用。