Si bien la automatización de los sistemas se considera un imperativo en las salas de juntas de todo el mundo, los equipos de automatización (los equipos sobre el terreno) a menudo carecen de los datos que les ayuden a industrializar sus esfuerzos de automatización y pasar de la automatización ad-hoc a la automatización estratégica.
En esta publicación de blog centrada en la automatización, mostraremos cómo instrumentar la automatización de la infraestructura con Elastic Observability. Con Elastic Observability, los equipos de automatización pueden producir información que los ayudará a identificar áreas para la optimización y desarrollar tableros que comuniquen el valor comercial a las partes interesadas y al C-Suite.
Demostraremos cómo la observabilidad puede ayudar a los equipos de automatización a responder cinco preguntas críticas para determinar cómo se están desempeñando sus procesos, a saber:
Exploraremos cómo usamos los datos para optimizar la automatización y luego veremos cómo configuramos la línea de comandos de Ansible y AWX (Tower) para extraer los datos.
Fuera de la caja
La instrumentación de canalización para Ansible se basa en OpenTelemetry . Esto proporciona un enfoque de código abierto para la recopilación de telemetría donde el equipo de Elastic está trabajando con la comunidad de Ansible para brindar visibilidad de Ansible.
De forma predeterminada, la exportación publica datos compatibles con OpenTelemetry en Elastic Application Performance Monitoring (APM), que proporciona información inmediata sobre el rendimiento de los flujos de automatización.
Comience con el fin en mente: ¿Qué nos dicen los datos sobre nuestras tuberías y su desempeño?
¿Cuál es la tendencia del desempeño de mis servicios de automatización?
En el escenario de ejemplo, tenemos flujos de automatización y pruebas agrupados por servicios, la vista Servicios proporciona una descripción general de todos los servicios que su equipo podría estar administrando con información sobre el tiempo de ejecución promedio (latencia) y la tasa de fallas.
Profundizar en un servicio proporciona información sobre los libros de jugadas y las pruebas que ejecutamos como parte de este servicio, así como sobre el rendimiento de nuestras dependencias.
¿Cuáles son los problemas específicos y los cuellos de botella?
Parece que esto tiene trabajo por hacer para mejorar la resiliencia de su automatización, por lo que profundizarían en una "Transacción" específica para ver cómo se ejecutan las tareas individuales. En este ejemplo, nuestro entorno de Kubernetes tardó mucho más de lo habitual, pero la transacción no falló.
Sin embargo, esta automatización falló y, al hacer clic en la tarea fallida, podemos obtener inmediatamente más información sobre los detalles de la tarea de Ansible, así como el mensaje de error.
Es posible que observe algunos campos interesantes en los detalles de intervalo anteriores. El complemento de devolución de llamada de Ansible Open Telemetry agrega etiquetas a los datos de OpenTelemetry, y podemos usar estas etiquetas para crear paneles y consultas personalizados. De hecho, podemos agregar nuestras propias etiquetas personalizadas, en este ejemplo, "manual_effort" y "team" para refinar aún más nuestros paneles.
Ahora exploremos qué tipo de preguntas de alto nivel podemos responder instrumentando nuestros flujos de automatización. Para ello utilizaremos cuadros de mando para resumir datos.
¿Cuál es el estado general de nuestra capacidad de automatización?
El primer conjunto de preguntas que me gustaría responder está relacionado con la cantidad de automatización que realizan los equipos en general y cuándo ejecutan la automatización. También sería bueno entender si la versión de Ansible es consistente a lo largo del tiempo.
La mayor parte de esta información está disponible lista para usar. El plugin de Ansible tiene dos variables que usamos para agrupar información por Equipo y también por Servicio:
¿La automatización le ahorra tiempo a mi negocio y aumenta la productividad?
Capturar los nombres de los equipos y también el esfuerzo manual esperado por flujo de automatización nos permite crear paneles que demuestran cuánto esfuerzo manual ahorraron los equipos con el tiempo a través de la automatización. Este tablero agrega las horas de esfuerzo manual por equipo a lo largo del tiempo y es oro de gestión y permite a las organizaciones justificar el esfuerzo requerido para implementar, ejecutar y expandir la automatización en toda la empresa.
¿Los equipos están utilizando la automatización de manera efectiva y dónde podemos optimizar?
El último conjunto de preguntas que estamos viendo es tratar de comprender qué módulos usan los equipos y también con qué módulos tienen problemas.
El complemento de Ansible captura la información del nivel de tarea de Ansible y, a partir de esto, podemos ver que los equipos usan más módulos de comando y shell de lo que recomendarían las buenas prácticas de Ansible. Esta sería una oportunidad para que este equipo optimice su trabajo. También muestra que el equipo tiene una gran cantidad de fallas debido a la forma en que usan el módulo de shell con un resumen de los principales errores. Tener esta información fácilmente disponible destaca las áreas de mejora y ganancias rápidas.
Instrumentación de Ansible: ¡Cero cambios en el libro de jugadas!
La buena noticia aquí es que los libros de jugadas de instrumentación no requieren ningún cambio en los libros de jugadas reales. Como mínimo, requiere el paquete comunitario ansible, tres dependencias de python, una entrada en el archivo ansible.cfg y variables de entorno que apunten al servidor Elastic APM.
Línea de comando Ansible
La configuración de la línea de comandos de Ansible requiere cuatro pasos:
callbacks_enabled = community.general.opentelemetry
Configuración de AWX/Torre
Hay un pequeño matiz sobre dónde aplicar la configuración cuando se usa AWX o Ansible Tower. AWX en este proyecto se ejecuta en Kubernetes, por lo que la configuración y los paquetes que necesitamos están en componentes específicos.
Paquetes
AWX requiere un entorno de ejecución con los paquetes Ansible y Python instalados. Para ello utilizamos la herramienta Ansible Builder para crear la definición del contenedor.
Luego carga el contenedor en un repositorio de imágenes accesible por AWX y define un entorno de ejecución utilizando el contenedor que creó.
Detalles del servicio y variables de entorno
Para inyectar las variables de entorno y los detalles del servicio, puede usar tipos de credenciales personalizados y luego asignar las credenciales a la plantilla de Playbook. Esto le brinda la flexibilidad de reutilizar los detalles del punto final para Elastic APM y también estandarizar los campos personalizados para fines de generación de informes.
Archivo de configuración de Ansible
La forma más fácil de propagar la configuración del archivo de configuración de Ansible es incluir el archivo anisble.cfg en la carpeta raíz del proyecto de automatización que usa para las plantillas.
Eso es todo lo que hay que hacer. Una vez hecho esto, los datos de telemetría de los libros de jugadas que ejecute en AWX aparecerán en Elastic, lo que le brindará una gran información.
Resumen
En esta publicación de blog, demostramos cómo instrumentar su automatización Ansible puede proporcionar información que lo ayudará a optimizar e industrializar la automatización en su organización. También mostramos lo fácil que es instrumentar sus flujos de automatización de Ansible.