0

想象一下，我有一个事件流，每个事件都有一个特定的事件类型，并作用于特定的用户/帐户

用户可以设置表单的警报

  • 当事件 A 在过去一年/月/日等内发生 3 次时发送警报。

我希望每秒收到 100 次这样的事件

我在想我每天都会有一个单独的索引

我还在考虑是否需要以某种方式预先聚合计数，因为对每个传入事件进行单独的聚合/计数查询似乎过多且不可扩展，但也许这不是问题？

解决这个问题的最佳方法是什么？

4

1 回答 1

0

我想到的一种方法是：

  • 对每个用户的设置进行渗透查询。例如，允许他们将带有“错误”一词的事件添加到级别错误。
  • 每个事件都在每个客户端索引中进行索引，如果每个客户端有很多事件，那么拥有每个客户端级别的索引应该很有用，例如 events_clientId_alarm。

那么事件的映射应该是这样的：

{
  "indexed_at": datetime,
  "level": keyword [fatal/error/debug/...],
  "log": string
}

然后你会有一个事件流来渗透，一旦事件被渗透，你就会知道在哪里存储事件。

然后，您可以使用 kibana/grafana 等 .. 方法来监控您的索引数据并在过去 5 分钟内发生 4 个带有级别警报的事件时发出警报。

在最坏的情况下，您将拥有一个包含或多或少 8640000 * 365 个文档的索引（如果您只有一个用户每秒有 100 个/事件），这是一个巨大的索引，但可以通过 ElasticSearch 正确管理（添加足够的分片到按日志级别和日期进行搜索/聚合）。

这里最重要的是知道您的数据将如何随时间增加，因为 Elasticsearch 不允许您在每个索引中添加更多分片。然后您必须想知道每个客户数据将如何随着时间的推移而增加，并猜测您需要多少分片才能使其顺利运行。

注意： 根据您与客户的交易，如果他们想要关于他们的事件数据的完整历史记录或类似的东西。您可以为每个客户每年存储一个索引，以便在需要和允许的情况下删除旧数据。

希望它有所帮助，我做了一个类似的项目，我也做了类似的方法来完成它。

于 2018-07-03T13:31:35.063 回答