AWS的负载预计会降低

可能熟悉虚拟化的“嘈杂邻居”问题--在同一台物理机器上的其他人的实例“窃取”了您的实例的CPU。我不会给出如何解决这个问题的线索(快速和肮脏-通过终止您的实例并让它在另一台物理机器上生成)，而是我将解释我的观察“在规模上”。

实际上，我并没有在AWS上遇到一个典型的“吵闹邻居”--也就是说，有一个例子被严重地“阻塞”了。但正如我在AWS的总体性能取决于许多因素。

一天中的时间是显而易见的--因为我在UTC+2工作，我的清晨实际上是欧洲还没有醒来的时候，而美国已经睡着了。因此，AWS的负载预计会降低。当我在上午和下午试验CloudFormatationStack时，差别是非常明显的(尽管我还没有测量)--“早晨”堆栈的运行速度比“下午”堆栈的要快得多。创建实例、ELB和整个堆栈所需的时间较少。

但上周我们观察到了一些很奇怪的事情。我们的常规负载测试必须在周四运行，但是直到本周末，性能都很糟糕--我们甚至无法正常运行--许多请求由于内部ELB的超时而失败。最重要的是，现货实例(你出价一定价格，而其他人可以在任何时候从你那里“偷”)是很难保持的--对它们有巨大的需求，而我们的现货实例经常被其他人声称。但据报道，AWS区域处于“OK”状态，没有错误。

上周四发生了什么？英国选举。我无法证明它对整个AWS产生了如此大的影响，我最初是作为一个笑话来解释的，但在英国大选期间，AWS地区可能会承受很大的负担。明显的高负荷，这似乎，使整个基础设施为其他人承受压力。(当然，这可能是个巧合)。它不是一个典型的“吵闹的邻居”--是ELB没有表演。然后，这个星期，一切都恢复正常了。

AWS基础结构是复杂的，它不仅仅是“实例”，所以即使您有足够的CPU来处理吵闹的邻居，任何其他组件都会受到整个基础结构负载增加的影响

https://www.jianshu.com/p/0add98605aea

例如ELB，RDS，SQS，S3，甚至你的VPC子网。当AWS处于压力之下时，你会感觉到它，不管怎样。

道德？当然，要拥抱失败。具有监视功能，可以将这些事件通知您不太稳定的基础设施，并具有容错设置，并进行适当的重试和回退。

志收集对于正确分析生产中的问题至关重要。在所有服务器上搜索和通知异常的接口是必须的。当然，如果您有一台服务器，您可以轻松地对其进行ssh并检查日志，但是对于更大的部署，集中收集日志要比登录到10台机器以查找“发生了什么”要好得多。

这样做有很多选择，大致分为两组：第三方服务和由您安装的软件。

第三方(或“基于云的”)日志收集服务包们非常容易安装，并且您为您使用的东西付费。基本上，您将每条消息(例如，通过自定义的Logback Appder)发送到提供者的端点，然后使用仪表板来分析数据。在许多情况下，这将是首选的方式。

然而，在其他情况下，公司政策可能不赞成使用第三方服务来存储特定于公司的数据，或者额外的成本可能是不可取的。在这种情况下，需要在安装和管理内部日志收集软件方面付出额外的努力。它们以类似的方式工作，但实现细节可能有所不同(例如，软件使用某种代理收集本地日志并将其聚合，而不是使用一个附加器向目标端点发送消息)。开源选项包括

https://www.douban.com/doulist/145585807/

在进行了非常快速的研究之后，我认为灰色日志最适合我们的需求，因此下面是AWS上安装过程的描述(尽管第一部分适用于不同的基础设施)。

首先要看的是由graylog提供，包括docker、OpenStack、流浪者和AWS。不幸的是，AWS版本有两个缺点--它使用的是Ubuntu，而不是AmazonAMI。这不是一个大问题，尽管您在堆栈中使用的一些通用脚本可能需要重写。另一个是破坏程序--当你启动它时，它不会运行一个网络界面，尽管它声称它应该运行。只启动MongoDB、ElasticSearch和灰色日志服务器。有两个实例--一个Web，另一个用于其他的--会使事情变得复杂，所以我选择了手动安装。

Graylog有两个组件--服务器(负责输入、索引和搜索)和Web接口(它是一个与服务器通信的不错的UI)。Web接口使用MongoDB作为元数据，服务器使用ElasticSearch存储传入的日志。下面是处理安装的bash脚本(CentOS)。请注意，没有“sudo”，因为初始化脚本在AWS上作为root执行。

现在，可以在实例上运行所有内容。然后，您必须执行一些AWS特定的事情(如果使用CloudForms，这将包括一堆JSON)。下面是清单：

https://www.douban.com/doulist/145579081/

• 您可以有一个具有一个实例的自动缩放组，也可以有一个实例。我更喜欢ASG，虽然另一个比较简单。如果实例死亡，ASG将自动恢复。
• 将上述脚本设置为在实例/ASG的启动配置的用户数据中调用(例如，首先从S3获取该脚本)
• 允许udp端口12201(默认日志端口)。这应该发生在实例/ASG安全组(入站)、应用程序节点安全组(出站)以及VPC的网络ACL中。保它真的通过。限制所有源的访问，但实例除外。
• 您需要将灰日志服务器实例的私有IP地址传递给所有应用程序节点。这在AWS上是很棘手的，因为私有IP地址会发生变化。所以你需要稳定的东西。您不能使用ELB(负载平衡器)，因为它不支持UDP。有两种选择：
  • 在启动时将弹性IP与节点关联。将该IP传递给应用程序节点。但是有一个陷阱--如果他们连接到弹性IP，这将通过NAT(如果你有)，你可能不得不打开你的实例“向世界”。因此，您必须将弹性IP转换为相应的公共DNS。然后DNS将被解析为私有IP。您可以通过手动和hacky来做到这一点：

    1	GRAYLOG_ADDRESS="ec2-$GRAYLOG_ADDRESS//./-}.us-west-1.compute.amazonaws.com"

    或者您可以使取与弹性IP相关联的实例的实例细节，然后与另一个调用一起获取其公共DNS。

  • 您可以使用Route 53(AWS DNS管理器)，而不是使用限制在单个实例上的弹性IP。这样，当灰日志服务器实例启动时，它可以将自己附加到路由53记录中，这样就允群中的多个灰日志实例。通过AWSCLI再次操作Route 53记录。然后，您只需将域名传递给应用程序节点，以便它们可以发送消息。
• 或者，您可以在所有节点(作为代理)上安装灰色日志服务器，并将它们指向ElasticSearch集群。但这要复杂得多，而且可能不是预期的方法。