Minha demonstração do OpenTelemetry Tracing apresenta dois componentes do Spring Boot. Um usa o agente Java, e notei um comportamento diferente quando o atualizei recentemente da v1.x para a v2.x. No outro, estou usando o Micrometer Tracing porque compilo para o GraalVM nativo, e ele não consegue processar agentes Java.   Minha demonstração do OpenTelemetry  Nesta postagem, quero comparar essas três abordagens: Java agent v1, Java agent v2 e Micrometer Tracing.  A aplicação base e sua infraestrutura  Usarei o mesmo aplicativo base: um aplicativo Spring Boot simples, codificado em Kotlin. Ele oferece um único endpoint.  A função além do ponto final é chamada  entry()  Ele chama outra função chamada  intermediate()  Este último usa uma instância   , a substituição de   , para fazer uma chamada para o ponto de extremidade acima WebClient RestTemplate  Para evitar loop infinito, passo um cabeçalho de solicitação personalizado: se a função   o encontrar, ela não prossegue.  entry()  Isso se traduz no seguinte código:   @SpringBootApplication class Agent1xApplication @RestController class MicrometerController { private val logger = LoggerFactory.getLogger(MicrometerController::class.java) @GetMapping("/{message}") fun entry(@PathVariable message: String, @RequestHeader("X-done") done: String?) { logger.info("entry: $message") if (done == null) intermediate() } fun intermediate() { logger.info("intermediate") RestClient.builder() .baseUrl("http://localhost:8080/done") .build() .get() .header("X-done", "true") .retrieve() .toBodilessEntity() } }  Para cada configuração, verificarei dois estágios: o estágio primário, com o OpenTelemetry habilitado, e um estágio de personalização para criar intervalos internos adicionais.  Rastreamento de micrômetro  O Micrometer Tracing deriva do   , uma "fachada de observabilidade de aplicativos independente de fornecedor". Micrometer  O Micrometer Tracing fornece uma fachada simples para as bibliotecas de rastreadores mais populares, permitindo que você instrumente seu código de aplicativo baseado em JVM sem bloqueio de fornecedor. Ele foi projetado para adicionar pouca ou nenhuma sobrecarga à sua atividade de coleta de rastreamento, ao mesmo tempo em que maximiza a portabilidade do seu esforço de rastreamento.  --  Site de rastreamento de micrômetro  Para começar com o Micrometer Tracing, é necessário adicionar algumas dependências:  Atuador de inicialização de mola,  org.springframework.boot:spring-boot-starter-actuator  Rastreamento de micrômetro em si,  io.micrometer:micrometer-tracing  Uma "ponte" para a API de backend de rastreamento de alvos. No meu caso, é OpenTelemetry, portanto  io.micrometer:micrometer-tracing-bridge-otel  Um exportador concreto para o backend,  io.opentelemetry:opentelemetry-exporter-otlp  Não precisamos de uma BOM porque as versões já estão definidas no pai do Spring Boot.  No entanto, precisamos de dois parâmetros de configuração de tempo de execução: para onde os traces devem ser enviados e qual é o nome do componente. Eles são governados pelas variáveis   e   . MANAGEMENT_OTLP_TRACING_ENDPOINT SPRING_APPLICATION_NAME   services: jaeger: image: jaegertracing/all-in-one:1.55 environment: - COLLECTOR_OTLP_ENABLED=true #1 ports: - "16686:16686" micrometer-tracing: build: dockerfile: Dockerfile-micrometer environment: MANAGEMENT_OTLP_TRACING_ENDPOINT: http://jaeger:4318/v1/traces #2 SPRING_APPLICATION_NAME: micrometer-tracing #3  Habilitar o coletor OpenTelemetry para Jaeger  URL completa para o ponto de extremidade gRPC do Jaeger OpenTelemetry  Defina o nome do serviço do OpenTelemetry  Aqui está o resultado:   Sem nenhuma personalização, o Micrometer cria intervalos ao receber e enviar solicitações HTTP.  O framework precisa injetar mágica no   para envio. Devemos deixar o primeiro instanciar o último para isso: RestClient   @SpringBootApplication class MicrometerTracingApplication { @Bean fun restClient(builder: RestClient.Builder) = builder.baseUrl("http://localhost:8080/done").build() }  Podemos criar spans manuais de várias maneiras, uma por meio da própria API OpenTelemetry. No entanto, a configuração requer muito código boilerplate. A maneira mais direta é a   do Micrometer. Seu principal benefício é usar uma única API que gerencia   e   .  API de Observação métricas traces  Aqui está o código atualizado:   class MicrometerController( private val restClient: RestClient, private val registry: ObservationRegistry ) { @GetMapping("/{message}") fun entry(@PathVariable message: String, @RequestHeader("X-done") done: String?) { logger.info("entry: $message") val observation = Observation.start("entry", registry) if (done == null) intermediate(observation) observation.stop() } fun intermediate(parent: Observation) { logger.info("intermediate") val observation = Observation.createNotStarted("intermediate", registry) .parentObservation(parent) .start() restClient.get() .header("X-done", "true") .retrieve() .toBodilessEntity() observation.stop() } }  As chamadas de observação adicionadas refletem nos traços gerados:   Agente OpenTelemetry v1  Uma alternativa ao Micrometer Tracing é o   genérico. Seu principal benefício é que ele não impacta nem o código nem os desenvolvedores; o agente é uma preocupação puramente de escopo de tempo de execução. OpenTelemetry Java Agent   java -javaagent:opentelemetry-javaagent.jar agent-one-1.0-SNAPSHOT.jar  O agente obedece à configuração do OpenTelemetry com variáveis de ambiente:   services: agent-1x: build: dockerfile: Dockerfile-agent1 environment: OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4317 #1 OTEL_RESOURCE_ATTRIBUTES: service.name=agent-1x #2 OTEL_METRICS_EXPORTER: none #3 OTEL_LOGS_EXPORTER: none #4 ports: - "8081:8080"  Defina o protocolo, o domínio e a porta. A biblioteca anexa  /v1/traces  Defina o nome do serviço do OpenTelemetry  Não exporte nem as métricas nem os logs  Sem mais configurações, obtemos os seguintes rastros:   O agente rastreia automaticamente as solicitações, tanto recebidas quanto enviadas,   . Os rastreamentos são corretamente aninhados uns dentro dos outros, de acordo com a pilha de chamadas. Para rastrear funções adicionais, precisamos adicionar uma dependência à nossa base de código,   . Agora podemos anotar funções não rastreadas anteriormente com a anotação   .  bem como as funções marcadas com anotações relacionadas ao Spring io.opentelemetry.instrumentation:opentelemetry-instrumentation-annotations @WithSpan  A parte   governa o rótulo do trace, enquanto o   é traduzido como um atributo   . Se o value for definido como uma string vazia, que é o padrão, ele emite o nome da função. Para meus propósitos, valores padrão são bons o suficiente. value() kind span.kind   @WithSpan fun intermediate() { logger.info("intermediate") RestClient.builder() .baseUrl("http://localhost:8080/done") .build() .get() .header("X-done", "true") .retrieve() .toBodilessEntity() }  Ele produz o novo rastreamento esperado   :  intermediate()  Agente OpenTelemetry v2  A OpenTelemetry lançou uma nova versão principal do agente em janeiro deste ano. Atualizei minha demo com ela; os traces agora são criados somente quando o aplicativo recebe e envia solicitações.   Quanto à versão anterior, podemos adicionar traces com a anotação   . A única diferença é que também precisamos anotar a função   . Ela não é rastreada por padrão.  @WithSpan entry()  Discussão  O Spring se tornou bem-sucedido por dois motivos: ele simplificou soluções complexas,   , EJBs 2, e forneceu uma camada de abstração sobre bibliotecas concorrentes. O Micrometer Tracing começou como uma camada de abstração sobre Zipkin e Jaeger, e fazia todo o sentido. Este argumento se torna discutível com o OpenTelemetry sendo suportado pela maioria das bibliotecas em linguagens de programação e coletores de rastreamento. A API de observação ainda é um benefício considerável do Micrometer Tracing, pois usa uma única API sobre Métricas e Rastreamentos. ou seja  No lado do Java Agent, a configuração do OpenTelemetry é similar em todas as pilhas de tecnologia e bibliotecas - variáveis de ambiente. Fiquei um pouco decepcionado quando atualizei da v1 para a v2, pois o novo agente não é compatível com Spring: funções anotadas com Spring não são rastreadas por padrão.  No final, é uma decisão sábia. É muito melhor ser explícito sobre os spans que você quer do que remover alguns que você não quer ver.    . Obrigado a   por sua ajuda e sua avaliação Jonatan Ivanov  O código-fonte completo desta postagem pode ser encontrado no GitHub:   https://github.com/ajavageek/boot-tracing?embedable=true   Para ir mais longe:   Demonstração do OpenTelemetry Tracing   Rastreamento de micrômetro   Rastros de Telemetria Aberta   Integração Java OpenTelemetry Exemplos de Java OpenTelemetry   Rastreamento distribuído com Spring Boot 3 — Micrometer vs OpenTelemetry   Observabilidade com Spring Boot 3   Originalmente publicado em   em 3 de agosto de 2024 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Este áudio é produzido no idioma original da história!

Rastreamento OpenTelemetry no Spring Boot: Escolhendo entre Java Agent e Micrômetro para

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Como melhorar seu fluxo de trabalho em 10 vezes: 17 aplicativos essenciais

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Como melhorar seu fluxo de trabalho em 10 vezes: 17 aplicativos essenciais

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps