我不确定要使用哪个监控框架。目前我正在查看Nagios 或Sensu。
谁能给我一个很好的参考来显示这两者的比较（或任何其他可能是一个很好的解决方案的监控工具）？我的主要目的是在 EC2 上进行横向扩展。我正在使用 Opscode Chef 进行系统集成。
【问题讨论】：
标签： amazon-ec2 monitoring chef-infra
Nagios 和 Sensu 之间的一个重要区别 -
Nagios 要求 1) 检查 2) 处理程序的所有配置，但最重要的是 3) 将主机写入 Nagios 服务器上的配置文件中。这意味着每次更改上述 3 个中的一个（例如添加新主机，删除旧主机）时，您都需要重新编写配置文件并重新启动 Nagios。
Sensu 与上述几乎相同，但有一个重要区别 - 在架构中添加或删除主机时（大多数自动缩放云部署中的情况） - 主机本身运行 sensu-client “订阅”不同的可用支票。因此，当一个新服务器出现并说“我是一个网络服务器”时，运行在其上的 sensu-client 会询问 sensu-server “网络服务器应该在其自身上运行哪些检查？”并运行它们。
除此之外，Nagios（也称为 Icinga）和 Sensu 的运营方面都非常出色，并且具有许多用于检查、处理程序和通过仪表板 (YMMV) 进行可见性的设施。
【讨论】：
根据最近使用 Sensu 的一些经验和使用 Nagios 的相当多的经验，我认为两者都是很好的选择。
Sensu 绝对是新来的。它有一个漂亮的 UI 和漂亮的 API。但是，它确实需要在您的设置中使用 Redis 和 RabbitMQ 才能工作。因此，请考虑您是否需要在 sensu 监控堆栈之外监控这些依赖项。 Sonian 也提供 Chef 食谱供您尝试。
https://github.com/sensu/sensu-chef
Nagios 已经存在了很长时间。它通常为大多数发行版打包，这使得安装简单并且几乎没有依赖关系。它的跟踪记录还意味着找到知道或使用过它并可以提供建议的人很容易。另一方面，UI 很丑陋，而且程序化访问通常是 hacky 或通过第三方加载项。 Nagios 也有厨师食谱：
https://github.com/bryanwb/chef-nagios
如果您有时间，我会同时尝试这两种方法，将两个监控系统作为试用版运行并没有什么坏处。主要关注点，尤其是在动态 EC2 设置中，您的配置管理工具可以轻松地生成监控配置文件。
在其他工具方面，我个人会包括一些记录时间序列数据的东西，例如每秒请求数或随时间推移的负载。图表对监控有很大帮助，可用于通过 Nagios 或类似工具驱动警报。我个人是 Ganglia 和 Graphite 的粉丝，而 Librato Metrics (https://metrics.librato.com/) 是一个非常不错的非免费选项。
【讨论】：
我尝试使用 Nagios 有一段时间：我觉得它很常见的唯一原因是“其他人都使用它”，因为使用它绝对是可怕的。让它做任何新的东西都非常复杂、困难和冗长：如果你发现它不做的事情，你知道你会在一个古老的设计的糟糕文档中咒骂一个星期。在你所有的努力结束时，一切都在起作用，它看起来很可怕。放弃它让我睡得更好。
Cacti 看起来不错，但在创建新插件时又过于复杂了。
对于绘图，我推荐Munin：用任何语言编写新插件都是微不足道的，有数百个可用的插件，而且看起来很合理。它非常容易安装 - 一个命令来安装和设置一个访问规则，因此非常适合自动部署，易于包装到 a chef recipe。 2.0 即将推出并解决了它的大部分缺点（特别是添加了可变更新间隔、可缩放图表、ssh 传输）。 Munin 可以与 Nagios 对话以获取通知，也可以由它自己完成，它提供了一个基本的仪表板。
【讨论】：
与 Sensu 和 Nagios 相比...选择 Sensu 监控系统。
以下是主要原因，
1.Easy Setup..客户端重启的次数大大减少..这是大型企业的主要问题 2. Nagios 插件可以与 Sensu 生态系统一起使用。 3. 适用于云环境的可扩展性和轻松性。
有没有人听说过 Zabbix。它有很多功能并且作为一个单独的包提供。我怀疑可扩展性
【讨论】：
只要是企业级，它就由数据库、sap、网络设备、网络服务器、文件管理器、备份库组成......几乎没有 nagios 的替代品（或者它的表亲 icinga、shinken） 也许有一天一切都会自动从云中出来，但几年后仍会有静态服务器（物理或虚拟，没关系），其明确的目的至少会停留几个月。我们仍然需要监控接口带宽、表空间、业务流程、数据库会话、日志文件、jmx 指标。 nagios 世界的插件概念有优势的一切。
【讨论】：