如不雅你以前曾在云平台上工作过，你必定熟悉这些体系的分布式和解耦性质。解耦的分布式体系依附于微办事来履行特定的义务，每个微办事都邑裸露本身的REST(表示状况转移)API。这些微办事平日以诸如RabbitMQ或QPID等消息中心件的情势经由过程轻量级消息层互相通信。

然而，这种分布式解耦体系固然异常有利，但也带来了固有的挑衅——若何精确监控OpenStack办事，更具体地说，若何辨认可能的单点故障。

挑衅一：体系不是一个整体

OpenStack的非整体性和解耦性平日被强调为其重要长处。这当然是一个重要的优势。然而，这显然会使任何监控整体办事状况的测验测验变得复杂。在每个组件履行一个特定义务的分布式体系中，每个组件进一步分布到多个子组件中，是以，不难解得当特定一部分软件产生故障时，肯定对办事的影响是多么艰苦。

克服这个艰苦的第一步是懂得云。你须要肯定所有重要组件之间的关系，然后肯定每个自力的特定办事之间的关系，它们的故障可能影响整体办事。简单地说，你须要知道云中所有组件之间的关系。

推敲到这一点，你不仅须要监督每个零丁组件的状况(正在运行或故障停止)，还要肯定其他办事若何受到故障的影响。

这恰是OpenStack的工作道理。每个重要的OpenStack组件(Keystone、Glance、Cinder、Neutron、Nova等)公开REST端点，组件和子组件经由过程消息中心件(如RabbitMQ)进行通信。这种办法的长处起首是许可将故障分派给特定组件，其次是云基本举措措施运营商可以以程度方法扩大所有办事，并智能分派负载。

Cacti、Nagios和Zabbix是OpenSource监控解决筹划的好例子。这些解决筹划定义了一组异常具体的度量标准，用于辨认操作体系上的可能问题，然则它们不供给肯定更复杂的故障情况或甚至办事状况所需的专门的指标。

例如，如不雅Keystone逝世机，没有人可以或许获取办事目次或登录任何办事，但这平日不会影响虚拟机或其他已建立的云办事(对象存储、块存储、负载均衡器等)，除非从新启动办事且Keystone仍然宕机。然而，如不雅Apache掉效，经由过程Apache工作的Keystone和其他类似的API办事可能会受到影响。

是以，监控平台或解决筹划不仅必须可以或许评估各个办事的状况，并且还要可以或许在办变乱障之间进行接洽关系，以便检核半数个体系的┞锋正影响，并响应地发送戒备或通知。

挑衅二：OpenStack不仅仅是OpenStack

下面的内容针对OpenStack办事监控的具体情况所面对的┞锋实挑衅，以及每个难题可能的解决筹划。

基于OpenStack的云不仅是分布式和解耦式体系，也是一种可在操作体系和其他在云基本举措措施中或与之相干的设备中创建资本的编排遣决筹划。这些资本包含虚拟机(Xen、KVM或其他治理法度榜样软件组件)、持久卷(NFS存储办事器、Ceph群集、基于SAN的LVM卷或其他存储后端)、收集实体(端口，网桥，收集，路由器，负载均衡器，防火墙，VPN等)和临时磁盘(驻留在操作体系目次中的Qcow2文件)以及很多其他小型体系。

是以，监测解决筹划必须推敲到这些基本组件。固然这些资本可能不太复杂，并且不太轻易出现故障，然则当它们停止运行时，重要OpenStack办事中的日记可能会掩盖真实的原因。它们仅在受到影响的OpenStack办事中显示结不雅，而不显示设备或掉效的操作体系软件的实际根来源基本因。

例如，如不雅libvirt掉效，组件Nova将无法安排虚拟实例。 Nova-compute作为办事将被启动并运行，但在安排阶段实例将掉败(实例状况：缺点)。为了检测这一点，你须要在nova-compute日记之外还监控libvirt(办事状况、指标及日记)。

是以，有须要检查底层软件和重要组件之间的关系，以及监控最终的链接，并推敲所有最终办事的一致性测试。你须要监控所有内容：存储、收集、hypervision层、每个零丁的组件以及之间的关系。

这是你须要有创造性的处所。你可以实施专门的指标和测试，以定义办事是否正常、降级或完全掉败。

挑衅三：彪炳固有思维模式

像OpenStack如许的分布式体系，个中每个核心办事都裸露了一个REST API，并且连接到基于TCP的消息办事，轻易受到收集瓶颈、连接池耗尽和其他相干问题的影响。很多相干办事连接到基于SQL的数据库，这可能会耗尽其最大年夜连接池，意味着须要在监控解决筹划中实施精确的连接状况监控指标(建立、分布等待、封闭等)，以检测可能的、影响API的连接相干问题。此外，可以构建cli测试来检查督馐痛态并测量其响应时光，这可以被转换成实际显示办事真实状况的指标。

上述每一个监控解决筹划和大年夜多半其他贸易或OpenSource解决筹划可以经由过程自行设计专门指标来进行扩大。

敕令“time OpenStack catalogue list”可以测量Keystone API响应时光，评估结不雅，并在结不雅不相符预期时产生人工故障状况。此外，你可以应用简单的操作体系对象，如“netstat”或“ss”，来监控API端点的不合连接状况，并懂得办事中可能出现的问题。OpenStack云依附关系的关键部分(例如消息代劳和数据库办事)也可以如许做。请留意，消息中心件掉败根本大将“杀逝世”OpenStack云。

关键是不要偷懒!不要只用默认的指标，而是应当用与本身办事相干的指标。

挑衅四良士为身分

工资身分关乎一切。俗话说，抱怨对象的工匠不是一个好工匠。

没有经由测试的情景响应法度榜样，单一故障不仅本身是一个问题，还将带来造更多的问题。在你的监控解决筹划中，云基本举措措施的任何变乱及其相干戒备中都应当有明白的记录，以清跋扈的步调来解释若何检测、遏制和解决问题。

工资身分必须推敲，即使你有一个可以接洽关系事宜和建议恰当的解决筹划来检测变乱的、聪慧的体系(一个有必定程度人工智能的体系)。请务必记住，如不雅体系不精确或不完全，那么输出也将不精确或不完全。

　　推荐阅读

　　WPSeku：一个找出WordPress安全问题的漏洞扫描器

WordPress 是一个免费开源、可高度自定义的内容治理体系(CMS)，它被全世界数以百万计的仁攀来运行博客和完全的网站。因为它是被用的最多的 CMS，是以有很多潜在的 WordPress 安然问题/马脚须要推敲。然而，如不雅我>>>详细阅读

本文标题：监控OpenStack的技巧

地址：http://www.17bianji.com/lsqh/35526.html

 1/2    1