Prefácio
Para um aplicativo de engenharia SpringBoot, um aplicativo SpringBoot que perde o monitoramento da JVM é como um cavalo selvagem correndo. Ele pode funcionar bem hoje, mas amanhã pode enlouquecer e nós, como mestre, não podemos controlá-lo. Isso também é verdadeiro para o aplicativo. fatal.
Quando o projeto SpringBoot é migrado para k8s, como monitorar o status dos recursos do projeto, como CPU, memória, disco e informações relacionadas à JVM, como memória da equipe, threads, carregamento de classe, etc., em comparação com a implantação direta do servidor, no ambiente k8s De acordo com o sistema de monitoramento original, ele não é mais aplicável, pois o aplicativo não é mais um servidor designado, mas também pode ser um cluster.
O que fazer então? Os pods são monitorados um por um?
Neste momento, lembrei que ao construir todo o sistema k8s, Grafana + Prometheus foi usado para monitorar todos os objetos k8s.
Grafana é uma ferramenta open source de visualização de dados desenvolvida na linguagem Go, que pode fazer monitoramento e estatísticas de dados, com função de alarme
O Prometheus é uma versão de código aberto de um sistema de monitoramento de código aberto desenvolvido pela SoundCloud. Em 2016, a Linux Foundation (Cloud Native Computing Foundation, CNCF) iniciada pelo Google incluiu o Prometheus como seu segundo maior projeto de código aberto (com uma sólida experiência).
A figura a seguir mostra o monitoramento de recursos de nós, pods e serviços k8s baseados em Grafana + Prometheus, através disso podemos realizar o monitoramento de recursos de hardware do nosso projeto Springboot.
A implementação do arquivo JSON é a seguinte:
Realizar monitoramento de recursos k8s com base em Grafana + Prometheus
De volta ao nosso tópico, como implementar o monitoramento JVM do projeto SpringBoot no k8s. Para projetos Java gerais, geralmente usamos as próprias ferramentas de monitoramento do jdk: jconsole
e jvisualvm
, ou usamos a linha de comando, jstat
etc.
Isso pode explicar a execução do projeto SpringBoot JVM状态是有可读取的入口的
. É possível gerar esses dados de status da JVM por meio de uma interface, usando Grafana + Prometheus como a operadora para visualizar o status da JVM do SpingBoot em k8s?
Deve ser possível. É por isso que escrevo.
princípio
Spring-Boot-Actuator
O SpringBoot vem com uma função de monitoramento Atuador, que pode ajudar a monitorar a operação interna do programa, como monitoramento de status, carregamento de bean, variáveis de ambiente, informações de log, informações de encadeamento, verificações de saúde, auditoria, estatísticas e rastreamento de HTTP. O
atuador também pode interagir com Integração de sistemas de monitoramento de aplicativos externos, como o Prometheus. Você pode escolher usar terminais HTTP ou JMX para gerenciar e monitorar aplicativos.
Atuador usa micrômetro para integrar o sistema de monitoramento de aplicativos externos já mencionado Prometheus. Isso torna possível integrar qualquer sistema de monitoramento de aplicativo com uma configuração muito pequena.
Verifique a documentação oficial do Spring-Boot-Actuator em detalhes
Descrição do princípio de implementação
Usado no projeto SpringBoot, os dados de estado, como jvm, são produzidos spring-boot-actor
de http
uma forma que o Prometheus armazena os dados de estado, como jvm, configurando o modo de dados de interface de leitura e, finalmente, Grafana
configura a Prometheus
fonte de dados nele, projeta gráficos relacionados e os lê e armazena por meio do Prometheus SQL os dados de estado de volta ao ícone de renderização da página 实现运行在k8s中的springboot应用jvm可视化监控
.
alcançar
Descrição ambiental
suave | versão |
---|---|
Java | 1.8 |
springboot | 2.1.0.RELEASE |
Spring-Boot-Actuator | 2.1.0.RELEASE |
grafana-amd64 | v5.0.4 |
Prometeu | v2.0.0 |
k8s | 1.16.0 |
Springboot apresenta dependências
<!-- monitor -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<version>2.1.0.RELEASE</version>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
<version>1.1.0</version>
</dependency>
configuração do aplicativo
# Actuator config
management.endpoints.web.exposure.include=*
management.metrics.tags.application=${spring.application.name}
management.metrics.export.prometheus.enabled=true
management.endpoint.health.show-details=always
management.endpoints.web.exposure.exclude=env,beans
Ver dados do indicador
Acessohttp://localhost:8080/actuator/prometheus
localhost:8080: 项目访问地址
Você pode ver a seguinte saída:
# HELP rabbitmq_published_total
# TYPE rabbitmq_published_total counter
rabbitmq_published_total{
application="center",name="rabbit",} 0.0
# HELP tomcat_global_sent_bytes_total
# TYPE tomcat_global_sent_bytes_total counter
tomcat_global_sent_bytes_total{
application="center",name="http-nio-8080",} 31.0
# HELP jvm_gc_max_data_size_bytes Max size of old generation memory pool
# TYPE jvm_gc_max_data_size_bytes gauge
jvm_gc_max_data_size_bytes{
application="center",} 2.803367936E9
# HELP tomcat_threads_current_threads
# TYPE tomcat_threads_current_threads gauge
tomcat_threads_current_threads{
application="center",name="http-nio-8084",} 10.0
# HELP tomcat_sessions_active_current_sessions
# TYPE tomcat_sessions_active_current_sessions gauge
tomcat_sessions_active_current_sessions{
application="center",} 0.0
# HELP rabbitmq_channels
# TYPE rabbitmq_channels gauge
rabbitmq_channels{
application="center",name="rabbit",} 1.0
# HELP system_load_average_1m The sum of the number of runnable entities queued to available processors and the number of runnable entities running on the available processors averaged over a period of time
# TYPE system_load_average_1m gauge
system_load_average_1m{
application="center",} 1.53
# HELP tomcat_sessions_rejected_sessions_total
# TYPE tomcat_sessions_rejected_sessions_total counter
tomcat_sessions_rejected_sessions_total{
application="center",} 0.0
# HELP tomcat_threads_busy_threads
# TYPE tomcat_threads_busy_threads gauge
tomcat_threads_busy_threads{
application="center",name="http-nio-8084",} 1.0
# HELP tomcat_sessions_created_sessions_total
# TYPE tomcat_sessions_created_sessions_total counter
tomcat_sessions_created_sessions_total{
application="center",} 0.0
# HELP jvm_gc_memory_promoted_bytes_total Count of positive increases in the size of the old generation memory pool before GC to after GC
# TYPE jvm_gc_memory_promoted_bytes_total counter
jvm_gc_memory_promoted_bytes_total{
application="center",} 1.37307128E8
# HELP jvm_buffer_count_buffers An estimate of the number of buffers in the pool
# TYPE jvm_buffer_count_buffers gauge
jvm_buffer_count_buffers{
application="center",id="direct",} 7.0
jvm_buffer_count_buffers{
application="center",id="mapped",} 0.0
configuração prometheus
Adicionar atuador para ler a fonte
- job_name: 'center-actuator'
metrics_path: /actuator/prometheus
static_configs:
- targets: ['192.168.1.240:8080']
job_name
: Defina o nome exclusivo da tarefa prometheus, customize
metrics_path
: caminho de acesso, atuador geralmente conserte isso
targets
: coleta de entrada de acesso de serviço
Visite Prometheus
Colocação de Grafana
JSON do painel de monitoramento springboot
efeito:
Resumindo
Por meio da operação acima, não é mais um problema monitorar o aplicativo springboot JVM no k8s. Mesmo assim, os dados de monitoramento podem ser persistentes e alarmes automáticos podem ser realizados. Acho que enquanto o k8s for aplicado, é melhor fazer persistente No momento, a melhor solução ainda é a melhor solução Grafana+Prometheus
. Em segundo lugar, algumas pessoas podem perguntar como aquela pilha fio visão específica, a situação interna memória heap, este é o caso atualmente usam Arthas , 基于arthas 实现线上应用的具体调优
.