7种AI方法可以为你的OpenStack监控提供帮助

云行业正在迅速变化，许多公司正在转向虚拟专用网络（VPN）。由于软件应用程序（如OpenStack），云存储和计算能力的管理变得更加容易。OpenStack是最好的软件之一，帮助数据中心所有者立即部署虚拟机，并通过仪表板或OpenStack API（应用程序编程接口）监视日志。好的优势是，OpenStack可以让数字业务轻松创建，评估和控制他们的计算环境。然而，在处理OpenStack环境中生成的大量日志数据的同时，不断需要做出关键决定仍然是一个严峻的挑战。

OpenStack的挑战

世界各地的数千家企业由于其丰富的生态系统，低运营成本和灵活性来缩短上市时间，因此使用OpenStack。然而，用户在部署此技术时遇到重大挑战，特别是在识别和监控资源方面。下面，我们将重点介绍OpenStack监控工具和解决方案所面临的挑战，使OpenStack成为云计算和虚拟机集成的简单解决方案。

 

 

动态环境

大多数OpenStack服务是完全静态的。云计算环境非常灵活，因为它可以根据部署的服务和应用程序的数量增长和缩小。因此，在动态环境中生成静态日志会限制IT经理对其环境中发生的情况进行非完整的概述。

 

为了刷新统计数据，需要人为干预。在即将部署容器和虚拟机的环境中，人为干预需要时间。运行几个月或几年不重新启动的机器的传统环境中，这些挑战的严重程度更大。在这种情况下，必须有一个有能力的团队，需要不断监控新的日志数据。当然，这可能相当麻烦，有时候，数据中心可能缺乏资源或足够的人力。

 

解

为了解决动态虚拟机环境的问题，AI供电的监控解决方案将是最好的方式。人工智能专注于实时监控所有OpenStack组件。此外，任何可能对整个环境产生重大影响的服务都将自动赋予最高优先级。最后，IT专家将立即了解每个微型服务中发生的情况，包括专有软件应用程序以及存储，网络，计算和数据计划组件的日志。通过对数据记录的即时深刻洞察，解决任何问题都是轻而易举的，因为所有微服务的简单性和连接性。

 

 

传统混合

大多数组织仍然在云服务之上运行旧的计算基础设施，这并不奇怪。事实上，超过75％的使用OpenStack部署的组织尚未放弃其他组织的遗留应用程序或平台。这些包括Google和Amazon云服务。利用传统的组合，OpenStack使用的开源监控工具可能无法更好地完全生成足够的日志来监视混合环境。这迫使公司使用多种监控工具，并且仍然是IT经理的头痛，同时仍增加了组织的开销。

 

解

数据中心渴望在完整的虚拟机部署中来自不同节点的混合和精心呈现的数据日志。AI监控工具可以评估和呈现来自不同部署的数据，特别是如果它们具有API。最终，通过AI产生的见解来跟踪网络中的问题变得直截了当，基本上毫不费力。AI可以帮助IT经理立即查看不同指标之间的关系并对其进行评估，以便了解哪些组件在出现错误时会导致问题。

 

 

OpenStack的分布式和去耦性质

OpenStack的环境破坏微服务，旨在完成许多不同的任务。然而，每个任务使用REST（表示状态转移）API来公开其最终结果。OpenStack的微型组件相互通信，以实现使用消息传递层传送（伟大）虚拟机的共同目标。这种方法的问题是将故障隔离到整个基础设施。

当单个微服务发生错误时，监控和识别正在停止整个平台的服务可能是棘手的，这可能会使整个机器部分或完全停止，使整个服务脱机。您可以想象整个Web应用程序由于单个微型组件不能轻易识别而失败？非常惊人，至少说。不是吗

 

解

非单一服务使得IT管理人员难以在单个微组件发生故障时评估对整个计算环境的真正影响。为了解决这个不确定性，需要了解云计算基础架构的工作原理。您将需要大量投资，并学习组成您可能的不同组件的所有功能。其次，您需要确定不同组件之间的关系。最后，您必须深入了解直接影响特定云服务的所有服务。考虑到这一点，您不仅可以理解由于非功能性微组件而导致某些组件出现故障的原因，而且还可以对可能受过程影响的其他服务获得有意义的见解。因此，

 

 

 

 

不同的结构和文件夹

