Como introducción ...
La explotación industrial requiere el conocimiento de cómo vive una aplicación. Esta tesis debe tomarse como un axioma. Este conocimiento son las métricas producidas por la aplicación. Las métricas pueden ser puramente técnicas (por ejemplo, la cantidad de RAM consumida) y comerciales (por ejemplo, pedidos completados).
Por sí solo, un corte de métricas no siempre es interesante e indicativo en este momento. Surgen preguntas básicas sobre la recopilación, el almacenamiento y la visualización de estas métricas.
La situación con la necesidad de métricas y la forma en que se procesan se agudiza cuando se utiliza un enfoque de servicio y una aplicación, desde el punto de vista del usuario, está respaldada por la operación de varios servicios interactivos. Agregue la implementación de la nube a eso y obtenga el pimiento picante .
De qué se trata
El proyecto en el que estoy participando solo usa servicios y se implementa en AWS (Amazon Web Services). La mayoría de los servicios se crean con Java 8+, Spring Boot y Docker. La conferencia en Luxoft IT Sreda # 7 y este artículo surgieron de las necesidades y objetivos del proyecto.
Mi objetivo es analizar el aspecto práctico de recopilar métricas de aplicaciones con Spring Boot y exportarlas a AWS CloudWatch . Esta será, de hecho, una guía paso a paso con explicaciones, análisis de matices y posibles rastrillos.
Cuando hablamos de resolver un problema práctico, es importante comprender sus síntomas para poder compararlo con el entorno existente. ¿Es posible aplicar lo que estamos hablando uno a uno o si se requiere adaptación, más investigación?
Echemos un vistazo a en qué consiste nuestro contexto actual:
- De hecho, nuestra aplicación o servicio se basa en Spring Boot. Como constructor de Maven, Java 8+
- Estibador. Sin embargo, su uso no es crítico. Es importante que para una aplicación que se ejecute en Docker, todo funcione también
- AWS EC2 es nuestra infraestructura donde se ejecuta la aplicación. En esencia, es una máquina virtual dentro de AWS.
- AWS CloudWatch es un sistema de monitoreo que es un panel de infraestructura de AWS.
Bota de primavera
Pasemos a SpringBoot y sus características que pueden ayudarnos. Lo primero y más importante en el arsenal es Actuator . Este módulo le permite mirar dentro de una aplicación en ejecución y, hasta cierto punto, personalizar su comportamiento. Por ejemplo:
- Health check:
- , , runtime.
- ,
- , , : , , GC.
- ...
Como muchos componentes de Spring, Actuator es similar a un constructor y se puede personalizar, ampliar y ajustar. Puedes empezar a estudiar desde aquí .
De todo el conjunto, actualmente estamos interesados en métricas. El actuador y las métricas en particular no solo son extensibles, sino que también están preconfigurados, por lo que solo hay un par de docenas de categorías de métricas disponibles de fábrica. Por supuesto, puede registrar sus propias métricas. Si el módulo web está conectado en el proyecto, las métricas se pueden obtener contactando
endpoint /metrics.
La recopilación y provisión de métricas se implementa a través de la biblioteca de micrómetros , que es un producto de Pivotal(ahora parte de VMware), el mismo que está desarrollando Spring. El micrómetro se comercializa como una fachada independiente del proveedor para exportar métricas de aplicaciones Java.
El actuador requerirá el siguiente arrancador para conectarse:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>Nube de primavera
A continuación, necesitamos un módulo de Spring Cloud, a saber
spring-cloud-starter-aws.
Cada módulo de la familia Spring Cloud tiene su propio control de versiones y será correcto usar no una versión específica del módulo, sino la lista de materiales de una
spring-cloud-dependenciesversión específica (tren de lanzamiento), donde se recopilan las versiones compatibles de los módulos. En el momento de escribir este artículo, este es Hoxton.
Además de las sabrosas configuraciones automáticas para trabajar con AWS
spring-cloud-starter-aws, como dependencia transitiva, ofrece aws-java-sdk.
En la sección de gestión de dependencias, ponga
<dependencyManagement>
...
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Hoxton.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
...
</dependencyManagement>Y dependiendo de:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-aws</artifactId>
</dependency>Registro micrométrico
Ahora tenemos un micrómetro en el actuador de resorte y
aws-java-sdk. Fuera de la caja, el micrómetro no puede exportar datos a AWS CloudWatch, esto requiere una implementación adecuada de MeterRegestry, una abstracción de micrómetro para recopilar métricas. El valor predeterminado es SimpleMeterRegistry, que almacena datos en la memoria. La implementación requerida está relacionada con micrometer-registry-cloudwatch. En el momento de escribir este artículo, la versión actual es 1.3.5.
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-cloudwatch</artifactId>
<version>1.3.5</version>
</dependency>El pom.xml final, en nuestro caso, se ve así: github.com/MrArtemAA/blog-demos/blob/master/export-metrics-to-cloudwatch/pom.xml
app.properties
Pasemos a la configuración de las propiedades de la aplicación, que en nuestro caso desempeñan un papel importante:
1
management.metrics.export.cloudwatch.namespace.: debe especificar el espacio de nombres en el que se guardarán las métricas en CloudWatch. Porque en la métrica en sí no hay información de qué instancia de la aplicación provienen los datos, el espacio de nombres solo determinará las métricas de una instancia en particular. De lo contrario, si define un espacio de nombres para varias instancias, los datos de las métricas se mezclarán y no está claro de dónde provienen.
2
management.metrics.export.cloudwatch.batch-size.: Es necesario establecer explícitamente el valor de la propiedad de tamaño de lote en 20. ¿Qué es este parámetro y por qué exactamente 20? Las métricas se envían a los clientes de Amazon CloudWatch de forma asíncrona, en lotes de 20 (este es el límite de AWS) a la vez.
3
cloud.aws.stack.auto=false.: Es necesario deshabilitar la detección automática de pila de AWS CloudFormationya que por defecto es = verdadero. Esta propiedad es responsable de si la aplicación intentará obtener automáticamente el nombre de la pila para configurar la aplicación para el entorno de nube (en el paradigma de infraestructura como código). Cuando se implementa en EC2, como en una máquina virtual normal, esta información no está disponible.
Es importante comprender que toda la información que AWS SDK intentará obtener por sí solo sin configuración adicional, [la biblioteca] la tomará de los metadatos de EC2 . Para obtener esta información, existe un punto final de servicio especial, donde se realiza la llamada.
Interrogación
tamaño del lote
Volvamos a la propiedad
management.metrics.export.cloudwatch.batch-sizey la necesidad de ponerla en 20. Parece que todo esto se puede hacer a nivel de las bibliotecas correspondientes que trabajan con AWS. De hecho, micrometer-registry-cloudwatchhay una interfaz con un CloudWatchConfig defaultmétodo que comprueba correctamente el valor y lanza una excepción si supera los 20. Sin embargo, si miras org.springframework.cloud.aws.autoconfigure.metrics.CloudWatchExportAutoConfiguration, veremos que la configuración se realiza utilizandoorg.springframework.cloud.aws.autoconfigure.metrics.CloudWatchPropertiesConfigAdapter:
@Bean
@ConditionalOnMissingBean
public CloudWatchConfig cloudWatchConfig(CloudWatchProperties cloudWatchProperties) {
return new CloudWatchPropertiesConfigAdapter(cloudWatchProperties);
}El adaptador, a su vez, anula
batchSize()como
@Override
public int batchSize() {
return get(CloudWatchProperties::getBatchSize, CloudWatchConfig.super::batchSize);
}Esto significa que si
CloudWatchPropertiesse define una propiedad, se tomará de allí. No contiene las comprobaciones necesarias y, si la propiedad no se establece explícitamente, el valor predeterminado será 10000.
Solicitudes a AWS
Una aplicación (servicio) no puede simplemente realizar solicitudes a los servicios de Amazon. [Las solicitudes] deben contener credenciales. Para hacer esto, AWS SDK tiene una cadena de proveedores de credenciales , que se recomienda. Entre estos proveedores se encuentra Instance Profile, que puede recibir datos basados en metadatos EC2. Para que esto funcione, debe asegurarse de que un rol esté vinculado a EC2 .
El rol debe otorgar permiso para realizar solicitudes a CloudWatch y estar disponible para EC2. El rol se puede especificar tanto al crear una nueva instancia EC2 como adjuntarse a una existente. El papel se aplica sobre la marcha.
Deshabilitar métricas
Para un entorno de prueba o compilación local, la exportación de métricas puede resultar excesiva. Establecer la propiedad le
management.metrics.export.cloudwatch.enabled=falsepermite deshabilitar la exportación de métricas a CloudWatch, mientras que la recopilación de métricas se realizará y, si tiene un módulo web conectado, endpoint /metricsaún estarán disponibles.
Micrometer recopila y entrega una amplia variedad de métricas. Si algunos de ellos no son necesarios, puede desactivarlos. Puede deshabilitar tanto individualmente como por categorías completas. Entonces, por ejemplo, la propiedad deshabilitará todas las métricas cuyo ID comience con . Tenga en cuenta: las métricas deshabilitadas no se recopilarán en absoluto.
management.metrics.enable.some.metric=falsesome.metric
Ejecutando todo AWS
Otra sorpresa te espera si intentas ejecutar la aplicación con la configuración mínima requerida en todo AWS. Para trabajar, los datos necesarios de la región donde se ejecuta la aplicación. Como ya sabemos, todo lo que no se indique explícitamente, el AWS SDK intentará obtener de los metadatos ... que no están allí. Por lo tanto, indicamos explícitamente la región deseada a través de la propiedad
cloud.aws.region.static=us-east-2. Como en el caso del nombre de la pila (propiedad cloud.aws.stack.auto), hay una propiedad que es cloud.aws.region.autoigual truepor defecto. Pero simplemente establecer el valor en falso no nos ayudará, ya que se necesita el valor de la región.
Además, como recordamos, las solicitudes a AWS requieren credenciales, por lo que si necesita transferir métricas a CloudWatch (o realizar otras solicitudes a AWS), debe especificar explícitamente los parámetros para las credenciales.a través de, por ejemplo, propiedades de la aplicación o variables de entorno.
Pasar por las propiedades de la aplicación se ve así:
cloud.aws.credentials.access-key=YOUR_ACCESS_KEY
cloud.aws.credentials.secret-key=YOUR_SECRET_KEY
Salir
Como creo que habrá notado, hacer que todo el esquema funcione y transferir métricas de la aplicación a CloudWatch no es tan difícil: se necesitaron 3 dependencias y 3 propiedades .
Lo más importante está en los detalles. Las bibliotecas (frameworks) como Spring, AWS SDK intentan hacernos la vida más fácil y hacer todo el trabajo por nosotros tanto como sea posible, pero al mismo tiempo, cualquier paso a un lado puede llevar a la aparición de un stacktrace, intenta entender por qué las métricas no van a ninguna parte, por qué la aplicación no se inicia en absoluto Y como arreglarlo. Espero que una sección con un desglose de los matices y una descripción de algunos de los detalles de cómo funcionan los servicios EC2 y CloudWatch le facilite la comprensión de lo que está sucediendo.
Si hablamos de usar CloudWatch en sí, entonces, en mi opinión, esta es una opción bastante natural cuando se usa la infraestructura de AWS.
Las métricas son los ojos y los oídos de nuestra aplicación, pero esto no niega el hecho de que necesita comprender cómo se recopilan, cuentan y muestran las métricas. ¿Qué tipo de datos verá en sus gráficos? Este problema será especialmente agudo en caso de anomalías y análisis de incidentes. Si hablamos de la biblioteca de micrómetros, vale la pena referirse a la documentación , allí, por ejemplo, se describe con cierto detalle sobre los tipos de medidores (Meter).
Enlaces
El intercambio de experiencias nos permite dominar rápidamente varios enfoques, herramientas, tecnologías y avanzar. Por lo tanto, no puedo ignorar los materiales más útiles sobre el tema, que no fueron referenciados durante el artículo:
Spring Boot: Metrics With Micrometer y AWS CloudWatch
Spring Cloud. Uso de Amazon Web Services. Configuración automática de Spring Boot
Spring in Action 5, Craig Walls, Manning
Popular sobre Amazon Web Services El
proyecto terminado se puede encontrar en GitHub .