Como introdução ...
A exploração industrial requer conhecimento de como vive um aplicativo. Esta tese deve ser tomada como um axioma. Esse conhecimento é a métrica produzida pelo aplicativo. As métricas podem ser puramente técnicas (por exemplo, a quantidade de RAM consumida) e comerciais (por exemplo, pedidos concluídos).
Por si só, um corte de métricas nem sempre é interessante e indicativo no momento. Surgem questões básicas sobre como coletar, armazenar e exibir essas métricas.
A situação com a necessidade de métricas e a forma como são processadas torna-se mais aguda quando uma abordagem de serviço é usada e uma aplicação, do ponto de vista do usuário, é suportada pela operação de vários serviços interagindo. Adicione a implantação da nuvem a isso e colha o pimentão .
Sobre o que é isso
O projeto do qual estou participando está apenas usando serviços e implantado no AWS (Amazon Web Services). A maioria dos serviços é construída usando Java 8+, Spring Boot e Docker. A palestra na Luxoft IT Sreda # 7 e este artigo surgiram das necessidades e objetivos do projeto.
Meu objetivo é examinar o lado prático da coleta de métricas de aplicativos usando Spring Boot e exportá-los para o AWS CloudWatch . Este será, na verdade, um guia passo a passo com explicações, análises de nuances e possíveis ancinhos.
Quando falamos em resolver um problema prático, é importante entender seus sintomas para compará-lo com o ambiente existente. É possível aplicar o que estamos falando um a um ou, se houver necessidade de adaptação, mais pesquisas.
Vamos dar uma olhada em em que consiste nosso contexto atual:
- Como dado, nosso aplicativo ou serviço é baseado no Spring Boot. Como um construtor Maven, Java 8+
- Docker. No entanto, seu uso não é crítico. É importante que para um aplicativo em execução no docker tudo funcione também
- O AWS EC2 é nossa infraestrutura onde o aplicativo é executado. Em sua essência, é uma máquina virtual dentro da AWS.
- AWS CloudWatch é um sistema de monitoramento que é um painel de infraestrutura da AWS.
Spring Boot
Vamos passar para o SpringBoot e seus recursos que podem nos ajudar. A primeira e mais importante coisa no arsenal é o Atuador . Este módulo permite que você olhe dentro de um aplicativo em execução e, em certa medida, personalize seu comportamento. Por exemplo:
- Health check:
- , , runtime.
- ,
- , , : , , GC.
- ...
Como muitos componentes do Spring, Actuator é semelhante a um construtor e pode ser customizado, estendido e ajustado. Você pode começar a estudar aqui .
De todo o conjunto, atualmente estamos interessados em métricas. O atuador e as métricas em particular não são apenas extensíveis, mas também pré-configurados, portanto, há apenas algumas dezenas de categorias de métricas disponíveis prontas para uso. Claro, você pode registrar suas próprias métricas. Caso o módulo web esteja conectado ao projeto, as métricas podem ser obtidas entrando em contato
endpoint /metrics
.
A coleta e entrega de métricas são implementadas por meio da biblioteca de micrômetros , que é um produto da Pivotal(agora parte da VMware), a mesma que está desenvolvendo o Spring. micrômetro é comercializado como uma fachada independente de fornecedor para exportar métricas de aplicativos Java.
O atuador exigirá o seguinte iniciador para conectar:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Spring Cloud
Em seguida, precisamos de um módulo do Spring Cloud, a saber
spring-cloud-starter-aws
.
Cada módulo da família Spring Cloud possui sua própria versão e será correto usar não uma versão específica do módulo, mas o BOM de uma
spring-cloud-dependencies
versão específica (trem de lançamento), onde as versões compatíveis dos módulos são coletadas. No momento da escrita, este é Hoxton.RELEASE.
Além de deliciosas autoconfigurações, para trabalhar com AWS
spring-cloud-starter-aws
, como uma dependência transitiva, ele dá aws-java-sdk
.
Na seção dependencyManagement, coloque
<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>
E dependendo de:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-aws</artifactId>
</dependency>
Registro de micrômetro
Agora temos um micrômetro no atuador da mola e
aws-java-sdk
. Fora da caixa, o micrômetro não sabe como exportar dados para o AWS CloudWatch, isso requer uma implementação apropriada de MeterRegestry, uma abstração de micrômetro para coletar métricas. O padrão é SimpleMeterRegistry, que armazena dados na memória. A implementação necessária está conectada junto com micrometer-registry-cloudwatch
. No momento em que este artigo foi escrito, a versão atual é 1.3.5.
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-cloudwatch</artifactId>
<version>1.3.5</version>
</dependency>
O pom.xml final, em nosso caso, tem a seguinte aparência: github.com/MrArtemAA/blog-demos/blob/master/export-metrics-to-cloudwatch/pom.xml
app.properties
Vamos prosseguir para a configuração das propriedades do aplicativo, que em nosso caso desempenham um papel importante:
1
management.metrics.export.cloudwatch.namespace
.: você precisa especificar o namespace sob o qual as métricas serão salvas no CloudWatch. Porque na própria métrica não há informações de qual instância do aplicativo os dados vieram, o namespace apenas determinará as métricas de uma instância específica. Caso contrário, se você definir um namespace para várias instâncias, os dados de métricas serão misturados e não ficará claro de onde eles vieram.

