vic*_*ooi 7 logging bigdata apache-storm
我们在多个数据中心的许多机器上分布了大量应用程序.
在一天中,我们将收到信号(内部或外部),这会在每个应用程序中引发一系列事件.
因此,每个信号产生大量的事件日志数据.日志本身并不是特定的结构,它们在应用程序之间也有很大不同.他们确实遵循基本惯例:
<timestamp> <calling function/method> <payload>
我们在日志中有ID号可以帮助将事件链接到一个信号 - 但是,这些并非万无一失,我们有时需要使用其他方法来尝试将事件拼凑在一起.
我一直在阅读有关Twitter的Storm系统的内容,我非常有兴趣尝试实时分析这些大量的日志数据并将其拼凑在一起.
我想做的事情如下:
日志数据存储在本地日志文件中(这不太可能改变),因此我们需要一种方法将数据插入到Storm本身.日志文件也可能被压缩.我对使用Flume或Logstash感兴趣 - 人们对这些有什么看法？或者有没有其他方法可以与Storm一起使用？
我还需要一种方法来存储实时报告和图形的数据,以及事件数据本身.
这是我发现有点棘手的第二部分 - 哪种存储后端适合存储事件,以及它们之间的链接？某种图形数据库是否合适,其中一种新的无模式NoSQL,或者更传统的东西？
最后,Storm适合这个角色,还是更合适的东西？
如果我选择Storm,我可以用什么方法来解决这个问题呢？我希望其他人有类似问题集的经验.
干杯,维克多
根据实时数据趋势生成报告和流图
这听起来非常合适。
查询信号，然后在所有应用程序中显示与该信号相关的整个事件链，包括链中步骤之间的延迟。（这个很重要）。
如果您的查询仅限于最近的数据（=不是很多数据）并且您可以允许数据丢失，我可以想象仅使用 Storm 来完成此操作。如果没有，我可能会将 Storm 与数据库结合起来，主要使用 Storm 来预处理并将数据存储到数据库中。在这种情况下，使用数据库可能可以更好地处理查询。
查看相关事件，并深入了解应用程序在某个事件发生期间还执行了哪些操作。
当您知道要执行什么查询并且不需要访问大量查询数据时，Storm 就非常有用。例如，提供显示相关事件的提要就非常适合。使用数据库提供执行即席查询（向下钻取）的方法可能会更容易。另外，如果您希望允许用户查询大量数据（例如一周的数据而不是一小时的数据等），那么您可能需要一个数据库。
至于输入数据，我会使用日志集中产品。您可以创建一个与产品提供的任何界面进行交互的 Spout。或者，如果您使用的日志记录框架允许通过套接字、JMS 等（如 log4j）发送日志，您可以从该套接字/JMS 队列等中读取 spout。
至于数据库的选择，这实际上取决于你想做什么。如果您不知道要记录哪种活动并且想要关联事件，那么我的赌注将是图形数据库，因为遍历事件很容易。