我们正在构build一个医学image processing软件栈，目前托pipe在各种AWS资源上。 作为这个应用程序的一部分，我们有一些长期运行的服务器（数据库，负载平衡器，Web应用程序等）。 在这些服务器上收集性能数据非常简单 – 我使用Nagios（用于监视/通知）和Munin（用于收集性能数据和显示趋势）的配方工作得很好。
但是，作为此应用程序的一部分，我们不断启动和终止EC2上的计算实例。 在典型用法中，这些计算实例启动，configuration自己，从消息队列接收作业，然后开始处理该作业，这需要15分钟到8小时以上的时间。 工作完成后，这些实例被终止，永远不会再被听到。
在这些短暂的实例中收集性能数据的体面战略是什么？
我不一定需要对他们进行监控 – 如果他们因为某种原因失败了，我们的应用程序会检测到这个情况，并处理另一个实例的重新启动工作，或者提升这个标志，这样pipe理员就可以看看事情了。 但是，收集CPU（用户，空闲，iowait等），内存使用情况，networkingstream量，磁盘读写数据等信息仍然是有用的。在我们的内部数据库中，我们跟踪机器的实例ID运行每个作业，查找特定实例ID的性能数据以进行故障排除和分析将非常有帮助。
Munin似乎不是一个好的候选人，因为它需要在文本文件中保留一个munin节点的列表 – 对于stream量大的环境来说，这并不理想，而且每个节点运行的时间很短，我宁愿保留全分辨率的数据，也不愿意随着时间的推移使RRD数据下降。
最后，我的猜测是，这将需要一个监控引擎：
评估选项时，我应该考虑其他事情吗？
但是，也许我正在过度思考这个问题，而且应该每隔1分钟在这些短暂的实例上运行sar ，并在终止之前收集sar db文件。
Zenoss有一个EC2Manager插件，可以自动添加所有的EC2实例（甚至在开源版本中），并监视EC2的变化。 不过，Zenoss可能会比你真正想要的更重。
对于短暂的实例，Nagios不太适合，因为您将不得不重新编写configuration文件。
我最近研究了哪些“众所周知/维护”的监测系统适合于这样的情况。
以下监视系统使添加/删除主机变得更加容易：
我想，你需要某种中央CMDB来成为真相的来源。 然后你可以使用CMDB作为Puppet / Chef / etc的数据源，它可以configuration监控主机，并将它们添加到监控服务器。
我认为短暂实例的正确方法是以某种方式利用Amazon CloudWatch或CloudWatch API 。 但是，这在很大程度上取决于你真正需要看到什么
如果您在“云”中使用高质量的负载平衡解决scheme ，那么它几乎比每实例监控更有利，因为负载平衡器可以基于更好的实时条件（例如，连接数，节点响应时间/延迟，地理位置）。
不过，我们正在寻求这样做，并可能与我们使用的商业监控套件集成。 否则， Zenoss似乎有一个jar装解决scheme。
如果您关心的是收集性能数据而不是监控，而且您希望每次实例出生或死亡时都需要进行configuration， collectd将非常适合。
将一个实例设置为服务器，即将networking插件configuration为接收数据，并将RRDtool插件configuration为写入数据。 使用您需要的任何插件来设置您的临时实例，以收集相关的性能数据，并使用configuration为将数据发送到服务器的networking插件。
即使这些实例是短暂的，您将需要更改默认的RRATimespan 。 如果您不想将数据存储在RRD文件中，collectd可以发送到其他数据存储，如石墨或mongodb。
Zabbix将是一个很好的select。
设置起来很简单，您可以configuration自动注册和发现，收集性能数据并在X天后清理logging。