我正在研究一种解决方案,将应用程序日志存储在Elastic Search中,用于许多开发团队中的许多应用程序.每个日志条目的结构与"app"字段相同,以指示应用程序.
第一个目标是支持在单个"应用程序"中进行有效查询.查询所有应用程序虽然仍然很重要,但仍然是次要的.
我正在努力确定什么是最好的:
编辑:在这两种情况下,我将使用基于时间的索引.
多指数系列
每个"app"都有一系列基于时间的索引(app1-2017-04-01,app1-2017-04-02,...等).用户可以直接对这些较小的索引执行搜索.这里的想法是,由于索引的大小较小,可能查询它们更快？
单指数系列
使用一个巨大的索引系列来表示所有应用程序日志(例如logs-2017-04-01,logs-2017-04-02,...等)用户将查询"app"字段以缩小搜索结果范围.
在这种情况下哪个更快？我很好奇其他索引的开销成本
Ran*_*dom 21
在大多数情况下,多个索引更好:
我将提供假设的指导,因为您选择忽略我的问题的答案.
当涉及到日志记录用例(基于时间的索引)时,必须掌握有关未来计划的一些数据:您希望保留记录数据的时间(保留期),将使用的模式是什么收集的数据(查询频率,索引频率),每天将有多少数据(这里指的是磁盘上的数据,也就是碎片大小).在考虑"每应用程序索引"或"单索引"问题之前,请考虑以下建议.在对分片大小进行数学计算,选择保留期的数量后,您可以考虑每个应用程序或单个索引.
特别是根据碎片大小和第二个保留期,需要考虑基于时间的索引是每日,每周还是每月.对于分片大小的一个很好的经验法则是最大30-50GB,高于此值的所有内容都将使任何恢复,分片重定位,搜索可能更慢并且可能影响群集稳定性.
如果您的应用程序能够每天生成大量数据,而这些数据将超过上述数量,则不应选择为每个应用程序生成索引.如果尺寸较小,那么它又取决于.一个节点上的大量分片正在浪费资源并且会使搜索速度变慢.每个分片都有一组固定的内存,只是因为它存在而被使用.此外,在执行搜索时,每个分片将通过一个线程执行其搜索.一个线程基本上是一个CPU核心.搜索中使用的时间跨度越大(搜索的索引越多),发生的并发搜索次数越多,尝试使用CPU核心的多个线程之间的操作系统级别的上下文切换越高.总而言之,不要试图在单个节点中挤出数百个分片,除非在任何给定时间只使用其中一些分片.如果您计划在大多数时间查询群集中的所有数据,那么您希望在每个节点上拥有的分片数量会大幅缩减.否则,您的群集将无法跟上负载.
如果您的日志记录用例是对最近的数据(最近几天到一周)主要具有高活动的用例,那么请考虑热门架构的方法:https://www.elastic.co/blog/hot-暖机体系结构功能于elasticsearch-5-X
构建和配置集群的练习总是涉及测试.那么,请尝试在尽可能与现实数据相同的数据上测试查询的性能.此外,在具有生产群集中节点的硬件规格的一个节点上执行此操作.
为不同的应用程序保留不同的索引为您提供了灵活性，最终可以通过调整每个应用程序的分片/副本数量来帮助您提高性能。在任何情况下，您始终可以通过定义别名或简单地使用通配符来允许交叉搜索。
考虑到多个团队会访问数据，为不同的应用保留不同的索引也更加清晰。最后，如果您最终想要添加某种访问控制（使用 Shield/X-Pack），拥有不同的索引肯定会让事情变得更容易。
在性能方面是更好地使用大指数高于几个小指标，因为你可以在一篇文章中看到指数与类型由阿德里安大。
索引存储在一组分片中，这些分片本身就是Lucene索引。这已经使您始终了解使用新索引的局限性：Lucene索引在磁盘空间，内存使用量和所使用的文件描述符方面具有很小但固定的开销。因此，单个大索引比几个小索引更有效：Lucene索引的固定成本可以在许多文档中更好地摊销。
我的建议是对所有应用程序使用一个基于时间的索引，其中每个应用程序都是您索引的不同类型。在每个应用程序日志上进行搜索时，这将使您更轻松，而在同一时间搜索所有应用程序时，将变得非常简单。
例如：
如果您只想在一个应用中搜索，则可以使用：
http://yourserver:9200/logs-2017-04-01/app1/_search
对于所有应用程序：
http://yourserver:9200/logs-2017-04-01/_search
需要评估的另一个好处是，每个应用程序可以具有不同数量的日志条目。这样，如果每个应用程序都有一个不同的索引，那么为每个应用程序分配碎片时将非常困难。因此，仅使用一个索引将使您在调整群集大小时更加轻松。如果索引太大，则将其分成更多碎片。
| 归档时间： |
|
| 查看次数： |
9336 次 |
| 最近记录： |