做统计表的网站,建设一个网站需要哪方面的费用,网络优化怎么弄,做公众号文章的网站因此#xff0c;碰巧我们在SaaS版本的LogSentinel上遇到了生产问题–我们的Elasticsearch停止了对新数据编制索引。 由于Elasticsearch只是辅助存储#xff0c;因此没有数据丢失#xff0c;但这给我们的客户带来了一些问题#xff08;他们无法在其仪表板上看到实时数据碰巧我们在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”这一事实但这实际上并不意味着什么。 因此故事的寓意是 监视一切。 发生坏事快速了解它们是一件好事。 检查您的生产配置并确保它足以满足当前需求。 它是副本JVM大小磁盘空间重试次数自动缩放规则等。 请注意托管云服务。 他们节省了很多精力但也使您失去了控制权。 他们可能遇到的问题是您唯一的选择就是联系支持部门。 如果提供托管服务请确保显示有关潜在边缘情况的足够信息。 错误控制台活动控制台或诸如此类使客户可以了解发生了什么。 验证关于库默认设置的假设。 理想情况下如果您在当前的配置状态下执行了某些意外操作则库应该警告您 确保您的应用程序是容错的即一个组件中的故障不会停止整个世界也不会导致数据丢失。 因此总的来说一个罕见的事件意外触发了蓝绿色部署其中有缺陷的配置和有缺陷的可用空间计算的结合导致了不可写的集群。 幸运的是没有数据丢失至少我学到了一些东西。 翻译自: https://www.javacodegeeks.com/2020/03/an-aws-elasticsearch-post-mortem.html
