我们有大量应用程序分布在多个数据中心的多台机器上。
一整天,我们都会收到信号(内部或外部),这会在每个应用程序中引起一系列事件。
因此,每个信号都会产生大量的事件日志数据。日志行本身并不是特别结构化的,而且它们在应用程序之间也大不相同。不过,它们确实遵循基本约定:
<timestamp> <calling function/method> <payload>
我们在日志行中有 ID 号,可以帮助将事件与信号联系起来——但是,这些并不是万无一失的,我们有时需要使用其他方法来尝试将事件拼凑在一起。
我一直在阅读有关 Twitter 的 Storm 系统的文章,我非常有兴趣尝试使用它来实时分析大量日志数据并将其拼凑在一起。
我想做这样的事情:
获取数据?
日志数据存储在本地日志文件中(这不太可能改变),所以我们需要一种方法将数据放入 Storm 本身。日志文件也可以被压缩。我已经考虑过使用 Flume 或 Logstash - 人们对这些有什么想法?或者是否有其他方法可以很好地与 Storm 配合使用?
存储事件?
我还需要一种方法来存储实时报告和图表的数据,以及事件数据本身。
这是我觉得有点棘手的第二部分 - 什么样的存储后端适合存储事件,以及它们之间的链接?某种图形数据库是否合适,是那些新奇的无模式 NoSQL 数据库中的一种,还是更传统的东西?
Storm 合适吗?
最后,Storm 适合这个角色,还是其他更适合这个角色?
如果我确实使用 Storm,我可以采取什么样的方法来解决这个问题?我希望其他人有类似问题集的经验。
干杯,
胜利者
最佳答案
Produce reports and streaming graphs based on trends from the data in realtime
这听起来非常合适。
Query a signal, then bring up the entire chain of events related to that signal in all applications, including delays between steps in the chain. (This is important).
如果您的查询仅限于最近的数据(= 不是很多数据)并且您可以允许数据丢失,我可以想象仅使用 Storm 来执行此操作。如果没有,我可能会将 Storm 与数据库结合起来,并使用 Storm 主要用于预处理和将数据存储到数据库中。在这种情况下,使用数据库可能会更好地处理查询。
View correlated events, and drill into what else an application was doing around the time of a certain event.
当您知道要执行什么查询并且不需要访问大量查询数据时,Storm 非常棒。例如,提供显示相关事件的提要非常合适。使用数据库可能更容易提供执行临时查询(向下钻取)的方法。此外,如果您想让用户查询大量数据(例如,一周的数据而不是一小时的数据等),那么您可能需要一个数据库。
至于输入数据,我会使用日志集中产品。您可以创建一个与该产品将提供的任何界面交互的 Spout。或者,如果您使用的日志框架允许通过套接字、JMS 等(如 log4j)发送日志,则可以从该套接字/JMS 队列等中读取 spout。
至于数据库的选择,这真的取决于你想做什么。如果您不知道要记录什么样的事件并希望关联事件,我打赌将使用图形数据库,因为遍历事件会很容易。
关于logging - 使用 Twitter Storm 处理日志数据?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14731375/