日志文件的数据分析-如何找到模式？

Question

我的公司有300多个基于windows CE 5.0移动设备的车辆，所有这些设备都在白天共享相同的软件和直接商店交付的使用模式，然后每天晚上在家庭基地进行Tcom。有一个未知事件会导致设备在中午崩溃并重新启动。在每周6天每天重新启动的计算机群中，此问题的频率为每周约10次。计算结果是每周300*6=1800引导次数(至少) 10/1800= 0.5%。我知道这个数字很低，但这超出了我老板的期望。

我的挑战是找到一种方法来扫描数千个logfille.txt文件，并试图找到某种模式。我知道这里的某个地方有一个模式。我有几个从哪里开始的想法，但我想把它扔给社区，看看你们都有什么建议。

关于这个问题的一些背景知识。应用程序在每次引导时启动一个新的日志文件。在一个有序的(控制)日志文件中，你可以看到应用程序启动，一整天都在做它的事情，然后在8-10小时后以某种有序的方式开始关闭进程。在问题日志文件中，您可以看到设备启动，然后日志在不到8小时的时间内结束，没有任何关闭顺序。然后，它启动一个新的日志文件，该文件与它在重命名过程中创建的logfile1.old的日期相同。我们拥有的应用程序是由不再在公司工作的windows开发人员自行开发的。更好的是，他们目前还不知道谁有消息来源。

我了解可用于检测内存泄漏的各种CE工具(DevHealth、零售消息等)。我们也在调查这条路线，但我确信有一种模式可以找到，只是我还不够聪明，无法找到。一定有一种方法可以使用Perl或Python来实现这一点，但我并没有看到。我有两个想法。

想法1-寻找单词使用的趋势。创建一个包含整个日志文件中使用的每个唯一单词的数组，并输出每个单词的计数。一旦我有了正在使用的单词的计数，我就可以对它们运行一些统计数据，并查找非正常事件。也许“紫色”这个词在1000行日志文件中被使用了500次(这里面可能有一些数学运算？)而在500行问题日志上只有4次？也许有一个只有在问题文件中才能看到的唯一单词。也许我可以得到一个反向的“单词云”？

想法2-将行分类为条目类型，然后查找条目类型序列中的趋势？日志文件已经有一个可预测的模式，如下所示= Level|date|time|system|source|message

我99%确定这里有一个我找不到的可见模式。所有的日志都变成了“super duper verbose”，所以有一大堆乱七八糟的东西(每秒25个日志，每个文件40k行)，这使得这更具挑战性。如果没有一个唯一的词，那么这几乎是真的。我该怎么做呢？

项目3-雇用windows CE平台开发人员是的，我们也在沿着这条道路前进，但我知道我遗漏了一种模式。他们会使用我没有的工具)，或者制作我们需要的工具来弄清楚是怎么回事。我怀疑可能存在内存泄漏、广播事件或平台工具将显示的其他事件。

第四项-我甚至没有想过你用过的东西。肯定有一些工具可以做到这一点，这些工具不像执行良好的python脚本那样有声望，我愿意沿着这条路走下去，我只是不知道这些工具是什么。

哦，对了，我不能把日志文件发到网上，所以别问了。用户承诺在看到趋势时会报告趋势，但我对此并不抱太大希望。我需要找到的只是日志中的模式，或者要复制的步骤

现在你就知道了。我可以使用什么工具或技术来开始呢？

Answer 1

这个问题根本没有输入数据，所以这个答案基本上是纯理论的，是你可以考虑的一些想法的集合。

1. 从一堆日志中分析模式你肯定可以创建一些显示相关数据的图形，这有助于缩小问题的范围，
2. 对于这类任务来说，python是非常好的。python
3. 你还可以将日志转换/插入到数据库中，这样你就能够更快地查询相关的可疑事件，甚至可以大量比较你所有的日志。
4. 一个更简单的方法可能是只关注显示崩溃的简单日志，而不是浪费大量的精力或资源来试图找到某种通用模式。从阅读一个简单的日志开始，以发现可能导致崩溃的可疑“事件”。
5. 对于这些类型的棘手问题，我最喜欢的方法与以前的方法不同，而不是专注于分析甚至解析日志，我只是尝试以一种确定性的方式在本地重现bug/s (您甚至不需要源代码)。有时候，在你的开发环境中复制生产环境真的很困难，但时间投入肯定是值得的。你在这个过程中付出的所有努力不仅可以帮助你解决这些错误，还可以更快地改进你的软件。请记住，您能够迭代better.
6. Another方法的次数越多，您可能只需要编写一个小脚本，该脚本将允许您重放崩溃的日志，但不确定这在您的环境中是否容易。通常，这种策略在使用web服务的生产软件中工作得很好，在web服务中会有很多带有数据请求和data-retrieves.

的元组

在任何情况下，如果没有看到日志中的数据类型，我就不能更具体，也不能给出更具体的细节。

Answer 2

想知道你有没有看过麋鹿堆？它是elasticsearch、kibana和log stash的首字母缩写，非常适合您的用例；它通常用于分析大量日志文件。

Elasticsearch和kibana为您提供了一个UI，让您可以交互式地探索和绘制趋势数据。在Linux平台上设置非常强大，而且非常简单，还有一个Windows版本。(我花了一两天的时间进行设置，但您从中获得了很多功能)。软件可以免费下载和使用。您可以使用类似于idea 1/2的样式

https://www.elastic.co/webinars/introduction-elk-stack

http://logz.io/learn/complete-guide-elk-stack/

关于Python / idea 4( elk可以被认为是其中的一部分)的问题，我没有对日志文件这样做，但我已经使用Regex从使用Python的文档中搜索和提取文本模式。如果你有一些关于你正在寻找的模式的线索，这也可以帮助你找到模式。

只有几个想法，希望能有所帮助。