我以前是很喜欢用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上能够获得哪些可见性，如何定位缓慢的任务，分析失败的任务......

我的自动化服务的性能趋势是怎样的？

在这个例子中，我们将自动化流程和测试按服务分组，服务视图提供了你的团队可能正在管理的所有服务的概览，以及对平均运行时间（延迟）和故障率的洞察力。

Services Overview

选择一个服务下钻，可以看到与该服务相关的Playbook以及测试的运行效率和对外的依赖（这里是github）：

Transactions and Dependencies

有哪些具体问题和瓶颈？

对于自动化，只要花上一些时间，总是可以找到可以提高的地方，所以，我们可以深入到一个特定的 "transation"，以查看单个任务的运行情况。在下面的例子中，我们的Kubernetes环境启动比平时花了很多时间，但整体流程并没有失败。

Transaction Span

而对于失败的情况，我们则可以通过点击失败的任务，立即得到更多关于Ansible任务的细节信息以及错误信息。

image.png

Span details for a failed transaction

你可能会注意到上面的跨度细节中一些有趣的字段。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

自动化的总览仪表板

自动化是否为我的企业节省了时间并提高了生产力？

记录每个团队和每个自动化流程的预期人工努力，使我们能够通过建立仪表板，展示团队通过自动化在一段时间内节省了多少人工努力。这个仪表板记录了每个团队在一段时间内花费在手动工作上的时间，通过对比，可向领导证明部署、运行和扩大企业范围的自动化所需的努力和带来的价值。

Hours saved by Team

自动化的效率如何？我们可以在哪些方面进行优化？

最后一个问题是了解团队使用哪些模块，以及他们在使用过程中遇到了哪些问题。

Ansible插件捕获了Ansible任务级别的信息，从中我们可以看到，团队使用了过多的 command和 shell模块，对于Ansible的最佳实践来说，这是应该避免的。这将是这个团队优化工作的一个机会。它还显示，由于该团队使用 shell模块的方式导致了大量的失败，并对最主要的错误进行了总结。有了这些信息，就能凸显出需要改进的地方。

Automation Module Summary

对Ansible进行埋点检测，无需修改任何的Playbook!

这里的好消息是对Playbook的埋点，不需要对Playbook本身进行任何修改。我们要添加的，只是 ansible 社区包、三个 python 依赖项、ansible.cfg 文件中的一个条目以及指向 Elastic APM 服务器的环境变量。

本节将简要介绍所需的更改，如果您想了解详细信息，请参阅 。

命令行模式下运行Ansible

命令行模式下，Ansible的配置需要四个步骤。

• 安装Ansible community.general软件包
• 安装Python依赖项：opentelemetry-exporter-otlp
• 更新ansible.cfg文件，  callbacks_enabled = community.general.opentelemetry
• 指定OTEL_EXPORTER_OTLP_ENDPOINT为环境变量

AWX/Tower 模式

在使用AWX或Ansible Tower时，在应用配置的地方有一点细微差别。本项目中的AWX运行在Kubernetes上，所以我们需要的设置和包都在特定的组件中。

Package

AWX 需要安装了 Ansible 和 Python 包的执行环境。为此，我们使用Ansible Builder 工具来创建容器定义。

然后，您将容器上传到 AWX 可访问的映像存储库，并使用您创建的容器定义执行环境。

服务信息和环境变量

要注入环境变量和服务详细信息，您可以使用自定义凭证类型，然后将凭证分配给 Playbook 模板。这使您可以灵活地为 Elastic APM 重复使用端点详细信息，并标准化自定义字段以用于报告目的。

配置APM Server信息

配置自定义字段

Ansible 配置文件

分发 Ansible 配置文件设置的最简单方法是将 anisble.cfg 文件包含在您用于模板的自动化项目的根文件夹中。

以上就是我们需要做的所有配置。完成后，您在 AWX 中运行的Playbook的遥测数据将出现在 Elastic 中，为您提供深刻的见解。

总结

在这篇博文中，我们展示了检测 Ansible 自动化如何提供洞察力，帮助您优化和标准化组织中的自动化。我们还展示了检测 Ansible 自动化流程是多么容易。