我以前是很喜欢用Ansible的,特别是面对大数据系统与分布式微服务系统这种有多节点,多组件需要部署和维护配置的场景,Ansible能够帮我们很好的实现运维步骤的自动化和标准化。但对于Ansbile的使用,我一直也有一个不满意的地方,就是缺乏足够的可观测性,在排障与性能检测时,能够使用的手段比较原始,特别是碰到一些情况,比如:“上次明明运行得好好的,这次怎么出错了呢?”因为没有将运行日志保存的习惯或者没有便捷保存的方法,出现意想不到的问题时,无法快速发现原因,并且,因为没有具体的性能指标和基线,所以,很难对一个Ansible脚本进行优化。
幸运的是,在最近的Elastic Stack新版本中,加入了对Ansible相关指标的监控。所以,在这篇以自动化为重点的博文中,我们将展示如何使用 Elastic Observability 来检测以Ansible做媒介的基础设施自动化。借助 Elastic Observability,自动化团队可以生成基线信息,帮助他们确定需要优化的领域,并开发仪表板,将业务价值传达给利益相关者。
我们将展示Elastic Observability 如何帮助自动化团队回答五个关键问题,以确定他们的playbook的运行情况,即:
我们将探索如何使用数据来优化自动化,然后看看我们如何配置 Ansible 命令行以及 AWX(Tower)来提取数据。
Ansible管道的埋点监测是基于OpenTelemetry的。这提供了一个开源的遥测收集方法,Elastic团队与Ansible社区合作,提供Ansible的可见性。
默认情况下,export将OpenTelemetry兼容的数据发布到Elastic应用性能监控(APM),这提供了对自动化流程执行情况的即时洞察力。
下面我们举一些例子:当我们将埋点监测的数据发送到Elastic Stack,我们能够在Observability App上能够获得哪些可见性,如何定位缓慢的任务,分析失败的任务......
在这个例子中,我们将自动化流程和测试按服务分组,服务视图提供了你的团队可能正在管理的所有服务的概览,以及对平均运行时间(延迟)和故障率的洞察力。
选择一个服务下钻,可以看到与该服务相关的Playbook以及测试的运行效率和对外的依赖(这里是github):
对于自动化,只要花上一些时间,总是可以找到可以提高的地方,所以,我们可以深入到一个特定的 "transation",以查看单个任务的运行情况。在下面的例子中,我们的Kubernetes环境启动比平时花了很多时间,但整体流程并没有失败。
而对于失败的情况,我们则可以通过点击失败的任务,立即得到更多关于Ansible任务的细节信息以及错误信息。
你可能会注意到上面的跨度细节中一些有趣的字段。Ansible Open Telemetry回调插件给OpenTelemetry数据添加了标签,我们可以使用这些标签来构建自定义仪表盘和查询。事实上,我们可以添加自己的自定义标签,在这个例子中是 "manual_effort "和 "team "来进一步完善我们的仪表盘。
现在让我们来探讨一下,通过对自动化流程的检测,我们可以回答什么样的更高层次的问题。为此,我们将使用仪表盘来总结数据。
关于健康监测,我们首先要了解团队整体自动化程度以及他们何时运行自动化。同时,了解 Ansible 版本是否随着时间的推移能保持一致也是一件好事。
大多数信息都是开箱即用的。Ansible 插件有两个变量,我们可以根据这两个变量将信息按照按团队和服务进行分组:
OTEL_SERVICE_NAME
- 此变量可用于服务分组,例如,上文中的“Services Overview” 视图中的“Account Test Environment”服务。 OTEL_RESOURCE_ATTRIBUTES
- 这是一个可以自定义的变量,使我们能够设置任何有用的自定义属性。在我们的例子中,我们正在记录 label.team
和label.manual_effort
记录每个团队和每个自动化流程的预期人工努力,使我们能够通过建立仪表板,展示团队通过自动化在一段时间内节省了多少人工努力。这个仪表板记录了每个团队在一段时间内花费在手动工作上的时间,通过对比,可向领导证明部署、运行和扩大企业范围的自动化所需的努力和带来的价值。
最后一个问题是了解团队使用哪些模块,以及他们在使用过程中遇到了哪些问题。
Ansible插件捕获了Ansible任务级别的信息,从中我们可以看到,团队使用了过多的command
和shell
模块,对于Ansible的最佳实践来说,这是应该避免的。这将是这个团队优化工作的一个机会。它还显示,由于该团队使用shell
模块的方式导致了大量的失败,并对最主要的错误进行了总结。有了这些信息,就能凸显出需要改进的地方。
这里的好消息是对Playbook的埋点,不需要对Playbook本身进行任何修改。我们要添加的,只是 ansible 社区包、三个 python 依赖项、ansible.cfg 文件中的一个条目以及指向 Elastic APM 服务器的环境变量。
本节将简要介绍所需的更改,如果您想了解详细信息,请参阅此存储库。
命令行模式下,Ansible的配置需要四个步骤。
callbacks_enabled = community.general.opentelemetry
在使用AWX或Ansible Tower时,在应用配置的地方有一点细微差别。本项目中的AWX运行在Kubernetes上,所以我们需要的设置和包都在特定的组件中。
AWX 需要安装了 Ansible 和 Python 包的执行环境。为此,我们使用Ansible Builder 工具来创建容器定义。
然后,您将容器上传到 AWX 可访问的映像存储库,并使用您创建的容器定义执行环境。
要注入环境变量和服务详细信息,您可以使用自定义凭证类型,然后将凭证分配给 Playbook 模板。这使您可以灵活地为 Elastic APM 重复使用端点详细信息,并标准化自定义字段以用于报告目的。
分发 Ansible 配置文件设置的最简单方法是将 anisble.cfg 文件包含在您用于模板的自动化项目的根文件夹中。
以上就是我们需要做的所有配置。完成后,您在 AWX 中运行的Playbook的遥测数据将出现在 Elastic 中,为您提供深刻的见解。
在这篇博文中,我们展示了检测 Ansible 自动化如何提供洞察力,帮助您优化和标准化组织中的自动化。我们还展示了检测 Ansible 自动化流程是多么容易。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。