我有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存储其结果的原因），但问题是这只是一个简化的模拟查询，实际查询很复杂并且重复大事是非干，可能不利于表现。
选项2需要一个有效的每个字段的列表，但是很混乱（我认为这是大约10个字段）。它也不灵活，但这并不是一项要求，因为这些字段不会很快改变。
选项3永远不会像以往那样完成。绝大多数事务都不是失败，map命令非常慢。不，我不需要超过几千，上面的最大搜索只是为了突出语法上最干净的方法的问题。
他们都很糟糕。选项3不是一种选择。选项1缓慢而混乱。选项2很杂乱，但在其他方面很好，使其成为最佳选择。我花时间搜索splunk文档，但可能有一个我错过的相关命令。我没有发现任何其他人的问题与我的问题相同。
令我惊讶的是，这似乎是map命令的一个相当正常的用例，但是有no option来保存所有非内部字段。
底线：有没有办法以干净合理的方式进行搜索？
我现在不上班，但我认为Splunk的版本是6.1.8（它不是Splunk Mint）。
Splunk只支持像SQL一样管道事物，但是我们想要更像PL / SQL的东西，所以我们以一种不是为它设计的方式使用工具。这意味着如果Splunk没有重大改变，那就不是一个很好的方法。
目前最好的解决方案是让应用程序计算所有感兴趣的内容并记录下来。在我的示例中，summery.log应包含locationId。在推出一段时间之后，不难知道所有重要的字段并将它们放在每个适用的日志中（preprod你只需根据QA猜测）。理想情况下，您应该为每个目的创建一个日志：performance.log，security.log，errors.log，businessMetrics.log（例如“纽约每天有多少次成功？”），每个都包含一个很好的密钥所需的所有字段价值对格式。同一个字段可以在多个日志中，并且单个事件可以触发多个日志。如果一切顺利，你可以放弃Splunk以获得更便宜和更好的东西，比如Elasticsearch（您可能必须运行脚本将旧日志转换为JSON）。
所以这个Splunk问题的“解决方案”就是不要使用Splunk ......是的，这对Splunk来说是一个不好的迹象。为了让Splunk真正发光，它需要支持任意JavaScript（或其他语言）以及用于访问日志的预定义函数。但即便如此：为什么你需要极其复杂的搜索？如果这些字段都存在于日志中，那么您也可以将它们放在易于到达的位置。因此，即使这样，Splunk也只对回答涉及非标准字段的业务问题或调试现有字段无法解决的问题（两个示例都使用rex，xmlkv或spath进行解析）非常有用。