在我们的应用程序中，我们将关键信息记录到日志文本文件中，以便以后进行调试。如果我已经有一些数据点，如订单号或“找不到对象引用”类型的错误，使用splunk很容易识别问题。但它的挑战让我用splunk来全面了解问题。为了能够识别软件中的实际问题，我必须仔细阅读多个日志文件或整个日志文件，以便在问题发生之前查看应用程序正在执行的操作。以人类方式读取整个日志文件有助于我在实际问题发生之前确定应用程序与其他数据点的行为方式。换句话说，很难让我看到splunk错误的“真正根本原因”。您在软件开发领域的经验是什么？
答案 0 :(得分：2)
提出splunk问题的适当位置是
那里有一群人会帮助你...
@Cninroh在大多数帐户上都是错误的。我在Splunk的开发工作。
您可以根据需要进行搜索以找到根本原因。您需要根据需要进行搜索。我不知道您的数据，但是，例如，下面的搜索会找到在“磁盘错误”之前以root身份登录的用户......
login root [ search disk-error | head 1 | eval latest = _time - 5*60 ] | head 1
您还可以设置警报以查找异常值和其他意外情况，这样您就不必积极寻找问题。它们可以推送给你。
答案 1 :(得分：1)
去除人性方面非常困难。话虽如此，我最近不得不领导splunk部署的开发方面，并且有一些很棒的工具可以满足您的一些需求。使用splunk的内置警报是完成其中一些操作的最简单方法。不幸的是，在splunkbase或其他地方的许多splunk相关事物（我的意思是，严重的是，请不要使用curl，并且对于web服务或其他api的每个示例都使用不安全的标志）的实际答案和示例很少。互联网。
无论哪种方式，我发现的一些最优雅的解决方案，用于查找特定类型的日志或日志数据，在我的搜索中大量使用“rex”命令。它将指定Perl正则表达式以帮助从正确的字段中提取正确的信息。来自splunk网站的Here's the new-ish page on it。
这当然假设您知道哪些字段包含您要查找的数据。不幸的是，如果在索引器上没有正确设置内容，这可能是Windows日志的问题。
答案 2 :(得分：0)
对于Splunk以您可能想要的方式工作（根据您的描述判断），您将“被迫”修改应用程序的某些部分以适应Splunk索引和存储数据的方法。
Splunk依赖于事件索引，这些事件是来自系统中各种日志的错误或状态消息。 Splunk索引的主要目标是日期，因此没有日期表示没有索引，之后将导致Splunk搜索中的不良结果。
在不同的情况下保留不同搜索字词的列表或备忘单也是一种很好的做法，因此您可以轻松生成曾经成功的结果。
在我们公司，我们为客户创建了一个特定版本的软件，他们选择使用Splunk作为他们的首选监控工具。这个自定义应用程序和我们的标准应用程序之间基本上的区别在于它非常强烈地依赖于将它所做的一切写入日志文件，并将它们保存在逻辑事件中，并使用“segemtn - time - root cause - user-group - file - action - 结果 - 注意“ 这使我们能够找到并实时发现问题，并且成本比以前低很多。
答案 3 :(得分：0)
就像您需要学习如何阅读和评估日志文件一样，您需要学习如何使用Splunk来充分利用您的工作。
对于在一台计算机上运行代码的开发人员，您可以轻松读取一个日志文件并查看发生的情况。一旦您发布该代码并在多层或分布式体系结构上运行，您就无法轻松跟踪发生问题的位置和时间。也许您甚至无法访问生产系统日志。
这是一个例子。通过简单的关键字搜索找到您的错误。单击有趣事件的时间戳。这使Splunk的时间范围达到1秒。清除关键字搜索并输入*以查看1秒内的所有事件。将您正在查看事件的主机和设备限制为您感兴趣的系统/应用程序。
您现在可以在一个视图中查看应用中涉及的所有系统中的事件。如果需要捕获根事件，您可以缩小到更多时间。如果要按时间顺序读取，请使用“| reverse”命令 - 顶部（最旧）到底部（最新）而不是Splunk的默认反向时间顺序。
找到问题后，您可以将该搜索转换为Splunk警报，以便日后得到通知。解决该问题后，您可以启用警报，这样如果您的修复程序在所有情况下都不是100％有效，或者未进入下一个主要/次要版本，您将收到通知。