Elastic Stack 已成为监控任何环境或应用程序的实际解决方案。 从日志、指标和正常运行时间到性能监控甚至安全，Elastic Stack 已成为满足几乎所有监控需求的一体化解决方案。 Elasticsearch 通过提供强大的分析引擎来处理任何类型的数据，成为这方面的基石。
Elasticsearch 旨在处理 TB 级的数据。 然而，这并不意味着 Elasticsearch 或 ELK 可以开箱即用地完美处理任何工作负载。 在大多数情况下，这是由于缺乏性能调整来满足确切的监控需求。 性能调优是令许多 DevOps 和系统管理员专业人员感到沮丧的一方面。 为了在 Elasticsearch 方面缓解这个问题，我们来看看如何开始调整 Elasticsearch 集群的性能。
评估你的要求
我们当然可以将环境中的所有数据推送到 Elasticsearch，但更好的问题是这样做是否能带来任何切实的好处。 是的，将所有数据放在一个易于访问的平台中可以简化事情。 然而，推送所有数据意味着更大且快速增长的数据集。 这很快就会变得笨重、成本高昂，甚至导致性能调整几乎不可能的情况。
避免这种情况的最简单方法是了解你需要从监控平台完成什么任务，并确定需要捕获并推送到 Elasticsearch 的优先级。 对最重要的数据进行分类，并将优化重点放在集群上，以满足这些高优先级数据集的需求。 假设你通过 S3 捕获 AWS VPC 流日志，但没有主动监控它们，那么将这些数据推送到 Elasticsearch 只是为了在需要时能够分析它们，这会浪费资源。 更好的解决方案是将这些数据保存在 S3 中，并在需要时使用 AWS Athena 等工具查询数据，或者在需要高级分析功能时推送数据子集。 你节省的容量可以在其他地方更好地利用，例如 APM 或其他日志，例如将更定期使用的应用程序错误日志。
例如，如果部署的主要需求是监控指标，那么更快的摄取和处理是关键。 如果我们专注于推送日志，存储也会在优化中发挥重要作用。 这是一个平衡游戏，需要选择需要推送的内容并优化摄取管道、存储和处理。 由于业务优先级不断变化，用户必须定期评估以确定需要优化的领域并定期更新优化。
硬件
无论进行怎样的优化，如果底层硬件没有足够的资源来处理摄取、处理和存储时的数据负载，用户仍然会遇到性能问题。 由于 Elasticsearch 旨在处理更大的数据集，因此需要适当的硬件资源才能实现最佳功能。 硬件资源的主要考虑因素是CPU、RAM 和存储。 你不仅需要资源来处理数据，还需要运行所需的应用程序本身。 你可能已经为摄取节点分配了足够的资源，但如果你的 Kibana 实例没有必要的资源，则部署将无法使用。
首先确定数据的确切需求，并考虑以下因素
- 摄入频率
- 数据加载
- 针对此数据运行的分析和查询的类型
- 存储要求、数据复制、保留期限
然后根据确定的需求为部署提供资源，并提供额外的空间以适应突然的使用高峰。
磁盘大小调整的注意事项
弄清楚集群的存储需求对于确保可靠的功能至关重要。 除了简单的磁盘容量要求外，用户还应该注意其他因素，例如 watermark 设置，当节点达到 85% 容量时将停止向节点发送分片，当节点达到容量的 90% 时完全停止写入现有分片 默认情况下。
如果配置了多个副本，则应该有足够的容量来容纳所有副本。 磁盘需要有足够的容量来处理所有这些需求，以及足够的空间，以便在发生故障或需要重新平衡时从其他节点重新定位分片。
索引和分片的容量规划
用户可以在 Elasticsearch 中创建任意数量的分片和索引，但不必要的大量分片和索引将会对集群管理级别以及日常使用带来显着的性能影响。
确定正确的分片和索引数量取决于多种因素，包括
- 可用硬件资源
- 数据的大小和复杂性
- 索引和分析需求、数据模型、查询需求
随着数据负载的增加，它直接影响负载，直接影响性能。 Elasticsearch 中的索引是一个或多个物理分片的逻辑分组。 更多分片意味着管理这些分片的开销更大，但查询大量较小的分片可以使每个分片的处理速度更快。 另一方面，处理相对较少的较大分片将导致更少的开销，有时在查询数据时可能会更快，但是在集群重新平衡等场景中，由于大小较大，可能需要更长的时间在不同节点之间移动分片，从而影响整个集群 表现。 Elastic 建议将以下内容作为起点。
- 目标是将平均分片大小保持在几 GB 到几十 GB 之间。 对于基于时间的数据的用例，通常会看到 20GB 到 40GB 范围内的分片。
- 避免大量分片问题。 节点可以容纳的分片数量与可用堆空间成正比。 作为一般规则，每 GB 堆空间的分片数量应小于 20。
最好的方法是使用我们将推送的数据进行测试以确定确切的要求。 最好在具有相对相似的数据集的临时集群中运行一些示例查询，然后在生产环境中镜像配置。
更多阅读：
在实际的使用中，我们还需要注意到索引的生命周期管理。对于不常用的数据，我们可以把它放入到冻层或冷层。有管索引生命周期管理的知识，可以阅读文章：
负载均衡
处理大量请求的最佳方式是平衡多个节点之间的负载。 大多数生产集群将使用负载平衡在节点之间分配工作负载，并减少单个节点不堪重负的机会。 通过在多个节点之间分配工作负载，负载平衡将毫不费力地提高集群的整体性能。
Elasticsearch 默认提供负载均衡功能，唯一的要求是用户必须手动启用它。 用户可以将节点配置为协调节点以启用智能负载平衡，从而在节点之间分配负载。 根据需求，用户可以配置多个负载均衡器来针对不同数据处理需求的特定节点。 负载均衡不仅适用于数据摄取或处理，它影响集群的各个方面。 确保您有足够数量的节点来处理从摄取节点、数据节点到 Kibana 以及 APM 和 Fleet 节点的负载（具体取决于使用情况）。
在实践中，我们可以通过配置 coordination-only 节点来实现 Elasticsearch 节点的负载均衡。你可以参考文章 “Elasticsearch 中的一些重要概念: cluster, node, index, document, shards 及 replica” 以了解更多。
刷新间隔
数据被索引后不会立即可用，这是由于配置的刷新间隔控制内存缓冲区中存在的数据的写入时间。 这相当于刷新一个数据流以获得最新的结果。 如果刷新间隔设置为10秒，它将每10秒更新一次并为你提供最新的数据。
由于每次刷新都会消耗资源，跨多个流的多次连续或并行刷新会给集群带来压力，从而导致性能下降。 因此，用户必须微调刷新间隔。 指标和正常运行时间需要更快的刷新间隔，因为这些取决于最新数据。 同时，根据日志类型，日志可以有更大的间隔，例如，如果你正在监视 Nginx 访问/错误日志，则需要更快的间隔，但对于后台任务执行日志，我们可以有更大的间隔。
作为基本经验法则，需要不断更新的数据可以以较小的间隔保留，而不太重要的数据可以设置为较大的间隔，例如每小时甚至每天刷新。
监控性能指标
我们使用 Elasticsearch 进行监控，但我们不要忘记监控 Elasticsearch 和 ELK。 应持续监控集群的健康状况和节点可用性。 由于 Elasticsearch 性能与可用硬件资源相关，用户应监控集群内所有节点的性能指标，例如 CPU、内存使用情况和磁盘 I/O。 内存使用情况监控还包括 JVM 内存以及垃圾收集统计信息。
除了索引和分片的数量之外，还必须不断监控性能和查询延迟，以识别资源密集型查询和索引，并在必要时执行任何优化。 索引和分片可以完全删除或合并以减少资源开销。 可以优化查询，或者重新配置索引以提高性能，我们甚至可以添加额外的资源以保持集群性能最佳。 这主要适用于自托管集群，应监控网络延迟和性能，以确保集群内所有资源之间的可靠且快速的连接。
主动关注集群性能是消除性能问题的最佳预防措施。更多关于健康 Elastic Stack 的文章：
- Beats：通过 Metricbeat 实现外部对 Elastic Stack 的监视
- Elastic：通过 Logstash 或 Kafka 使用 Metricbeat 监控 Elastic Stack
- Elastic：监控 Elasticsearch 及 Kibana
- Elastic：监控 Beats 及 APM Server
- Logstash：使用 Metricbeat 监控 Logstash
结论
确定数据处理需求的优先级、提供足够的硬件资源、根据用户的具体需求优化集群以及持续监控是正确调整 Elasticsearch 集群以发挥最佳性能的基础。 初始优化可能非常耗时且艰巨，但可以获得显着的性能提升，并且对于任何集群来说都是必须做的。