刚刚花了两天时间解决了EC2在离岸团队logging下的开发问题。
在EC2的多个Dev实例中运行apache / tomcat V7.0.21几周，没有任何问题。
那么在D3环境下的主要性能问题。 在第一次没有问题的情况下重新在岸上运行脚本。
在D3 env中再次离岸logging缺陷，这次他们在D2中运行脚本克隆没有任何问题。 早上在D3在岸上再次运行脚本，这次有重大问题。
有一种感觉是基础设施，但没有办法certificate这一点。
调谐的servlet容器看着垃圾收集，堆，jdbc池 – 在沙盒环境中，没有错。
然后脚本在D3克隆图像中传递。 所有logging的缺陷已通过 我们什么也没变。
它在Xen虚拟机，networking或RDS上看起来像EC2问题。 不知道是什么。
当你盲目的时候，你怎么能隔离云中的错误。 没有基础设施的可见性，你从哪里开始？
任何人有类似的问题？
EC2基础设施可以被监控吗？
佩里，这听起来像你正确地诊断这个问题（EC2上的虚假/随机/意外的行为几乎总是退化的主机硬件的副作用） – 唯一的方法，你可以确认是张贴到EC2论坛或打开支持票并要求他们调查EC2团队在哪一点可以确认/否认故障硬件。
解决方法，无论你是否得到确认，总是closures并重新启动你的虚拟机，将它放在不同的硬件上。 （你可以定期在EC2论坛上看到这个）。
在未来，我会把它作为EC2的完全随机问题排除故障的第一步。 重启一个实例。
EC2上底层硬件的状态实时警报仍然没有办法，即使硬件出现故障时通过的几个电子邮件通知似乎是随机的，因为硬件仍然可能会失败，并且您从未收到其中一个监控邮件。
您可以尝试在pingdom或wasitup等单个实例上指定监控服务，但这些都是简单的pingtesting，我不知道这些是否适用于您。
另外，如果你可以缩小失败的范围，你可以看到一些随机失败的特定事情（例如，当硬件启动失败时，某些操作在EC2上变得愚蠢），你可以编写一个系统脚本/ cron作业， 1分钟或10分钟，并报告错误。
这是一种煤矿开采的方法，没有任何科学或确切的方法，但它可能会有所帮助，并允许您在用户使用之前就能够解决问题。