|
近年来越来越多的厂商和机构利用 OpenStack 搭建 IaaS 层等基础架构方面的云服务，从而使得
OpenStack 的发展获得了巨大的推动。
但对于这样一个庞大的架构，能够让其稳定而又高效的运转起来也不是一件易事，因此如何实现一个强大、健全、可扩展的
OpenStack 监控系统 也成为当下很多人关注 OpenStack 时所要考虑的重要部分。
与此同时随着 OpenStack 上节点数目和所需监控对象的数量的增加，监控系统也俨然成为一个云平台非常重要的特性，也是评估一个
OpenStack 的可运维程度的参考。
首先我们先来了解下到底什么是 OpenStack 以及其相关构成。
什么是 OpenStack
OpenStack 是一个美国国家航空航天局和 Rackspace 合作研发的 IaaS 软件，让任何人都可以自行建立和提供云端运算服务。此外，OpenStack
也用作建立防火墙内的私有云，提供机构或企业内各部门共享资源。
简单来说，OpenStack 就是一个提供私有化部署的 Amazon Web Services。经历 5
年的蓬勃发展，加入 OpenStack 阵营的已经包括 Google、惠普、IBM 和 Intel。
对于 OpenStack 来说，其计算模块 Nova 是整个系统中重要的组成部分
OpenStack 模块构成
既然提到 Nova ，那么就有必要说说 OpenStack 的模块构成。OpenStack
由以下6个重要模块构成：
1.Nova - 计算服务
2.Keysyone - 认证服务
3.Glance - 镜像服务
4.Neutron - 虚拟网络服务
5.Cinder - 存储服务
6.Horizon - UI 组件
总的来说，OpenStack 就像 AWS 提供虚拟计算单元 EC2，虚拟存储
S3，虚拟网段 VPC等。而这些相互独立的模块组成了一套完整的云计算服务平台；如果加上面向对象的存储 Swfit，资源监控
Ceilometer 和云系统部署 Heat，那么这个云计算服务平台会更加完整。
下面我们来介绍与 OpenStack 监控关系最紧密的 3 个模块：Nova、Keystone 和 Neutron，方便大家更好地理解和搭建
OpenStack 监控系统。
Nova
Nova 功能及特点：
1.实例生命周期管理
2.计算资源管理
3.网络与授权管理
4.基于 REST 的 API
5.异步连续通信
6.支持各种宿主：Xen、XenServer/XCP、KVM、UML、VMware
vSphere 及 Hyper-V
基于 Nova 的功能，在进行 OpenStack 监控时可以关注以下数据：
1.openstack.nova.current_workload：当前
Nova 的 Workload，包括 build, snapshot, migration, resize
各种动作的负载。
2.openstack.nova.running_vms：当前 Nova
在运行的虚拟机和实例（instance）的数量。
3.openstack.nova.hypervisor_load.1:hypervisor
相关指标；除了一分钟内系统负载外，还包括 disk, ram, cpu 等相关指标。
4.openstack.nova.limits.max_personality：和
project 和租户相关的指标；包括除 personality 外的 image, security
相关指标。
OpenStack 内部在遵循 AMQP（高级消息队列协议）的基础上，基于
Rabbit MQ 作为其消息队列进行通信。Nova 对请求应答进行异步调用，当请求接收后便则立即触发一个回调。由于使用了异步通信，不会有用户的动作被长置于等待状态。例如，启动一个实例或上传一份镜像的过程较为耗时，API调用就将等待返回结果而不影响其它操作，在此异步通信起到了很大作用，使整个系统变得更加高效。
Neutron & Keystone
Neutron 为 OpenStack提供虚拟网络管理服务，来使得网络配置更为简单。
Keystone 为所有的 OpenStack组件提供认证和访问策略服务，它依赖自身 REST（基于 Identity
API）系统进行工作，主要对（但不限于）Swift、Glance、Nova 等进行认证与授权。事实上，授权通过对动作消息来源者请求的合法性进行鉴定。
这些 OpenStack 指标值得关注
OpenStack 复杂程度让 Gartner 在面对企业咨询 OpenStack 搭建私有云时，会询问
3 个问题：
1.你的业务需要搭建在一个 IaaS 私有云平台上吗?
2.你有技术和资源来支持这么复杂的项目吗?
3.像 OpenStack 这样的开源框架合适你的工作环境吗?
可见 OpenStack 并不是一个很容易上手的工程。好在国内出现了 OpenStack
中国社区，和 Cloudinsight这样的组织，帮助企业和开发者更好地使用 OpenStack。
为了帮助您更好地监控OpenStack，以下通过相关提取出的指标和图例，告诉您哪些指标值得关注，从而快速上手
OpenStack 监控。
如上文所述，对于 OpenStack 来说以下几类指标的监控是需要关注的：
1.Hypervisor 指标 - 运行的虚拟机数量，hypervisor
自身负载等；
2.Nova Server 指标 - 磁盘的读写速率，RAM 相关指标等；
3.Tenant 指标 - 资源使用情况，CPU 核数等；
4.Message Queue 指标 - MQ 的大小等
Nova 以管理平台的身份登场，负责管理整个云的计算资源、网络、授权及测度。它原生支持 KVM, QEMU
宿主，也提供 Xen, VMware vSphere 及 Hyper-V 的支持。Nova 兼容 AWS
的 EC2 和 S3 API，就像 AWS 通过 Nova 我们可以方便地移植应用，减少应用的部署时间。
Nova 指标就包括了 Hypervisor, Nova Server, Tenant 指标。通过 Hypervisor
指标可以了解到系统的整体运行情况和负载，而 Nova Server 指标可以了解某个虚拟机的运行情况，Tenant
指标则是可以查看相关租户的资源使用情况。
Hypervisor 指标
为了方便更加方便理解，在此我们提取了以下 7 个指标，来查看 Hypervisor 的性能。由上图可知，Hypervisor
主导 Nova 模块中与计算相关的部分。
hypervisor_load - 该指标表征系统负载，有点类似操作系统的system.load.1
指标，标识过去 1 分钟内系统负载。如果系统负载上升，一般来说相关的虚拟机的指标也会上升，此时需要针对性能进行优化。
current_workload - 一般来说，hypervisor 任务包括：build, snapshot,
migrate, resize；该指标显示当前任务数量，由于 hypervisor 和虚拟机共用 IO
资源，若当前任务任务数量过高，一般来说会导致 IO 瓶颈问题。
running_vms - 当前运行的虚拟机数量。通过数据聚合功能，您可以了解整个平台的虚拟机数量，加上系统负载和任务数量，您可以了解到
OpenStack 整体的运行情况。
vcpus_available- 当前 CPU 使用情况在生产环境下一般是保持不变的。您可以通过设置该指标的报警，来监控该指标的变化，从而预测异常。而在开发环境中，该指标无显著的监控意义。越高的
CPU 数量代表您有越多的资源提供给用于计算的主机，若该指标出现陡然降低的情况，那代表您需要增设机器了。
free_disk_gb - 磁盘的空闲情况，直接影响是否可以新建虚拟机。关注该指标可以了解到何时需要对占用磁盘空间较大的实例进行迁移。
free_ram_mb - 和磁盘的空闲情况相似，RAM 的空闲情况也是一个非常值得关注的情况，属于关键资源。
Nova Server 指标
关注 Nova Server 指标可以了解主要节点的信息，如每个节点向 Nova 发送请求的数量，从而预测是否存在
Noisy Neighbor Problem。
若想要了解每个实例（虚拟机）的具体指标，如 CPU 利用率、内存、网络等指标，您可以使用
Cloudinsight 或 Zabbix 类的监控工具将其 Agent 安装至每个虚拟机内部。通过标签来进行数据聚合和分组，可以达到更专业化的监控程度。
hdd_read_req - 在虚拟环境中，每个进程的 RAM 使用量是十分有限的。查看 HDD 的读请求数量，就意味着监控
Nova 节点的虚拟机的基本性能。举例来说，若该指标出现峰值，就意味着虚拟机的 RAM 太小了，从而导致较小的分页，继而使得对
HDD 的读请求数量激增。此时您就需要对 Nova 集群进行性能排查啦。
Tenant 指标
Tenant 这个概念在一年前被讨论得蛮火的，特别是国内 SaaS 厂商兴起了以后。租户简单来说，就是一组用户啦。给不同组的用户分配不一样的资源，可以达到资源的合理分配，从而达到利益的最大化。
监控租户相关指标，也就意味着在监控与业务相关的指标。
total_cores_used & max_total_cores - Core 作为重要的资源，了解其使用情况，来辅助决策是否需要在激增的情况下，多分配资源；是否需要在持续较低使用率的情况下，减少资源分配。
total_instances_used & max_total_instances - Instance
数量也就是虚拟机数量，和 core 一样是重要的资源。监控租户的当前使用量，和最大分配量，可以帮助决策是否需要为该租户增添资源。
RabbitMQ指标
RabbitMQ指标又是什么呢？正如上文所说，OpenStack 内部在遵循 AMQP（高级消息队列协议）的基础上，基于
Rabbit MQ 作为其消息队列进行通信。
也就是说，监控 RabbitMQ 指标意味着监控 OpenStack 环境的整体情况，毕竟通讯与中断还是蛮重要的一件事情的啦。
consumer_utilisation - 理想情况下，该指标保持在 100% 数值下是最好的，这意味着每个队列都可以及时地处理新消息。网络拥堵和
Comsumer Prefetch 都会降低该指标的数值。SO SAD！
memory - 和大多数 MQ 一样，RabbitMQ 会在内存不够用的情况下调用磁盘。加上磁盘分页而导致的吞吐量增加，很容易使得内存使用量超过系统
RAM 的 40%（默认值），RabbitMQ 会优先对消息生产者进行节流。Duang！性能问题就产生了。
count - 建议为该指标设置指标报警策略，当数值为 0 时，触发报警。毕竟有效队列的数量是 0，那是相当可怕的事情呢。
consumers - 和 count 一样，设置个报警比较好。该指标为 0 是一件犹如伏地魔重生的事情。若您不幸遇到该情况，我们推荐以下两种方式：Aliveness
Testing 和StackTach 工具。
|
