7

我们有大量的应用程序分布在多个数据中心的多台机器上。

在一天中,我们将接收到信号(内部或外部),这些信号会在每个应用程序中引发一系列事件。

因此,每个信号都会产生大量的事件日志数据。日志本身并不是特别结构化的,并且它们在应用程序之间也有很大不同。他们确实遵循基本约定:

<timestamp> <calling function/method> <payload>

我们在日志行中有 ID 号,可以帮助将事件与信号联系起来——然而,这些并不是万无一失的,我们有时需要使用其他方式来尝试将事件拼凑在一起。

我一直在阅读有关 Twitter 的 Storm 系统的信息,我对尝试使用它来实时分析大量日志数据并将其拼凑起来非常感兴趣。

我想做这样的事情:

  • 根据实时数据趋势生成报告和流图。
  • 查询一个信号,然后在所有应用程序中调出与该信号相关的整个事件链,包括链中步骤之间的延迟。(这个很重要)。
  • 查看相关事件,并深入了解应用程序在某个事件发生时还做了什么。

输入数据?

日志数据存储在本地日志文件中(这不太可能改变),所以我们需要一种方法将数据吞入 Storm 本身。日志文件也可以被压缩。我已经考虑过使用 Flume 或 Logstash - 人们对这些有什么看法?或者是否有其他方法可以很好地与 Storm 配合使用?

存储事件?

我还需要一种方法来存储实时报告和图表的数据,以及事件数据本身。

第二部分我觉得有点棘手——什么样的存储后端适合存储事件,以及它们之间的链接?某种图形数据库是否合适,是那些新奇的无模式 NoSQL 数据库之一,还是更传统的东西?

风暴合适吗?

最后,Storm 适合这个角色,还是其他更适合的角色?

如果我确实选择了 Storm,我可以采取什么样的方法来解决这个问题?我希望其他人有类似问题的经验。

干杯,维克多

4

2 回答 2

3

根据实时数据趋势生成报告和流图

这听起来很合适。

查询一个信号,然后在所有应用程序中调出与该信号相关的整个事件链,包括链中步骤之间的延迟。(这个很重要)。

如果您的查询仅限于最近的数据(= 不是很多数据)并且您可以允许数据丢失,我可以想象只使用 Storm 来执行此操作。如果没有,我可能会将 Storm 与数据库结合起来,主要使用 Storm 进行预处理并将数据存储到数据库中。在这种情况下,使用数据库可能会更好地处理查询。

查看相关事件,并深入了解应用程序在某个事件发生时还做了什么。

当您知道要执行什么查询并且不需要访问大量数据以进行查询时,Storm 非常棒。例如,提供显示相关事件的提要非常合适。使用数据库提供执行即席查询(向下钻取)的方法可能会更容易。此外,如果您希望允许用户查询大量数据(例如一周的数据而不是一小时的数据等),那么您可能需要一个数据库。

至于输入数据,我会使用日志集中产品。您可以创建一个与该产品将提供的任何接口交互的 Spout。或者,如果您使用允许通过套接字、JMS 等(如 log4j)发送日志的日志框架,则可以从该套接字/JMS 队列等中读取 spout。

至于数据库的选择,这真的取决于你想做什么。如果你不知道你将记录什么样的活动并且想要关联事件,我的赌注将放在图形数据库上,因为遍历事件会很容易。

于 2013-02-23T21:33:51.917 回答
2

这听起来很像我目前正在处理的案例,所以我会给出一些关于可以做什么的想法。

要获取数据,您可以查看Apache Kafka。此消息系统可以将您的日志从应用程序中移出并进入中间存储。从那里,不同的系统可以作为消费者附加,Storm 是其中之一,使用特殊的 Storm-Kafka spout 可以很好地集成。

在我们的例子中,我们有一些实时数据直接从 Kafka 代理消费到监控/仪表板和其他需要通过 Storm 处理的数据流。后者根据数据的性质存储在分布式数据库(MongoDB、Cassandra 或 Couchbase)中,然后加载到仪表板和其他系统中。

对于批处理作业,您还可以将数据从 Kafka 加载到 Hadoop 中,所有这些都可以彼此独立完成,将相同的数据从 Kafka 拉到多个系统中。

Kafka 还通过 mirror-maker 支持多个数据中心。

于 2013-03-21T19:42:51.757 回答