本周刚花了两天时间解决离岸团队记录的 EC2 中的开发问题。
已经在 EC2 中的多个 Dev 实例中运行 apache/tomcat 版本 7.0.21 数周，没有任何问题。
然后 D3 环境中出现重大性能问题。第一次重新运行脚本时没有任何问题。
离岸再次在 D3 环境中记录了缺陷，这次他们在 D2 克隆中运行脚本没有问题。早上在岸上再次在 D3 中运行脚本，这次出现了重大问题。
感觉这是基础设施，但没有办法证明这一点。
调整 servlet 容器查看垃圾收集、堆、jdbc 池 - 在沙盒环境中，没有任何问题。
然后脚本在 D3 克隆图像中传递。所有记录的缺陷都通过了。我们什么都没改变。
看起来像是 EC2 问题，可能是 Xen VM、网络或 RDS 的问题。不知道是什么问题。
当你盲目飞行时，如何隔离云中的故障？没有基础设施的可见性，你从哪里开始？
有人有类似的问题吗？
EC2 基础设施可以被监控吗？
答案1
佩里，听起来你正确地诊断出了这个问题（EC2 上的虚假/随机/意外行为几乎总是主机硬件性能下降的副作用）——你唯一可以确认的方法是发布到 EC2 论坛或开具支持单并要求他们进行调查，此时 EC2 团队可以确认/否认有故障的硬件。
无论你是否确认，解决方法始终是关闭并重新启动你的虚拟机，将其放置在不同的硬件上。（你可以定期在 EC2 论坛上看到这一点）。
将来，我会将解决 EC2 上完全随机的问题的第一步作为这样做：重新启动实例。
仍然无法获取有关 EC2 上底层硬件状态的实时警报，即使硬件出现故障时发送的少数电子邮件通知似乎也是随机的，因为硬件仍然可能出现故障并且您永远不会收到其中一封监控电子邮件。
您可以尝试将监控服务指向您的各个实例，如 pingdom 或 wasitup，但那些是简单的 ping 测试，我不知道它们是否适合您。
或者，如果您可以将看到的故障范围缩小到随机发生故障的特定事物（例如，当硬件开始出现故障时，EC2 上的某个操作会变得异常），您可以编写一个系统脚本/ cron 作业，每 1 分钟或 10 分钟运行一次该精确的服务并报告错误。
这是一种“煤矿中的金丝雀”方法，既不科学也不精确，但它可能会有一点帮助，并让你在用户之前发现问题。