Question

想象一下我有一系列事件，每个事件都有特定的事件类型，并以特定的用户/帐户为范围

用户可以设置表单的警报

我希望每秒收到100例此类事件

我当时想我每天都有一个单独的索引

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

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

Answer 1

我想到的一种方法是：

针对每个用户及其设置进行渗滤查询。例如，允许他们将带有“错误”一词的事件添加到级别错误中。
每个事件都在每个客户端索引中建立索引，并且如果每个客户端都有很多事件，那么对于每个客户端级别的索引（例如events_clientId_alarm）应该很有用。

然后，事件的映射应类似于：

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

然后，您将有大量事件要渗透，一旦事件被渗透，您就会知道该事件的存储位置。

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

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

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

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

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