2
management.metrics.export.cloudwatch.batch-size
.: É necessário definir explicitamente o valor da propriedade batch-size como 20. O que é esse parâmetro e por que exatamente 20? As métricas são enviadas aos clientes Amazon CloudWatch de maneira assíncrona, em lotes de 20 (esse é o limite da AWS) por vez.
3
cloud.aws.stack.auto=false
.: Precisa desabilitar a autodetecção de pilha do AWS CloudFormationDesde a o padrão é = true. Esta propriedade é responsável por se o aplicativo tentará obter automaticamente o nome da pilha para configurar o aplicativo para o ambiente de nuvem (no paradigma de infraestrutura como código). Ao implantar no EC2, como em uma máquina virtual normal, essas informações não estão disponíveis.
É importante entender que todas as informações que o SDK da AWS tentará obter por conta própria, sem configuração adicional, ele [a biblioteca] obterá dos metadados EC2 . Para obter essas informações, há um terminal de serviço especial, que é acessado.
Interrogatório
tamanho do batch
Vamos voltar à propriedade
management.metrics.export.cloudwatch.batch-size
e à necessidade de defini-la como igual a 20. Parece que tudo isso pode ser feito no nível das bibliotecas correspondentes que trabalham com AWS. Na verdade, micrometer-registry-cloudwatch
existe uma interface com um CloudWatchConfig default
método que verifica corretamente o valor e lança uma exceção se exceder 20. No entanto, se você olhar org.springframework.cloud.aws.autoconfigure.metrics.CloudWatchExportAutoConfiguration
, veremos que a configuração é feita usandoorg.springframework.cloud.aws.autoconfigure.metrics.CloudWatchPropertiesConfigAdapter:
@Bean
@ConditionalOnMissingBean
public CloudWatchConfig cloudWatchConfig(CloudWatchProperties cloudWatchProperties) {
return new CloudWatchPropertiesConfigAdapter(cloudWatchProperties);
}
O adaptador, por sua vez, substitui
batchSize()
como
@Override
public int batchSize() {
return get(CloudWatchProperties::getBatchSize, CloudWatchConfig.super::batchSize);
}
Isso significa que se uma
CloudWatchProperties
propriedade for definida, ela será obtida a partir daí. Ele não contém as verificações necessárias e, se a propriedade não for definida explicitamente, o valor padrão será 10.000.
Solicitações para AWS
Um aplicativo (serviço) não pode apenas fazer solicitações aos serviços da Amazon. Eles [solicitações] devem conter credenciais. Para fazer isso, o SDK da AWS tem uma cadeia de provedores de credenciais , o que é recomendado. Entre esses provedores está o Perfil de Instância, que pode receber dados com base em metadados EC2. Para que isso funcione, você precisa ter certeza de que uma função está vinculada ao EC2 .

