Conecte aplicações Spring Boot ao Managed Service for Prometheus para monitorar continuamente a integridade e o desempenho. Este tópico descreve como configurar rapidamente essa integração.
Informações de fundo
Aplicações MVC tradicionais baseadas em SSM exigem configurações extensas, nas quais um pequeno erro pode causar falhas. O Spring Boot resolve esse problema com a autoconfiguração: se os pacotes JAR necessários estiverem presentes, o Spring Boot configura a aplicação automaticamente. Você também pode substituir as classes de autoconfiguração por configurações personalizadas para criar rapidamente aplicações de nível empresarial.
Um sistema de monitoramento abrangente para aplicações Spring Boot geralmente consiste nos seguintes componentes principais.
Collect monitoring data
Os métodos mais comuns para coletar dados de monitoramento são os modelos push e pull. O ecossistema de monitoramento do Prometheus é um exemplo clássico de sistema baseado em pull. Managed Service for Prometheus é um sistema típico baseado em pull. Aplicações e infraestrutura expõem dados de monitoramento por meio de uma interface compatível com OpenMetrics, e o Managed Service for Prometheus coleta periodicamente esses dados para armazenamento de longo prazo.
O OpenMetrics é um protocolo de métricas nativo da nuvem e altamente escalável que define o padrão para relatar métricas nativas da nuvem em escala. Ele suporta representação de texto e Protocol Buffers. O formato baseado em texto é mais comum e constitui o protocolo padrão que o Managed Service for Prometheus utiliza para a coleta de dados. O exemplo a seguir mostra o formato de representação de métricas baseado no OpenMetrics.
# TYPE acme_http_router_request_seconds summary
# UNIT acme_http_router_request_seconds seconds
# HELP acme_http_router_request_seconds Latency though all of ACME's HTTP request router.
acme_http_router_request_seconds_sum{path="/api/v1",method="GET"} 9036.32
acme_http_router_request_seconds_count{path="/api/v1",method="GET"} 807283.0
acme_http_router_request_seconds_created{path="/api/v1",method="GET"} 1605281325.0
acme_http_router_request_seconds_sum{path="/api/v2",method="POST"} 479.3
acme_http_router_request_seconds_count{path="/api/v2",method="POST"} 34.0
acme_http_router_request_seconds_created{path="/api/v2",method="POST"} 1605281325.0
# TYPE go_goroutines gauge
# HELP go_goroutines Number of goroutines that currently exist.
go_goroutines 69
# TYPE process_cpu_seconds counter
# UNIT process_cpu_seconds seconds
# HELP process_cpu_seconds Total user and system CPU time spent in seconds.
process_cpu_seconds_total 4.20072246e+06
# EOF
O modelo de dados de uma métrica é definido por um nome de métrica e um conjunto de pares chave-valor chamados rótulos. Pontos de dados com o mesmo nome de métrica e rótulos pertencem à mesma série temporal. Por exemplo, acme_http_router_request_seconds_sum{path="/api/v1",method="GET"} representa uma amostra de dados para a métrica chamada acme_http_router_request_seconds_sum, com um rótulo method cujo valor é GET. Cada amostra contém um valor Float64 e um carimbo de data/hora UNIX com precisão de milissegundos. Com o tempo, essas amostras coletadas formam as linhas dinâmicas em um gráfico.
A maioria dos componentes de infraestrutura no ecossistema nativo da nuvem pode expor métricas no formato de texto OpenMetrics. Para componentes sem suporte nativo, a comunidade Prometheus oferece uma vasta coleção de Exportadores do Prometheus. Esses componentes (ou Exportadores) respondem a solicitações periódicas de coleta do Managed Service for Prometheus para registrar seu status operacional no Managed Service for Prometheus para análise posterior. Use também os SDKs multilíngues do Managed Service for Prometheus para instrumentar seu código e integrar suas próprias métricas de negócios ao ecossistema Prometheus.
Data visualization and analysis
Após coletar métricas de aplicação e infraestrutura, consulte, analise e compare dados multidimensionais para entender o estado do sistema. O Grafana, ferramenta líder de visualização de dados de código aberto, oferece ampla variedade de tipos de gráficos e modelos. O Managed Service for Prometheus fornece um serviço Grafana totalmente gerenciado para consultar, analisar e visualizar seus dados de monitoramento.
Timely alerting and incident management
Quando um serviço corre risco de falha, o sistema de monitoramento deve notificar os administradores prontamente para que resolvam problemas ou os previnam proativamente, minimizando o impacto nos negócios. Ao analisar diferentes métricas e dados históricos, os administradores identificam e resolvem as causas raiz.
Visão geral do processo de integração
Para aplicações Spring Boot, a comunidade fornece o framework Spring Boot Actuator, que simplifica a instrumentação de código, a coleta de métricas e a saída para desenvolvedores Java. A partir do Spring Boot 2.0, o Actuator foi reconstruído sobre o Micrometer, fornecendo recursos de monitoramento mais poderosos e flexíveis. O Micrometer é uma fachada de métricas, análoga ao SLF4J para logs. Ao usar o Micrometer, as aplicações conectam-se a vários sistemas de monitoramento, como AppOptics, Datadog, Elastic, InfluxDB e Managed Service for Prometheus.
Ao mapear métricas de aplicações Java, o Micrometer usa a seguinte semântica para mapear seus tipos de métricas para os tipos usados pelo Managed Service for Prometheus:
|
Tipo de métrica do Micrometer |
Tipo de métrica do Managed Service for Prometheus |
Caso de uso típico |
|
Counter |
Counter |
Valor monotonicamente crescente. Por exemplo, contagem de visualizações de página (PV), visitantes únicos (UV) ou chamadas de API. |
|
Gauge |
Gauge |
Variável que flutua ao longo do tempo. Por exemplo, utilização de recursos, carga do sistema ou tamanho da fila de solicitações. |
|
Timer |
Histogram |
Distribuição estatística de dados, tipicamente para latência. Por exemplo, cálculo de latências P50, P90 e P99 para uma chamada de API. |
|
DistributionSummary |
Summary |
Distribuição estatística de dados, com finalidade semelhante à de um Histogram. |
O tipo de métrica Counter do Micrometer mapeia para o tipo Counter no Managed Service for Prometheus e descreve uma variável monotonicamente crescente, como o número de chamadas de API, acertos de cache ou visitas totais. Um Timer inclui logicamente um Counter. Se você usar um Timer para coletar tempos de resposta de uma API, ele também coletará o número de chamadas. Portanto, não especifique tanto um Timer quanto um Counter para a mesma API.
O tipo de métrica Gauge do Micrometer mapeia para o tipo Gauge no Managed Service for Prometheus e descreve uma variável que flutua continuamente dentro de um intervalo, como a utilização da CPU ou o número de tarefas em uma fila de pool de threads.
O tipo de métrica Timer do Micrometer mapeia para o tipo Histogram no Managed Service for Prometheus e descreve dados relacionados ao tempo, como a distribuição do tempo de resposta (RT) de uma API.
O tipo de métrica DistributionSummary do Micrometer mapeia para o tipo Summary no Managed Service for Prometheus. Semelhante a um Histogram, um Summary serve para distribuições estatísticas. No entanto, como a distribuição é calculada no lado do cliente antes de ser enviada ao Managed Service for Prometheus para armazenamento, os resultados do Summary não podem ser agregados em várias máquinas. Isso limita seu uso, pois não fornece uma visão global da distribuição de dados.
Integration workflow
Para conectar uma aplicação Spring Boot implantada em um cluster Kubernetes ao Managed Service for Prometheus, siga o processo de instrumentação de código>implantação da aplicação>descoberta de serviço.
Primeiro, adicione as dependências Maven necessárias do Spring Boot Actuator ao seu código e registre as métricas que deseja monitorar ou adicione anotações aos métodos em seus controladores.
Em seguida, implante a aplicação instrumentada no Kubernetes e registre o endpoint de coleta de métricas no Managed Service for Prometheus. Esse processo é conhecido como descoberta de serviço. O Managed Service for Prometheus fornece descoberta de serviço usando a definição de recurso personalizado (CRD) ServiceMonitor.
Por fim, após o Managed Service for Prometheus descobrir com êxito o endpoint de métricas da aplicação alvo, configure fontes de dados e crie painéis no Grafana. Configure também alertas com base em métricas principais.
Objetivos de monitoramento
Ao conectar uma aplicação Spring Boot em um cluster Kubernetes ao Managed Service for Prometheus, você atinge os seguintes objetivos:
Monitore o ponto de entrada do sistema: Acompanhe as principais métricas RED (Taxa, Erros, Duração) para APIs voltadas para o exterior em um serviço de frontend que lida com tráfego de clientes.
Monitore caminhos críticos do sistema: Observe objetos-chave no caminho crítico de serviços de backend, como o status da fila de um pool de threads ou a taxa de acerto de um Guava Cache em processo.
Monitore métricas personalizadas relevantes para o negócio: Implemente monitoramento para métricas específicas do seu negócio, como o número de visitantes únicos para uma API específica.
Monitore o desempenho da JVM: Mantenha o controle da coleta de lixo (GC) da JVM e do uso de memória.
Centralize o monitoramento: Agregue e exiba todas as métricas anteriores em um painel unificado e configure alertas para indicadores-chave.
Etapa 1: Configurar o Spring Boot Actuator
Este tópico usa uma aplicação de microsserviços nativa da nuvem criada com Spring Boot e Spring Cloud Alibaba para demonstrar como conectar uma aplicação de microsserviços Spring Boot em um cluster Kubernetes ao Managed Service for Prometheus.
-
Adicione as dependências do Spring Boot Actuator ao seu arquivo
pom.xml.<!-- spring-boot-actuator dependency --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <!-- prometheus dependency --> <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency> -
No arquivo
application.properties, adicione a seguinte configuração para expor a porta para dados de monitoramento. Neste exemplo, a porta é 8091.# Add the following configuration to application.properties to expose metrics spring.application.name=frontend management.server.port=8091 management.endpoints.web.exposure.include=* management.metrics.tags.application=${spring.application.name}Após a configuração bem-sucedida, acesse a porta 8091 da aplicação. Os dados de monitoramento no formato OpenMetrics estão disponíveis no caminho
/actuator/prometheusnesta porta.
Etapa 2: Instrumentar o código
Para coletar métricas RED para uma API, adicione a anotação @Timed ao método correspondente. O exemplo a seguir adiciona @Timed à API da página inicial.
@Timed(value = "main_page_request_duration", description = "Time taken to return main page", histogram = true)
@ApiOperation(value = "Home page", tags = {"Home page operations"})
@GetMapping("/")
public String index(Model model) {
model.addAttribute("products", productDAO.getProductList());
model.addAttribute("FRONTEND_APP_NAME", Application.APP_NAME);
model.addAttribute("FRONTEND_SERVICE_TAG", Application.SERVICE_TAG);
model.addAttribute("FRONTEND_IP", registration.getHost());
model.addAttribute("PRODUCT_APP_NAME", PRODUCT_APP_NAME);
model.addAttribute("PRODUCT_SERVICE_TAG", PRODUCT_SERVICE_TAG);
model.addAttribute("PRODUCT_IP", PRODUCT_IP);
model.addAttribute("new_version", StringUtils.isBlank(env));
return "index.html";
}
Aqui, value é o nome da métrica exposta em /actuator/prometheus, e histogram=true expõe uma métrica de histograma para a duração da solicitação da API, permitindo calcular distribuições de tempo de solicitação, como P90 e P99.
Se sua aplicação usar uma biblioteca de cache em processo, como o Guava Cache, e você quiser rastrear seu status de tempo de execução, envolva objetos-chave usando os métodos decoradores do Micrometer.
Modifying the Guava cache
Injete
MeterRegistry. O Spring Boot injeta automaticamente a implementaçãoPrometheusMeterRegistry.Envolva o cache local usando uma API utilitária, que é
GuavaCacheMetrics.monitorno código a seguir.Ative o registro de estatísticas de cache chamando o método
.recordStats().Nomeie o objeto de cache para gerar as métricas correspondentes.
@Resource
private static MeterRegistry meterRegistry;
private static final LoadingCache<String, String> REFRESH_CACHE = GuavaCacheMetrics.monitor(
meterRegistry,
CacheBuilder.newBuilder()
.recordStats()
.build(new CacheLoader<String, String>() {
@Override
public String load(String key) {
// Implement the specific load operation here.
return "";
}
}),
"refresh-cache");
Modifying the thread pool
Injete
MeterRegistry. A implementação específica injetada aqui éPrometheusMeterRegistry.Envolva o pool de threads usando uma API utilitária.
Nomeie o pool de threads para gerar as métricas correspondentes.
@Resource
private static MeterRegistry meterRegistry;
private static final ScheduledExecutorService REFRESH_EXECUTOR = ExecutorServiceMetrics.monitor(
meterRegistry,
Executors.newScheduledThreadPool(1,
new ThreadFactory() {
public Thread newThread(Runnable r) {
Thread thread = new Thread(r);
thread.setDaemon(true);
thread.setName("dubbo.outlier.refresh-" + thread.getId());
return thread;
}
}),
"refresh-executor"
);
Para monitorar métricas personalizadas específicas do negócio, injete MeterRegistry em seu bean e construa um Counter, Gauge ou Timer conforme suas necessidades. Registre-o no MeterRegistry para expor a métrica, conforme mostrado no exemplo a seguir.
@Service
public class DemoService {
Counter visitCounter;
public DemoService(MeterRegistry registry) {
visitCounter = Counter.builder("visit_counter")
.description("Number of visits to the site")
.register(registry);
}
public String visit() {
visitCounter.increment();
return "Hello World!";
}
}
Isso conclui as modificações de código necessárias. Agora, recrie a imagem da aplicação e implante-a em um cluster Kubernetes onde o Managed Service for Prometheus esteja instalado. Em seguida, configure um ServiceMonitor no console do Managed Service for Prometheus para ativar a descoberta de serviço. Para obter mais informações, consulte Observabilidade de Contêineres e Gerenciamento de instâncias.
Após configurar o ServiceMonitor, encontre a aplicação recém-registrada na lista Targets.
Na página Targets, se você vir default/frontend-service-monitor/0 (1/1 up) e o State for UP, isso indica que o endpoint de métricas (caminho: /actuator/prometheus) está funcionando corretamente e a configuração do ServiceMonitor está ativa.
Etapa 3: Configurar painéis
O Managed Service for Prometheus agora coleta e armazena os dados de monitoramento da sua aplicação. Configure painéis e alertas para visualizar os dados. Os seguintes modelos de painel da comunidade open-source do Grafana ajudam você a criar seu próprio painel de monitoramento.
Com esses modelos e o serviço Grafana integrado do Managed Service for Prometheus, crie um painel que consolide métricas-chave para desenvolvimento e operações diárias em uma única página. Por exemplo, um painel criado a partir desses modelos pode incluir uma visão geral, tempos de execução de componentes, uso de memória, memória heap e non-heap e status de GC geracional.
