[ English | 日本語 | Deutsch | Indonesia ]
监控¶
有两种类型的监控：监视问题和监视使用趋势。前者确保所有服务都已启动并运行，从而创建一个功能完善的云。后者涉及随着时间的推移监控资源使用情况，以便就潜在的瓶颈和升级做出明智的决策。
进程监控¶
一种基本的警报监控类型是简单地检查所需的进程是否正在运行。例如，确保云控制器上正在运行 nova-api 服务
# ps aux | grep nova-api
nova 12786 0.0 0.0 37952 1312 ? Ss Feb11 0:00 su -s /bin/sh -c exec nova-api
--config-file=/etc/nova/nova.conf nova
nova 12787 0.0 0.1 135764 57400 ? S Feb11 0:01 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12792 0.0 0.0 96052 22856 ? S Feb11 0:01 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12793 0.0 0.3 290688 115516 ? S Feb11 1:23 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12794 0.0 0.2 248636 77068 ? S Feb11 0:04 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
root 24121 0.0 0.0 11688 912 pts/5 S+ 13:07 0:00 grep nova-api
应监控的 OpenStack 进程取决于环境的具体配置，但可以包括
计算服务 (nova)
nova-api
nova-scheduler
nova-conductor
nova-novncproxy
nova-compute
块存储服务 (cinder)
cinder-volume
cinder-api
cinder-scheduler
网络服务 (neutron)
neutron-server
neutron-openvswitch-agent
neutron-dhcp-agent
neutron-l3-agent
neutron-metadata-agent
镜像服务 (glance)
glance-api
glance-registry
身份验证服务 (keystone)
keystone 进程在 Apache 中作为 WSGI 应用程序运行。
资源警报¶
资源警报在一种或多种资源严重不足时提供通知。虽然应将监控阈值调整到您的特定 OpenStack 环境，但监控资源使用情况与 OpenStack 没有任何特定关系——任何通用的警报类型都可以正常工作。
您想要监控的一些资源包括
磁盘使用情况
服务器负载
内存使用情况
网络 I/O
可用 vCPU
遥测服务¶
遥测服务 (ceilometer) 收集与 OpenStack 服务相关的计量和事件数据。遥测服务收集的数据可用于计费。根据部署配置，收集的数据可能可供基于部署配置的用户访问。您可以在 Ceilometer 管理员指南 或 Ceilometer 贡献者指南 中了解有关该模块的更多信息。
OpenStack 特定资源¶
内存、磁盘和 CPU 等资源是所有服务器（甚至非 OpenStack 服务器）都具有的通用资源，对服务器的整体健康状况非常重要。具体来说，在使用 OpenStack 时，这些资源很重要，原因在于：确保有足够的资源来启动实例。您可以通过 openstack 命令查看 OpenStack 资源使用情况
# openstack usage list
此命令显示租户正在运行的实例列表以及有关组合实例的一些轻量级使用统计信息。此命令对于快速概述您的云非常有用，但它并没有深入到很多细节。
接下来，nova 数据库包含三个表，用于存储使用信息。
nova.quotas 和 nova.quota_usages 表格存储配额信息。如果租户的配额与默认配额设置不同，则其配额存储在 nova.quotas 表中。例如
mysql> select project_id, resource, hard_limit from quotas;
+----------------------------------+-----------------------------+------------+
| project_id | resource | hard_limit |
+----------------------------------+-----------------------------+------------+
| 628df59f091142399e0689a2696f5baa | metadata_items | 128 |
| 628df59f091142399e0689a2696f5baa | injected_file_content_bytes | 10240 |
| 628df59f091142399e0689a2696f5baa | injected_files | 5 |
| 628df59f091142399e0689a2696f5baa | gigabytes | 1000 |
| 628df59f091142399e0689a2696f5baa | ram | 51200 |
| 628df59f091142399e0689a2696f5baa | floating_ips | 10 |
| 628df59f091142399e0689a2696f5baa | instances | 10 |
| 628df59f091142399e0689a2696f5baa | volumes | 10 |
| 628df59f091142399e0689a2696f5baa | cores | 20 |
+----------------------------------+-----------------------------+------------+
nova.quota_usages 表跟踪租户当前正在使用的资源数量
mysql> select project_id, resource, in_use from quota_usages where project_id like '628%';
+----------------------------------+--------------+--------+
| project_id | resource | in_use |
+----------------------------------+--------------+--------+
| 628df59f091142399e0689a2696f5baa | instances | 1 |
| 628df59f091142399e0689a2696f5baa | ram | 512 |
| 628df59f091142399e0689a2696f5baa | cores | 1 |
| 628df59f091142399e0689a2696f5baa | floating_ips | 1 |
| 628df59f091142399e0689a2696f5baa | volumes | 2 |
| 628df59f091142399e0689a2696f5baa | gigabytes | 12 |
| 628df59f091142399e0689a2696f5baa | images | 1 |
+----------------------------------+--------------+--------+
通过将租户的硬限制与其当前资源使用情况进行比较，您可以查看其使用百分比。例如，如果此租户正在使用 1 个浮动 IP，而总共有 10 个，那么他们正在使用 10% 的浮动 IP 配额。与其手动进行计算，您可以使用 SQL 或您选择的脚本语言并创建一个格式化的报告
+----------------------------------+------------+-------------+---------------+
| some_tenant |
+-----------------------------------+------------+------------+---------------+
| Resource | Used | Limit | |
+-----------------------------------+------------+------------+---------------+
| cores | 1 | 20 | 5 % |
| floating_ips | 1 | 10 | 10 % |
| gigabytes | 12 | 1000 | 1 % |
| images | 1 | 4 | 25 % |
| injected_file_content_bytes | 0 | 10240 | 0 % |
| injected_file_path_bytes | 0 | 255 | 0 % |
| injected_files | 0 | 5 | 0 % |
| instances | 1 | 10 | 10 % |
| key_pairs | 0 | 100 | 0 % |
| metadata_items | 0 | 128 | 0 % |
| ram | 512 | 51200 | 1 % |
| reservation_expire | 0 | 86400 | 0 % |
| security_group_rules | 0 | 20 | 0 % |
| security_groups | 0 | 10 | 0 % |
| volumes | 2 | 10 | 20 % |
+-----------------------------------+------------+------------+---------------+
前述信息是由一个自定义脚本生成的，该脚本可以在 GitHub 上找到。
注意
此脚本特定于某个 OpenStack 安装，必须进行修改才能适应您的环境。但是，逻辑应该易于转移。
智能警报¶
智能警报可以被认为是运维的持续集成的一种形式。例如，您可以很容易地通过确保 glance-api 和 glance-registry 进程正在运行，或者查看 glance-api 是否正在监听 9292 端口来检查镜像服务是否已启动并正在运行。
但是，您如何确定镜像是否已成功上传到镜像服务？也许镜像服务正在存储镜像的磁盘已满，或者 S3 后端已关闭。您可以自然地通过快速上传镜像来检查这一点
#!/bin/bash
#
# assumes that reasonable credentials have been stored at
# /root/auth
. /root/openrc
wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
openstack image create --name='cirros image' --public \
--container-format=bare --disk-format=qcow2 \
--file cirros-0.3.5-x86_64-disk.img
通过将此脚本整合到您的监控系统（例如 Nagios）的警报中，您现在拥有了一种自动化的方法来确保镜像上传到镜像目录正在工作。
注意
您必须在每次测试后删除该镜像。更好的是，测试您是否可以成功从镜像服务中删除镜像。
实施智能警报需要比本章中描述的其他警报花费更多的时间进行计划和实施。实施智能警报的一个良好大纲是
审查云中的常见操作。
创建自动测试这些操作的方法。
将这些测试整合到警报系统中。
智能警报的一些其他示例包括
是否可以启动和销毁实例？
是否可以创建用户？
是否可以存储和删除对象？
是否可以创建和销毁卷？
趋势¶
趋势可以为您提供有关您的云每天表现如何的绝佳见解。例如，您可以了解到繁忙的一天仅仅是一个罕见的事件，或者您应该开始添加新的计算节点。
趋势采用与警报略有不同的方法。虽然警报关注二进制结果（检查是成功还是失败），但趋势会记录在某个特定时间点的当前状态。记录足够多的时间点后，您可以查看该值随时间的变化情况。
前面提到的所有警报类型也可以用于趋势报告。其他一些趋势示例包括
每个计算节点上的实例数量
正在使用的风味类型
正在使用的卷数量
每小时的对象存储请求数量
每小时的
nova-api请求数量您的存储服务的 I/O 统计信息
例如，记录 nova-api 使用情况可以帮助您跟踪云控制器的扩展需求。通过关注 nova-api 请求，您可以确定是否需要生成更多的 nova-api 进程，或者更进一步，引入一个全新的服务器来运行 nova-api。要获得近似的请求计数，请在 /var/log/nova/nova-api.log 中查找标准 INFO 消息
# grep INFO /var/log/nova/nova-api.log | wc
您可以获得进一步的统计信息，方法是查找成功请求的数量
# grep " 200 " /var/log/nova/nova-api.log | wc
通过定期运行此命令并记录结果，您可以创建一个随时间变化的趋势报告，显示您的 nova-api 使用情况是增加、减少还是保持稳定。
可以使用诸如 collectd 之类的工具来存储此信息。虽然 collectd 超出了本书的范围，但一个好的起点将是使用 collectd 将结果存储为 COUNTER 数据类型。有关更多信息，请参阅 collectd 的文档。
监控工具¶
Nagios¶
Nagios 是一种开源监控服务。它能够执行任意命令来检查服务器和网络服务的状态，直接在服务器上远程执行任意命令，并允许服务器以被动监控的形式发送通知。Nagios 自 1999 年以来一直存在。虽然有更新的监控服务可用，但 Nagios 仍然是经过实践检验的系统管理支柱。
您可以使用 Nagios 和 NRPE 创建关键进程的自动化警报。例如，要确保计算节点上的 nova-compute 进程正在运行，请在 Nagios 服务器上创建一个警报
define service {
host_name c01.example.com
check_command check_nrpe_1arg!check_nova-compute
use generic-service
notification_period 24x7
contact_groups sysadmins
service_description nova-compute
}
在计算节点上，创建以下 NRPE 配置
command[check_nova-compute]=/usr/lib/nagios/plugins/check_procs -c 1: -a nova-compute
Nagios 检查是否始终正在运行至少一个 nova-compute 服务。
对于资源警报，例如，使用 Nagios 监控计算节点上的磁盘容量，将以下内容添加到您的 Nagios 配置
define service {
host_name c01.example.com
check_command check_nrpe!check_all_disks!20% 10%
use generic-service
contact_groups sysadmins
service_description Disk
}
在计算节点上，将以下内容添加到您的 NRPE 配置
command[check_all_disks]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -e
Nagios 在计算节点上的任何磁盘满 80% 时发出 WARNING 警报，并在满 90% 时发出 CRITICAL 警报。
StackTach¶
StackTach 是一种收集和报告 nova 发送的通知的工具。通知本质上与日志相同，但可以更加详细。几乎所有 OpenStack 组件都能够在发生重大事件时生成通知。通知是放置在 OpenStack 队列（通常是 RabbitMQ）上的消息，供下游系统使用。可以在 系统使用数据 中找到有关通知的概述。
要启用 nova 发送通知，请将以下内容添加到 nova.conf 配置文件
notification_topics=monitor
notification_driver=messagingv2
一旦 nova 正在发送通知，请安装并配置 StackTach。StackTach 适用于队列消耗和管道处理，配置为从 RabbitMQ 服务器读取这些通知并将它们存储在数据库中。用户可以使用浏览器界面或命令行工具 Stacky 查询实例、请求和服务器。由于 StackTach 相对较新且不断变化，因此安装说明很快就会过时。请参阅 StackTach Git 仓库 以获取说明以及演示视频。可以在 官方页面 上发现有关最新开发的更多详细信息
Logstash¶
Logstash 是一种高性能的日志索引和搜索引擎。Jenkins 测试运行的日志被发送到 logstash，在那里被索引和存储。Logstash 促进了在单个测试运行中查看来自多个来源的日志，搜索测试运行中的错误或特定事件，以及搜索跨测试运行的日志事件趋势。
Logstash 设置中有四个主要层，分别是
日志推送器
日志索引器
ElasticSearch
Kibana
每一层都可以水平扩展。随着日志数量的增长，您可以添加更多的日志推送器、更多的 Logstash 索引器和更多的 ElasticSearch 节点。
Logpusher 是一对 Python 脚本，首先监听 Jenkins 构建事件，然后将它们转换为 Gearman 作业。Gearman 提供了一个通用的应用程序框架，用于将工作分配给其他机器或更适合执行该工作的进程。它允许您并行工作、负载均衡处理以及在语言之间调用函数。稍后，Logpusher 执行 Gearman 作业，将日志文件推送到 logstash。Logstash 索引器读取这些日志事件，过滤掉不需要的行，将多个事件合并在一起，并解析有用的信息，然后将其发送到 ElasticSearch 进行存储和索引。Kibana 是一个面向 logstash 的 Web 客户端，用于 ElasticSearch。
