我们有一个在ELB后面有EBS（用于启动性能）的实例。当前实例情况下，当实例在内存中耗尽时，它将使用EBS重新引导启动时间减少50％（下降到4分钟），在N次中进行彻底的压力测试，重启实例处于start_failed状态。现在我们检查了日志：
[2016-03-21T17:06:28+11:00] INFO: Forking chef instance to converge...
[2016-03-21T17:06:28+11:00] INFO: *** Chef 12.7.2 ***
[2016-03-21T17:06:28+11:00] INFO: Chef-client pid: 2965
[2016-03-21T17:06:31+11:00] INFO: HTTP Request Returned 404 Not Found: Object not found: chefzero://localhost:8889/nodes/tmainsite3.localdomain
[2016-03-21T17:06:31+11:00] INFO: Setting the run_list to [] from CLI options
[2016-03-21T17:06:31+11:00] INFO: Run List is []
[2016-03-21T17:06:31+11:00] INFO: Run List expands to []
[2016-03-21T17:06:31+11:00] INFO: Starting Chef Run for tmainsite3.localdomain
[2016-03-21T17:06:31+11:00] INFO: Running start handlers
[2016-03-21T17:06:31+11:00] INFO: Start handlers complete.
[2016-03-21T17:06:31+11:00] INFO: HTTP Request Returned 404 Not Found: Object not found:
[2016-03-21T17:06:31+11:00] INFO: Loading cookbooks []
[2016-03-21T17:06:31+11:00] WARN: Node tmainsite3.localdomain has an empty run list.
[2016-03-21T17:06:31+11:00] INFO: Chef Run complete in 0.074774713 seconds
[2016-03-21T17:06:31+11:00] INFO: Running report handlers
[2016-03-21T17:06:31+11:00] INFO: Report handlers complete
对我来说似乎是空的..我理解当由于VPC中的代理服务延迟导致启动停止时状态会发生什么但是我认为这是不同的...它是start_failed并且自动修复不起作用它..所以它不会重新启动并返回健康检查..
我们尝试直接访问并且实例正在运行我们可以看到我们的应用程序在那里工作并且我们检查了负载均衡器..实例不存在有0/0，我认为这应该停止服务吗？
请帮助..我们有点失落..我知道这里发生了很多事情。如果可以解释，我很高兴。
谢谢！
编辑：从/var/log/aws/opsworks/opsworks-agent.keep_alive添加日志
[2016-03-21 17:03:09] INFO [opsworks-agent(1379)]: keep_alive: Reporting keepalive. (0.991 sec)
[2016-03-21 17:04:09] DEBUG [opsworks-agent(1379)]: keep_alive: Performing keepalive
[2016-03-21 17:04:10] INFO [opsworks-agent(1379)]: keep_alive: Reporting keepalive. (0.972 sec)
[2016-03-21 17:05:10] DEBUG [opsworks-agent(1379)]: keep_alive: Performing keepalive
[2016-03-21 17:05:11] INFO [opsworks-agent(1379)]: keep_alive: Reporting keepalive. (1.276 sec)
[2016-03-21 17:06:11] DEBUG [opsworks-agent(1379)]: keep_alive: Performing keepalive
[2016-03-21 17:06:12] INFO [opsworks-agent(1379)]: keep_alive: Reporting keepalive. (0.987 sec)
[2016-03-21 17:09:07] INFO [opsworks-agent(1384)]: keep_alive: Initializing Instance Service client with credentials from IAM instance profile.
[2016-03-21 17:09:08] INFO [opsworks-agent(1384)]: keep_alive: Running on AWS OpsWorks instance 1420ff17-a4db-4c2f-9c48-5190918e8518
[2016-03-21 17:09:08] DEBUG [opsworks-agent(1384)]: keep_alive: Performing keepalive
[2016-03-21 17:09:09] ERROR [opsworks-agent(1384)]: keep_alive: Access denied to the OpsWorks instance service
[2016-03-21 17:10:39] DEBUG [opsworks-agent(1384)]: keep_alive: Performing keepalive
[2016-03-21 17:10:40] ERROR [opsworks-agent(1384)]: keep_alive: Access denied to the OpsWorks instance service
[2016-03-21 17:12:10] DEBUG [opsworks-agent(1384)]: keep_alive: Performing keepalive
[2016-03-21 17:12:11] ERROR [opsworks-agent(1384)]: keep_alive: Access denied to the OpsWorks instance service
[2016-03-21 17:13:41] DEBUG [opsworks-agent(1384)]: keep_alive: Performing keepalive
[2016-03-21 17:13:42] ERROR [opsworks-agent(1384)]: keep_alive: Access denied to the OpsWorks instance service
[2016-03-21 17:15:12] DEBUG [opsworks-agent(1384)]: keep_alive: Performing keepalive
[2016-03-21 17:15:13] ERROR [opsworks-agent(1384)]: keep_alive: Access denied to the OpsWorks instance service