OpenStack监控方法

假如你之前曾在云服务平台上运行过，你一定了解这种体系的分布式系统和解耦特性。解耦的分布式架构取决于微服务来实行特殊的每日任务，每一个微服务都是会暴露的REST(表明状态迁移)API。这种微服务一般以例如RabbitMQ或QPID等消息中间件的方式根据轻量信息层互相通讯。　　这恰好是OpenStack的原理。每一个具体的OpenStack组件(Keystone，Glance，Cinder，Neutron，Nova等)公布REST节点，组件跟子组件根据消息中间件(如RabbitMQ)开展通讯。这类方式的优势最先是容许将常见故障分派给特殊组件，次之是云基础设施建设营运商能够以水准方法拓展全部服务，并智能化分派负荷。　　殊不知，这类分布式系统解耦系统软件尽管十分有益，但也提供了原有的探索——如何正确监控OpenStack服务，更具体地说，如何识别很有可能的服务器宕机。　　下边的信息对于OpenStack服务监控的情况所面对的真正挑戰，及其每一个难点很有可能的解决方案。　　挑戰一：系统软件并不是一个总体　　OpenStack的非全面性和解耦性一般被注重为其关键优势。这或许是一个至关重要的优点。殊不知，这显而易见会使一切监控总体服务状态的试着复杂化。在每一个组件实行一个特殊每日任务的分布式架构中，每一个组件进一步遍布到好几个子组件中，因而，不难理解当特殊一部分手机软件产生问题时，明确对服务的直接影响是多么的艰难。摆脱这一难题的主要步是掌握云。你需要明确全部关键组件中间的关联，随后判断每一个单独的特殊服务中间的关联，他们的常见故障很有可能会影响总体服务。简易地说，你需要了解云间全部组件中间的关联。　　充分考虑这一点，你不但必须监控每一个独立组件的状态(已经运作或常见故障终止)，还需要明确别的服务怎样遭受常见故障的危害。比如，假如Keystone卡死，没人可以获得服务文件目录或登陆一切服务，但这一般并不会危害vm虚拟机或别的已创建的云服务(阿里云oss，块存储，负载均衡设备等)，除非是重启服务且Keystone依然服务器宕机。殊不知，假如Apache无效，根据Apache工作中的Keystone和别的相近的API服务很有可能会遭受危害。　　因而，监控服务平台或解决方案不但必须可以评定每个服务的状态，并且还需要能在服务常见故障中间开展关系，便于查验对所有体系的真实危害，并相对地推送报警或通告。　　挑戰二：OpenStack不仅是OpenStack　　根据OpenStack的云不但是分布式系统和解耦式系统软件，也是一种可在电脑操作系统和别的在云基础设施建设中或与之关联的机器设备中建立資源的编辑解决方案。这种資源包含vm虚拟机(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。

转载于天翼云知识，如有侵权，请联系删除，谢谢