OpenStack Cloud管理设置依赖于传统的监控工具，这些工具有很多问题，列出其中的一个。已知的“黑匣子”问题：最终用户只看到输入和输出，但不是进程。在现实世界中，OpenStack的部署是在不同的地理位置和结构中进行的。这意味着许多组件，如托管，云服务和网络提供商都参与到该过程中。另一方面，安装了不同的软件应用程序，并且每个软件都需要跟踪，以确保云服务流畅。通过这种多样化的结构和应用，为OpenStack绘制有意义的洞察力对于IT经理来说是非常具有挑战性的。

 

解

每个组织都需要投入人工智能（AI）没有AI的好东西是将复杂的日志减少到一个仪表板的方式。这使得IT经理能够获得集中数据，以便在整个计算环境中获得完整的可见性。简单来说，OpenStack技术的最终用户将以简化和易于理解的方式获得由计算机，网络和存储组件生成的日志的每个方面。数据将以实时的形式表示，并且可以轻松地监视环境中的自动更新。这将有助于减轻可能的数据丢失，因为所有服务都将可以启动并运行，而不会有任何偏差。

 

 

监控默认指标

OpenStack指标和日志过度依赖于问题检测的默认指标。这些包括内存泄漏，文件问题，死锁，性能结果等。虽然这些日志在识别常见问题方面非常好，但是它们可能无法检测需要专门的监控工具的复杂困境。通过使用通用度量的故障检测和预测可能并不总是按照需要工作，有时候会导致虚警。特殊问题检测的一个例子是当磁盘空间被使用到一定限度（例如80％）时提醒。这不是完全证明，因为在发生严重的性能下降之前可能无法检测到问题。

 

解

您将需要使用完整的故障识别方法并运行不同的测试，以确保某些服务正常。不要仅仅依靠开放源代码指标，而是在外面思考并运行所有的测试，这些测试可以帮助您识别某些组件是否发生故障，退化或只需要重新启动。

 

 

基于TCP的服务瓶颈和连接池耗尽

OpenStack是一种分布式服务，其所有核心服务通过REST API暴露自己。另一方面，OpenStack的消息服务是基于TCP的，因此它很容易受到包括网络和/或连接问题在内的主要问题的影响。此外，大多数OpenStack服务都连接到SQL（结构化查询语言）数据库。有时，大量的数据日志和指标，可以耗尽每个部署可用的连接池。

 

解

OpenStack需要具有正确的连接状态才能生成正确的监控解决方案。此外，使用正确的命令行工具来检查终端服务的状态，以获得背景中发生的情况的真实状态。换句话说，您需要开发一种通过定制度量来扩展监控解决方案的习惯，可以通过OpenStack API或其他市场可用的开源工具设计。大多数IT经理只有在过度依赖默认指标和日志时出错。

 

 

关于人类失败的一个最后的评论

作为IT经理，如果您希望运行没有瓶颈，您需要遵循正确的程序来管理云或虚拟机基础架构。有时，由于IT经理以某种方式失败，可能会导致OpenStack环境中的故障​​。由于人为因素导致的设计不当或无知因素可能导致整个系统的巨大失败。

 

如果发生问题，请始终测试不同的方案。此外，如果微组件出现问题，请确保您调查该方案，以了解它如何在很大程度上影响整个系统。请记住，忽略单一服务可能会导致收入损失，甚至导致您的亲爱的工作费用昂贵。此外，始终在监控仪表板中响应红色警报。例如，如果系统显示使用了95％的磁盘，请立即添加更多空间，或者如果您正在租用服务，则只需升级您的服务。

 

 

结论

OpenStack是一种伟大的技术，可以帮助您的业务发展，并使数据应用程序在云中保持安全。这些技术帮助我们在完全可靠的稳定环境中部署虚拟机。但是，我们需要记住，一台机器本身并不“思考”，我们需要做最好的工作，并采用指标，日志和正确使用基于人工智能的工具来采取适当的措施。

 

在计算世界中，没有正确定时的操作来修复问题的监控是模糊的。作为IT经理，您需要积极主动，并尽可能早地发现问题。然后，采取正确的步骤，将问题分散到其他领域，避免影响整个系统。一个OpenStack环境，具有适当的监控工具，与系统的微服务良好连接，为创意和有纪律的IT经理生成正确的信息，将赢得云计算的战斗。这也使得运行和维护虚拟云环境更容易，而不超出您的预算。

 

阅读其他领域，避免影响整个系统。一个OpenStack环境，具有适当的监控工具，与系统的微服务良好连接，为创意和有纪律的IT经理生成正确的信息，将赢得云计算的战斗。这也使得运行和维护虚拟云环境更容易，而不超出您的预算。

原文地址：https://www.loomsystems.com/blog/7-ways-ai-can-come-to-the-rescue-for-your-openstack-monitoring