La supervisión del rendimiento de las aplicaciones (APM) es mucho más que capturar y rastrear errores y seguimientos de pila. Las empresas actuales basadas en la nube implementan aplicaciones en varias regiones e incluso en proveedores de la nube. Por lo tanto, aprovechar el poder de los metadatos proporcionados por los agentes de Elastic APM se vuelve más crítico. Aprovechar los metadatos, incluida información crucial como la región de la nube, el proveedor y el tipo de máquina, nos permite realizar un seguimiento de los costos en toda la pila de aplicaciones. En esta publicación de blog, analizamos cómo podemos utilizar los metadatos de la nube para capacitar a las empresas para que tomen decisiones más inteligentes y rentables, al mismo tiempo que mejoramos la utilización de los recursos y la experiencia del usuario.

Primero, necesitamos una aplicación de ejemplo que nos permita monitorear los cambios de infraestructura de manera efectiva. Usamos una aplicación Python Flask con el agente APM de Elastic Python. La aplicación es una calculadora sencilla que toma los números como una solicitud REST. Utilizamos Locust, una sencilla herramienta de prueba de carga para evaluar el rendimiento bajo diferentes cargas de trabajo.

El siguiente paso incluye obtener la información de precios asociada con los servicios en la nube. Cada proveedor de nube es diferente. La mayoría de ellos ofrecen una opción para recuperar precios a través de una API. Pero hoy nos centraremos en Google Cloud y aprovecharemos su calculadora de precios para recuperar información de costos relevante.

El siguiente paso es elaborar nuestro documento de facturación:

Creamos un documento y establecemos una identificación personalizada. Este ID coincide con el nombre de la instancia y la región, ya que los costos de las máquinas pueden diferir en cada región. Las identificaciones automáticas podrían ser problemáticas porque es posible que desee actualizar periódicamente el costo de una máquina. Podría usar un índice con marca de tiempo para eso y solo usar la última coincidencia de documentos. Pero de esta manera puedo actualizar y no tengo que preocuparme por eso. También calculé el precio en minutos y horas. Lo más importante es el campo machine.enrichment , que es el mismo que el ID. El mismo tipo de instancia puede existir en varias regiones, pero nuestro procesador de enriquecimiento está limitado a coincidencias o rangos. Creamos un nombre coincidente que pueda coincidir explícitamente como en e2-standard-4_europe-west4 . Depende de usted decidir si desea que el proveedor de la nube esté allí y convertirlo en google_e2-standard-4_europ-west-4 .

No olvide ejecutar _execute al final. Esto es necesario para elaborar los índices internos utilizados por el enriquecimiento en la tubería de ingesta. La canalización de ingesta es bastante minimalista: llama al enriquecimiento y cambia el nombre de un campo. Aquí es donde entra en juego nuestro campo machine.enrichment . Una advertencia sobre el enriquecimiento es que cuando agrega nuevos documentos al índice de facturación en la nube, debe volver a ejecutar la instrucción _execute . El último bit calcula el costo total con el recuento de máquinas únicas vistas.

Como todo esto ya está configurado, estamos listos para nuestra Transformación. Para esto, necesitamos una vista de datos que coincida con los flujos de datos de APM. Esto es traces-apm* , metrics-apm.* , logs-apm.* . Para Transform, vaya a la interfaz de usuario de Transform en Kibana y configúrela de la siguiente manera:

Estamos haciendo un desglose por horas, por lo tanto, obtengo un documento por servicio, por hora, por tipo de máquina. Lo interesante son las agregaciones. Quiero ver el uso promedio de la CPU y el percentil 75,95,99, para ver el uso de la CPU cada hora. Permitiéndome identificar el uso de la CPU durante una hora. En la parte inferior, asigne un nombre a la transformación, seleccione un índice de costos de nube y seleccione la canalización de ingesta de facturación  en la nube .

Aquí está la transformación completa como documento JSON:

Una vez creada y ejecutada la transformación, necesitamos una vista de datos de Kibana para el índice: costos de nube . Para la transacción, utilice el formateador personalizado dentro de Kibana y establezca su formato en "Duración" en "microsegundos".

De izquierda a derecha, queremos centrarnos en el primer gráfico. Tenemos las barras que representan la CPU como promedio en verde y el percentil 95 en azul en la parte superior. Va de 0 a 100 % y está normalizado, lo que significa que incluso con 8 núcleos de CPU, seguirá leyendo el 100 % de uso y no el 800 %. El gráfico de líneas representa la duración de la transacción, el promedio está en rojo y el percentil 95 en morado. Por último, tenemos el área naranja en la parte inferior, que es el uso promedio de memoria en ese host.

Inmediatamente nos damos cuenta de que nuestra calculadora no necesita mucha memoria. Al pasar el cursor sobre el gráfico se muestra un uso de memoria del 2,89%. La máquina e2-standard-8 que estamos usando tiene 32 GB de memoria. Ocasionalmente alcanzamos un nivel de CPU del 100% en el percentil 95. Cuando esto sucede, vemos que la duración promedio de la transacción aumenta a 2,5 milisegundos. Sin embargo, cada hora esta máquina nos cuesta unos 30 céntimos. Con esta información, ahora podemos reducir el tamaño para adaptarlo mejor. El uso promedio de CPU es de alrededor del 11-13% y el percentil 95 no está tan lejos. 

Debido a que utilizamos 8 CPU, ahora se podría decir que el 12,5% representa un núcleo completo, pero eso es sólo una suposición en una hoja de papel. No obstante, sabemos que hay mucho margen de maniobra y podemos reducir bastante la escala. En este caso, decidí pasarme a 2 CPU y 2 GB de RAM, lo que se conoce como e2-highcpu2 . Esto debería adaptarse mejor a mi aplicación de calculadora. Apenas tocamos la RAM, el 2,89% de los 32 GB son aproximadamente 1 GB de uso. Después del cambio y reinicio de la máquina calculadora, comencé la misma prueba Locust para identificar el uso de mi CPU y, lo que es más importante, si mis transacciones se vuelven más lentas y, de ser así, en qué medida. En última instancia, quiero decidir si 1 milisegundo más de latencia vale 10 centavos más por hora. Agregué el cambio como una anotación en Lens.

Después de dejarlo funcionar por un momento, ahora podemos identificar el impacto de los hosts más pequeños. En este caso podemos ver que el promedio no cambió. Sin embargo, el percentil 95 (el 95% de todas las transacciones están por debajo de este valor) se disparó. Nuevamente, se ve mal al principio, pero al comprobarlo, pasó de ~1,5 milisegundos a ~2,10 milisegundos, un aumento de ~0,6 milisegundos. Ahora, puedes decidir si vale la pena pagar ~180$ más al mes por ese aumento de 0,6 milisegundos o si la latencia actual es lo suficientemente buena.