AWS Elasticsearch后模式

因此，碰巧我们在SaaS版本的LogSentinel上遇到了生产问题–我们的Elasticsearch停止了对新数据编制索引。由于Elasticsearch只是辅助存储，因此没有数据丢失，但这给我们的客户带来了一些问题（他们无法在其仪表板上看到实时数据）。以下是事后分析–发生了什么事情，发生了什么原因，我们如何处理它以及如何防止它。

让我从系统如何运行的背景开始–我们通过RESTful API（或syslog）接受审核跟踪条目（日志），并将其推送到Kafka主题。然后使用Kafka主题将数据存储在主存储（Cassandra）中并对其进行索引，以便在Elasticsearch中更好地进行可视化和分析。选择托管的AWS Elasticsearch服务是因为它节省了集群管理的所有开销，并且作为一家启动公司，我们希望最大程度地减少基础架构管理工作。就像下面将要看到的那样，这是一种祝福和诅咒。

我们在许多元素上启用了警报，包括Elasticsearch存储空间和日志文件中的应用程序错误数。这使我们能够快速响应问题。因此触发了“大量应用程序错误”警报。索引由于FORBIDDEN/8/index write而被阻止。我们有一个启用它的系统调用，因此我尝试运行它，但是不到一分钟后，它再次被阻止。这意味着我们的Kafka使用者无法处理消息，这很好，因为我们在Kafka中有足够的消息保留期限，因此不会丢失任何数据。

我调查了这种阻止的可能原因。根据Amazon的说法，其中有两个 -JVM内存压力增加和磁盘空间不足。我检查了指标，一切看起来都很好– JVM内存压力几乎没有达到70％（阈值是75％），并且有超过200GiB的免费存储。 Elasticsearch应用程序日志中只有一个WARN（这是“节点故障”，但此后未报告任何问题）

这个问题还有另一个奇怪的方面–节点的数量是配置的两倍。这通常在升级期间发生，因为AWS正在为Elasticsearch使用蓝色/绿色部署，但是我们最近没有进行任何升级。这些额外的节点通常会在很短的一段时间后消失（在重新部署/升级准备就绪之后），但是在这种情况下它们不会消失。

无法通过SSH连接到实际机器，无法通过Elasticsearch手段取消阻止索引，无法关闭或重新启动节点，我提出了支持请求。经过我们几次和几次交流后，问题已经明确并得到解决。

此问题的主要原因是2倍。首先，我们有一个无法反映集群状态的配置–我们假设有更多的节点，而共享和副本配置意味着我们没有分配副本（此处和此处的碎片和副本更多）。最佳实践是使节点>副本数，以便每个节点获得一个副本（加上主分片）。拥有未分配的分片副本本身并不坏，并且有合理的理由。我们可能被认为是配置错误，但不是立即造成负面影响的一种。我们之所以选择这些设置，部分原因是创建集群后无法在AWS中更改某些设置。并且不支持打开和关闭索引。

第二个问题是AWS Elasticsearch逻辑，用于计算其断路器中阻止索引编制的可用存储。因此，即使每个现有节点上都有200+ GiB可用空间，AWS Elasticsearch仍认为我们空间不足并阻止了索引编制。我们无法看到这一点，因为我们只能看到可用的存储，而没有看到AWS认为可用的存储。因此，计算将获得分片+副本的总数，然后将其乘以每个共享存储。这意味着未分配副本不会占用实际空间，就好像它们已占用空间一样。这种逻辑是违反直觉的（如果不是完全错误的话），几乎没有办法预测它。

发生蓝/绿部署时，将触发此逻辑–因此，在正常操作中，将检查实际的剩余存储空间，但是在升级期间，将触发基于分片的检查。那已经阻塞了整个集群。但是，什么触发了蓝绿色部署过程？

我们有时需要访问Kibana，并且由于严格的安全规则，默认情况下任何人都无法访问它。因此，我们临时更改了访问策略，以允许从我们的办公室IP进行访问。预计此更改不会触发新的部署，也永远不会导致这种变化。但是，AWS文档指出：

在大多数情况下，以下操作不会导致蓝绿色部署：更改访问策略，更改自动快照时间，如果您的域具有专用主节点，则更改数据实例计数。
有一些例外。例如，如果自启动三个可用区支持以来您尚未重新配置域，则Amazon ES可能会执行一次蓝/绿部署，以在可用区中重新分配专用主节点。

显然还有其他例外，其中之一发生在我们身上。这就导致了蓝色/绿色的部署，由于我们的配置有缺陷，这又触发了基于奇数逻辑的索引块，以假定未分配的副本占用了存储空间。

我们如何修复它-我们用更少的副本创建了索引，并开始了重新索引（它从主要来源获取数据并成批索引）。这减小了占用空间，AWS手动干预以“取消”蓝/绿部署。一旦知道了问题，修复就很容易了（由于其他索引配置的更改，我们仍然必须重新创建索引）。（再次）说一下在解决问题和沟通方面，AWS支持有多好。

正如我在开始时所说的，这并不意味着有数据丢失，因为我们让Kafka将消息保留了足够的时间。但是，一旦索引可写，我们就希望使用者从上一次成功发送的消息开始继续-我们专门编写了事务处理行为，该行为仅在成功存储到主存储中并成功建立索引之后才提交偏移量。不幸的是，我们正在使用的kafka客户端打开了我们忽略的自动提交功能。因此，消费者跳过了失败的消息。它们仍然在Kafka中，我们正在使用单独的工具对其进行处理，但这向我们表明了我们的假设是错误的，并且代码调用了“ commit”这一事实，但这实际上并不意味着什么。

因此，故事的寓意是：