我们正在构建一个医学图像处理软件堆栈,目前托管在各种 AWS 资源上。作为此应用程序的一部分,我们拥有一些长期运行的服务器(数据库、负载平衡器、Web 应用程序等)。收集这些服务器上的性能数据非常简单 - 我常用的 Nagios(用于监控/通知)和 Munin(用于收集性能数据和显示趋势)就可以了。
但是,作为此应用程序的一部分,我们不断在 EC2 上启动和终止计算实例。在典型使用中,这些计算实例会启动、自行配置、从消息队列接收作业,然后开始处理该作业,这个过程需要 15 分钟到 8 小时以上。作业完成后,这些实例会被终止,从此不再被听到。
收集这些短暂实例的性能数据的合理策略是什么?
我不一定需要对它们进行监控——如果它们因某种原因失败,我们的应用程序将检测到这一点,并处理在另一个实例上重新启动作业或发出标志,以便管理员可以查看情况。然而,它仍然会对于收集 CPU(用户、空闲、iowait 等)、内存使用情况、网络流量、磁盘读/写数据等信息很有用。在我们的内部数据库中,我们跟踪运行每个作业的机器的实例 ID,并且能够查找特定实例 ID 的性能数据对于故障排除和分析非常有帮助。
Munin 似乎不是一个很好的选择,因为它需要在文本文件中维护一个 munin 节点列表 - 对于高流失率的环境来说,这远非理想,并且由于每个节点运行的时间很短,我宁愿无限期地保留全分辨率数据,也不愿让 RRD 随着时间的推移淡化数据。
最后,我猜测这将需要一个监控引擎:
- 使用数据库(MySQL、SQLite 等)进行配置和数据存储
- 公开添加/删除主机和服务的 API
在评估选择时我还应该考虑其他事情吗?
不过,也许我对此想得太多了,应该sar
在这些短暂的实例上以 1 分钟的间隔运行一次,并在终止之前收集 sar db 文件。
答案1
Zenoss 有一个 EC2Manager 插件,可以自动添加所有 EC2 实例(即使是开源版本)并监控 EC2 的变化。不过 Zenoss 可能比您真正想要的更重。
答案2
答案3
答案4
我认为处理临时实例的正确方法是利用亚马逊云监控或者CloudWatch API在某种程度上。但这很大程度上取决于你真正需要看到什么……
如果你使用质量负载平衡解决方案云端,这几乎比每个实例监控更有益,因为负载均衡器可以根据更好的实时条件(例如连接数、节点响应时间/延迟、地理位置)做出更明智的路由决策。