如果你之前曾在云平台上工作过，你一定熟习这些系统的散布式和解耦性质。解耦的散布式系统依赖于微服务来履行特定的任务，每一个微服务都会暴露自己的REST(表示状态转移)API。这些微服务通常以诸如RabbitMQ或QPID等消息中间件的情势通太轻量级消息层相互通讯。
这正是OpenStack的工作原理。每一个主要的OpenStack组件(Keystone、Glance、Cinder、Neutron、Nova等)公然REST端点，组件和子组件通过消息中间件(如RabbitMQ)进行通讯。这类方法的优点首先是允许将故障分配给特定组件，其次是云基础设施运营商可以以水平方式扩大所有服务，并智能分配负载。
但是，这类散布式解耦系统虽然非常有益，但也带来了固有的挑战——如何正确监控OpenStack服务，更具体地说，如何辨认可能的单点故障。
下面的内容针对OpenStack服务监控的具体情况所面临的真实挑战，和每一个困难可能的解决方案。
挑战一：系统不是一个整体
OpenStack的非整体性和解耦性通常被强调为其主要优点。这固然是一个重要的优势。但是，这明显会使任何监控整体服务状态的尝试变得复杂。在每一个组件履行一个特定任务的散布式系统中，每一个组件进一步散布到多个子组件中，因此，不难理解当特定一部份软件产生故障时，肯定对服务的影响是多么困难。
克服这个困难的重要步是了解云。你需要肯定所有主要组件之间的关系，然后肯定每一个独立的特定服务之间的关系，它们的故障可能影响整体服务。简单地说，你需要知道云中所有组件之间的关系。
斟酌到这一点，你不但需要监视每一个单独组件的状态(正在运行或故障停止)，还要肯定其他服务如何遭到故障的影响。
例如，如果Keystone死机，没有人能够获得服务目录或登录任何服务，但这通常不会影响虚拟机或其他已建立的云服务(对象存储、块存储、负载均衡器等)，除非重新启动服务且Keystone依然宕机。但是，如果Apache失效，通过Apache工作的Keystone和其他类似的API服务可能会遭到影响。
因此，监控平台或解决方案不但需要能够评估各个服务的状态，而且还要能够在服务故障之间进行关联，以便检查对全部系统的真正影响，并相应地发送警报或通知。
挑战二：OpenStack不单单是OpenStack
基于OpenStack的云不但是散布式和解耦式系统，也是一种可在操作系统和其他在云基础设施中或与之相关的装备中创建资源的编排解决方案。这些资源包括虚拟机(Xen、KVM或其他管理程序软件组件)、持久卷(NFS存储服务器、Ceph群集、基于SAN的LVM卷或其他存储后端)、网络实体(端口，网桥，网络，路由器，负载平衡器，防火墙，VPN等)和临时磁盘(驻留在操作系统目录中的Qcow2文件)和许多其他小型系统。
因此，监测解决方案需要斟酌到这些基础组件。虽然这些资源可能不太复杂，并且不太容易出现故障，但是当它们停止运行时，主要OpenStack服务中的日志可能会掩盖真实的缘由。它们仅在遭到影响的OpenStack服务中显示结果，而不显示装备或失效的操作系统软件的实际根本缘由。
例如，如果libvirt失效，组件Nova将没法部署虚拟实例。 Nova-compute作为服务将被启动并运行，但在部署阶段实例将失败(实例状态：毛病)。为了检测这一点，你需要在nova-compute日志以外还监控libvirt(服务状态、指标及日志)。
因此，有必要检查底层软件和主要组件之间的关系，和监控终究的链接，并斟酌所有终究服务的一致性测试。你需要监控所有内容：存储、网络、hypervision层、每一个单独的组件和之间的关系。
挑战三：跳出固有思惟模式
Cacti、Nagios和Zabbix是OpenSource监控解决方案的好例子。这些解决方案定义了一组非常具体的度量标准，用于辨认操作系统上的可能问题，但是它们不提供肯定更复杂的故障情况或乃至服务状态所需的专门的指标。
这是你需要有创造性的地方。你可以实行专门的指标和测试，以定义服务是否是正常、降级或完全失败。
像OpenStack这样的散布式系统，其中每一个核心服务都暴露了一个REST API，并且连接到基于TCP的消息服务，容易遭到网络瓶颈、连接池耗尽和其他相关问题的影响。许多相关服务连接到基于SQL的数据库，这可能会耗尽其连接池，意味着需要在监控解决方案中实行正确的连接状态监控指标(建立、散布等待、关闭等)，以检测可能的、影响API的连接相关问题。另外，可以构建cli测试来检查端点状态并丈量其响应时间，这可以被转换成实际显示服务真实状态的指标。
上述每个监控解决方案和大多数其他商业或OpenSource解决方案可以通过自行设计专门指标来进行扩大。
命令“time OpenStack catalogue list”可以丈量Keystone API响应时间，评估结果，并在结果不符合预期时产生人工故障状态。另外，你可使用简单的操作系统工具，如“netstat”或“ss”，来监控API端点的区分连接状态，并了解服务中可能出现的问题。OpenStack云依赖关系的关键部份(例如消息代理和数据库服务)也能够这样做。请注意，消息中间件失败基本上将“杀死”OpenStack云。
关键是不要偷懒!不要只用默许的指标，而是应当用与自己服务相关的指标。
挑战四：人为因素
人为因素关乎一切。俗语说，抱怨工具的工匠不是一个好工匠。
没有经过测试的情形响应程序，单一故障不但本身是一个问题，还将带来造更多的问题。在你的监控解决方案中，云基础设施的任何事故及其相关警报中都应当有明确的记录，以清楚的步骤来解释如何检测、遏制和解决问题。
人为因素需要斟酌，即便你有一个可以关联事件和建议适当的解决方案来检测事故的、聪明的系统(一个有一定程度人工智能的系统)。请务必记住，如果系统不正确或不完全，那末输出也将不准确或不完全。
总结一下，OpenStack监控不一定很困难，最重要的是要完全。每一个单独的服务和与其他服务的互动都需要仔细监控。特殊指标乃至可以自己实现。通过一些TLC，你可以轻松地成功监控你的OpenStack。
