上述每一个监控解决方案和大多数其他商业或OpenSource解决方案可以通过自行设计专门指标来进行扩展。
命令“time OpenStack catalogue list”可以测量Keystone API响应时间，评估结果，并在结果不符合预期时产生人工故障状态。此外，你可以使用简单的操作系统工具，如“netstat”或“ss”，来监控API端点的不同连接状态，并了解服务中可能出现的问题。OpenStack云依赖关系的关键部分（例如消息代理和数据库服务）也可以这样做。请注意，消息中间件失败基本上将“杀死”OpenStack云。
关键是不要偷懒！不要只用默认的指标，而是应该用与自己服务相关的指标。
挑战四：人为因素
人为因素关乎一切。俗话说，埋怨工具的工匠不是一个好工匠。
没有经过测试的情景响应程序，单一故障不仅本身是一个问题，还将带来造更多的问题。在你的监控解决方案中，云基础设施的任何事故及其相关警报中都应该有明确的记录，以清楚的步骤来解释如何检测、遏制和解决问题。
人为因素必须考虑，即使你有一个可以关联事件和建议适当的解决方案来检测事故的、聪明的系统（一个有一定程度人工智能的系统）。请务必记住，如果系统不正确或不完整，那么输出也将不准确或不完整。
总结一下，OpenStack监控不一定很困难，最重要的是要彻底。每个单独的服务以及与其他服务的互动都需要仔细监控。特殊指标甚至可以自己实现。通过一些TLC，你可以轻松地成功监控你的OpenStack。