A função deve conceder permissões para fazer solicitações ao CloudWatch e estar disponíveis para o EC2. A função pode ser especificada ao criar uma nova instância EC2 ou anexada a uma existente. A função é aplicada instantaneamente.
Desativando métricas
Para uma construção local ou ambiente de teste, exportar métricas pode ser um exagero. Definir a propriedade
management.metrics.export.cloudwatch.enabled=false
permite desabilitar a exportação de métricas para o CloudWatch, enquanto a coleta de métricas será realizada e, se você tiver um módulo web conectado, endpoint /metrics
elas ainda estarão disponíveis.
Micrômetro coleta e fornece uma ampla variedade de métricas. Se alguns deles não forem necessários, você pode desativá-los. Você pode desabilitar tanto individualmente quanto por categorias inteiras. Assim, por exemplo, a propriedade irá desabilitar todas as métricas cujo id comece com . Observação: as métricas desabilitadas não serão coletadas.
management.metrics.enable.some.metric=false
some.metric
Executando todos os AWS
Outra surpresa o aguarda se você tentar executar o aplicativo com as configurações mínimas exigidas em todos os AWS. Para operação, os dados necessários da região onde o aplicativo está rodando. Como já sabemos, o que quer que não esteja explicitamente declarado, o SDK da AWS tentará obter dos metadados ... que não estão lá. Portanto, indicamos explicitamente a região desejada por meio da propriedade
cloud.aws.region.static=us-east-2
. Como no caso do nome da pilha (propriedade cloud.aws.stack.auto
), existe uma propriedade que é cloud.aws.region.auto
igual true
por padrão. Mas simplesmente definir o valor como falso não vai nos ajudar, já que o valor da região é necessário.
Além disso, como lembramos, as solicitações para AWS exigem credenciais, portanto, se você precisar transferir métricas para CloudWatch (ou fazer outras solicitações para AWS), você deve especificar explicitamente os parâmetros para as credenciaisvia, por exemplo, propriedades do aplicativo ou variáveis de ambiente.
A passagem pelas propriedades do aplicativo se parece com isto:
cloud.aws.credentials.access-key=YOUR_ACCESS_KEY
cloud.aws.credentials.secret-key=YOUR_SECRET_KEY
Resultado
Como eu acho que você deve ter notado, fazer todo o esquema funcionar e transferir as métricas do aplicativo para o CloudWatch não é tão difícil: são necessárias 3 dependências e 3 propriedades .
O mais importante está nos detalhes. Bibliotecas (frameworks) como Spring, AWS SDK tentam tornar a vida mais fácil e fazer todo o trabalho para nós o máximo possível, mas ao mesmo tempo, qualquer passo à parte pode levar ao aparecimento de um rastreamento de pilha, tentativas de entender por que as métricas não vão a lugar nenhum, por que o aplicativo não inicia de todo e como consertar isso. Uma seção com uma análise das nuances e uma descrição de alguns dos detalhes de como os serviços EC2 e CloudWatch funcionam, espero, facilitará sua compreensão do que está acontecendo.
Se falamos sobre o uso do CloudWatch em si, então, na minha opinião, esta é uma escolha bastante natural ao usar a infraestrutura da AWS.
As métricas são os olhos e os ouvidos de nosso aplicativo, mas isso não nega o fato de que você precisa entender como as métricas são coletadas, contadas e exibidas. Que tipo de dados você verá em seus gráficos. Este problema será especialmente agudo no caso de anomalias e análise de incidentes. Se falamos da biblioteca de micrômetros, vale a pena consultar a documentação , lá, por exemplo, é descrito com alguns detalhes sobre os tipos de medidores (Medidor).
Links
A troca de experiências nos permite dominar rapidamente várias abordagens, ferramentas, tecnologias e seguir em frente. Portanto, não posso ignorar os materiais mais úteis sobre o assunto, que não foram
citados durante o artigo: Spring Boot: Metrics With Micrometer e AWS CloudWatch
Spring Cloud. Usando Amazon Web Services. Configuração automática do Spring Boot
Spring in Action 5, Craig Walls, Manning
Popular sobre Amazon Web Services O
projeto concluído pode ser encontrado no GitHub .