用于事件日志指标的数据体系结构？

我的服务具有大量正在进行的用户事件，因此我们想做一些事情，例如“ 从日期D开始计数事件类型T的发生”。

我们正在尝试做出两个基本决定：

1. 存储什么？存储每个事件与仅存储聚合

   • （事件日志样式）记录每个事件并在以后对它们进行计数。
   • （时间序列样式）每天存储一个汇总的“ 日期D的事件E数”

2. 数据存储在哪里

   • 在关系数据库（尤其是MySQL）中
   • 在非关系（NoSQL）数据库中
   • 在平面日志文件中（通过，通过网络集中收集syslog-ng）

什么是标准做法？在哪里可以找到有关比较不同类型系统的更多信息？

额外细节：

• 事件流总数很大，每天可能有数十万个条目
• 但是我们目前的需求只是计算其中的某些类型的事件
• 我们不一定需要实时访问原始数据或聚合结果

恕我直言，“将所有事件记录到文件中，稍后对其进行爬网以过滤和聚合流”是一种非常标准的UNIX方式，但是我的Rails-y同胞似乎认为除非在MySQL中，否则什么都不是真实的。

视情况而定，我会给您建议，为您提供新的视角

存储什么？存储每个事件与仅存储聚合

（事件日志样式）记录每个事件并在以后对它们进行计数。

如果您计划不漏掉任何细节，即使现在它们已经不相关，在我看来这也是最好的方法，因为有时，随着结果的到来，您会发现其他一些对于X或Y不相关的事件，或者他们没有带来任何额外的信息，但是经过一些分析，它确实做到了，并且您还需要跟踪该信息，因为记录下来但没有说明，因此您可能需要一些时间才能将其添加到图片中。

（时间序列样式）每天存储一个汇总的“日期D的事件E数”

如果您想在明天实现并使用它，它可以工作，但是如果您有新的要求，或者发现与由于某种原因而被省略的另一个事件相关联，那么您需要添加此新事件，然后等待一些长时间保持良好的汇总级别

数据存储在哪里

在关系数据库（尤其是MySQL）中

如果您要记录所有事件，那么对于数据库而言，第一种选择可能很沉重，因此恐怕MySQL可能会变得太小，如果您想使用RDBMS解决方案，则您可能会认为它更大，例如PostgreSQL或专有的Oracle或DB2 。

但是对于聚合将是一个不错的选择，根据生成的负载，您可以在代码中聚合并将这些聚合插入数据库中。

在非关系（NoSQL）数据库中

如果您使用此解决方案，则需要查看在Wikipedia上阅读哪种方法可以对您有所帮助，但由于没有足够的经验，我在该主题上无济于事，我主要使用rdbms。

在平面日志文件中（通过syslog-ng通过网络集中收集）

我个人不鼓励您选择该选项，如果文件太大，则解析起来会更困难，但是我仍然不知道主要目的是跟进系统，还是只是检查日志文件...

希望能帮助到你！

我认为您解析日志，计数结果并将结果存储在数据库中的想法是正确的。不确定您是否仍然希望将所有这些原始日志存储在数据库中（我认为这就是您所说的同胞的建议）。您已经有文件中的日志，对吗？您可以将其存档。我想这真的取决于您的用例。

也同意@ThorbjørnRavn Andersen提出的将您的“评论答案”移至该问题。

取决于您的预期用途。如果您有一个显示合计值的标准图形或报告，那么您将希望仅过滤事件进入时的事件并将它们聚合到适当的存储桶中。如果您需要深入研究特定事件，或者您认为以后可能想要返回并重新分析/重新分类事件，则应该存储各个事件。

如果您有时间和空间，我通常希望做的是汇总数据，但将详细信息存储在（压缩的）文件中。这些细节不必很容易获得，因为我几乎从不需要它们，但是如果分类标准发生变化，它们可用于批量重新处理。

任何架构决定都应由业务需求驱动。在您的情况下，您应该对要从日志系统获取哪些信息有更清晰的了解，以便决定如何存储，需要多长时间获取一次该信息以及需要等待多长时间才能获得结果。这就是驱动日志收集器，事件相关器和类似应用程序设计的原因。

建议您不要看一些与您尝试开发的应用程序类似的应用程序，而不要让我发表意见。其中一些功能可能比您假装要强大得多，但是如果您遵循所遵循的体系结构和存储策略，也不会受到损害。在专业方面，您拥有RSA和Arcsight等SIEM应用程序，在开放源方面，您拥有诸如Kiwi或OSSIM（也具有基于专业设备的版本）之类的计划。

要考虑的另一件事是，当您开始使用该工具获得的结果时，您将开始很可能收到来自管理层的许多要求，以获取更多信息和更详细的信息。因此...请谨慎使用，并在地平线上规划您的视野。它可能会给您带来更多的工作，但是绝对可以得到很多支持和可见性（包装中有压力）。