1. Introdução
Última atualização:15/07/2022
Observabilidade do aplicativo
Observabilidade e OpenTelemetry
Observabilidade é o termo usado para descrever um atributo de um sistema. Um sistema com observabilidade permite que as equipes depurem ativamente o sistema. Nesse contexto, três pilares da observabilidade, registros, métricas e rastros, são a instrumentação fundamental para que o sistema adquira a observabilidade.
O OpenTelemetry é um conjunto de especificações, bibliotecas e agentes que aceleram a instrumentação e exportação de dados de telemetria (registros, métricas e traces) necessários para a observabilidade. O OpenTelemetry é um projeto de padrão aberto e orientado pela comunidade no CNCF. Ao utilizar as bibliotecas fornecidas pelo projeto e pelo ecossistema, os desenvolvedores podem instrumentar os aplicativos de forma neutra para o fornecedor e para várias arquiteturas.
Além dos três pilares da observabilidade, o perfil contínuo é outro componente importante para a observabilidade e expande a base de usuários do setor. O Cloud Profiler é um dos originadores e oferece uma interface fácil para detalhar as métricas de desempenho nas pilhas de chamadas do aplicativo.
Este codelab é a parte 1 da série e aborda a instrumentação de rastros distribuídos em microsserviços com o OpenTelemetry e o Cloud Trace. A Parte 2 vai abordar a criação contínua de perfis com o Cloud Profiler.
Rastreamento distribuído
Entre registros, métricas e rastros, o rastro é a telemetria que informa a latência de uma parte específica do processo no sistema. Especialmente na era dos microsserviços, o rastreamento distribuído é o principal impulsionador para encontrar gargalos de latência no sistema distribuído geral.
Ao analisar rastros distribuídos, a visualização de dados de rastro é a chave para entender as latências gerais do sistema de relance. No rastro distribuído, processamos um conjunto de chamadas para processar uma única solicitação para o ponto de entrada do sistema em uma forma de rastro que contém vários períodos.
A duração representa uma unidade individual de trabalho realizada em um sistema distribuído, registrando os horários de início e término. As spans geralmente têm relações hierárquicas entre si. Na imagem abaixo, todas as spans menores são filhas de uma span /messages grande e são reunidas em um Trace que mostra o caminho do trabalho em um sistema.
O Google Cloud Trace é uma das opções de back-end de rastreamento distribuído e está bem integrado a outros produtos do Google Cloud.
O que você vai criar
Neste codelab, você vai instrumentar informações de rastreamento nos serviços chamados "Shakespeare application" (também conhecido como Shakesapp) que são executados em um cluster do Google Kubernetes Engine. A arquitetura do Shakesapp é descrita abaixo:
- O Loadgen envia uma string de consulta para o cliente em HTTP
- Os clientes transmitem a consulta do loadgen para o servidor em gRPC
- O servidor aceita a consulta do cliente, busca todas as obras de Shakespeare em formato de texto no Google Cloud Storage, pesquisa as linhas que contêm a consulta e retorna o número da linha que corresponde ao cliente.
Você vai instrumentar as informações de rastreamento em toda a solicitação. Depois disso, você vai incorporar um agente de perfil no servidor e investigar o gargalo.
O que você vai aprender
- Como começar a usar as bibliotecas do OpenTelemetry Trace no projeto Go
- Como criar um intervalo com a biblioteca
- Como propagar contextos de extensão entre os componentes do app
- Como enviar dados de trace para o Cloud Trace
- Como analisar o rastro no Cloud Trace
Este codelab explica como instrumentar seus microsserviços. Para facilitar a compreensão, este exemplo contém apenas três componentes (gerador de carga, cliente e servidor), mas você pode aplicar o mesmo processo explicado neste codelab a sistemas mais complexos e grandes.
O que é necessário
- Conhecimento básico de Go
- Conhecimento básico do Kubernetes
2. Configuração e requisitos
Configuração de ambiente autoguiada
Se você ainda não tem uma Conta do Google (Gmail ou Google Apps), crie uma. Faça login no Console do Google Cloud Platform ( console.cloud.google.com) e crie um novo projeto.
Se você já tiver um projeto, clique no menu suspenso de seleção no canto superior esquerdo do console:
e clique no botão "NEW PROJECT" na caixa de diálogo exibida para criar um novo projeto:
Se você ainda não tiver um projeto, uma caixa de diálogo como esta será exibida para criar seu primeiro:
A caixa de diálogo de criação de projeto subsequente permite que você insira os detalhes do novo projeto:
Lembre-se do código do projeto, um nome exclusivo em todos os projetos do Google Cloud. O nome acima já foi escolhido e não servirá para você. Ele será mencionado mais adiante neste codelab como PROJECT_ID.
Em seguida, se ainda não tiver feito isso, ative o faturamento no console do desenvolvedor para usar os recursos do Google Cloud e ative a API Cloud Trace.
A execução por meio deste codelab terá um custo baixo, mas poderá ser mais se você decidir usar mais recursos ou se deixá-los em execução. Consulte a seção "limpeza" no final deste documento. Os preços do Google Cloud Trace, do Google Kubernetes Engine e do Google Artifact Registry estão indicados na documentação oficial.
- Preços do pacote de operações do Google Cloud | Pacote de operações
- Preços | Documentação do Kubernetes Engine
- Preços do Artifact Registry | Documentação do Artifact Registry
Novos usuários do Google Cloud Platform estão qualificados para uma avaliação gratuita de US$ 300, o que torna este codelab totalmente gratuito.
Configuração do Google Cloud Shell
Embora o Google Cloud e o Google Cloud Trace possam ser operados remotamente em seu laptop, neste codelab vamos usar o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.
O Cloud Shell é uma máquina virtual com base em Debian que contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Isso significa que tudo que você precisa para este codelab é um navegador (sim, funciona em um Chromebook).
Para ativar o Cloud Shell no Console do Cloud, basta clicar em Ativar o Cloud Shell 
. O provisionamento e a conexão ao ambiente levam apenas alguns instantes.
Depois de se conectar ao Cloud Shell, você já estará autenticado e o projeto estará configurado com seu PROJECT_ID.
gcloud auth list
Resposta ao comando
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
Resposta ao comando
[core] project = <PROJECT_ID>
Se, por algum motivo, o projeto não estiver definido, basta emitir o seguinte comando:
gcloud config set project <PROJECT_ID>
Quer encontrar seu PROJECT_ID? Veja qual ID você usou nas etapas de configuração ou procure-o no painel do Console do Cloud:
O Cloud Shell também define algumas variáveis de ambiente por padrão, o que pode ser útil ao executar comandos futuros.
echo $GOOGLE_CLOUD_PROJECT
Resposta ao comando
<PROJECT_ID>
Defina a zona padrão e a configuração do projeto:
gcloud config set compute/zone us-central1-f
É possível escolher uma variedade de zonas diferentes. Para mais informações, consulte Regiões e zonas.
Configuração de idioma do Go
Neste codelab, usamos o Go para todo o código-fonte. Execute o comando a seguir no Cloud Shell e confirme se a versão do Go é 1.17 ou mais recente.
go version
Resposta ao comando
go version go1.18.3 linux/amd64
Configurar um cluster do Google Kubernetes
Neste codelab, você vai executar um cluster de microsserviços no Google Kubernetes Engine (GKE). O processo deste codelab é o seguinte:
- Fazer o download do projeto de referência no Cloud Shell
- Criar microsserviços em contêineres
- Fazer upload de contêineres para o Google Artifact Registry (GAR)
- Implantar contêineres no GKE
- Modificar o código-fonte dos serviços para a instrumentação de rastreamento
- Acesse a etapa 2
Ativar o Kubernetes Engine
Primeiro, configuramos um cluster do Kubernetes em que o Shakesapp é executado no GKE. Portanto, precisamos ativar o GKE. Acesse o menu "Kubernetes Engine" e pressione o botão ATIVAR.
Agora você está pronto para criar um cluster do Kubernetes.
Criar cluster do Kubernetes
No Cloud Shell, execute o seguinte comando para criar um cluster do Kubernetes. Confirme se o valor da zona está na região que você vai usar para a criação do repositório do Artifact Registry. Mude o valor da zona us-central1-f se a região do repositório não estiver cobrindo a zona.
gcloud container clusters create otel-trace-codelab2 \ --zone us-central1-f \ --release-channel rapid \ --preemptible \ --enable-autoscaling \ --max-nodes 8 \ --no-enable-ip-alias \ --scopes cloud-platform
Resposta ao comando
Note: Your Pod address range (`--cluster-ipv4-cidr`) can accommodate at most 1008 node(s). Creating cluster otel-trace-codelab2 in us-central1-f... Cluster is being health-checked (master is healthy)...done. Created [https://container.googleapis.com/v1/projects/development-215403/zones/us-central1-f/clusters/otel-trace-codelab2]. To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-central1-f/otel-trace-codelab2?project=development-215403 kubeconfig entry generated for otel-trace-codelab2. NAME: otel-trace-codelab2 LOCATION: us-central1-f MASTER_VERSION: 1.23.6-gke.1501 MASTER_IP: 104.154.76.89 MACHINE_TYPE: e2-medium NODE_VERSION: 1.23.6-gke.1501 NUM_NODES: 3 STATUS: RUNNING
Configuração do Artifact Registry e do skaffold
Agora temos um cluster do Kubernetes pronto para implantação. Em seguida, preparamos um registro de contêineres para enviar e implantar contêineres. Para essas etapas, precisamos configurar um Artifact Registry (GAR) e o skaffold para usá-lo.
Configuração do Artifact Registry
Navegue até o menu "Artifact Registry" e pressione o botão ENABLE.
Depois de alguns instantes, o navegador de repositório do GAR vai aparecer. Clique no botão "CREATE REPOSITORY" e insira o nome do repositório.
Neste codelab, vou chamar o novo repositório de trace-codelab. O formato do artefato é "Docker" e o tipo de local é "Região". Escolha a região próxima à que você definiu como zona padrão do Google Compute Engine. Por exemplo, este exemplo escolheu "us-central1-f" acima, então aqui escolhemos "us-central1 (Iowa)". Em seguida, clique no botão "CRIAR".
Agora você vai encontrar "trace-codelab" no navegador do repositório.
Vamos voltar aqui mais tarde para verificar o caminho do registro.
Configuração do Skaffold
O Skaffold é uma ferramenta útil para criar microsserviços executados no Kubernetes. Ele lida com o fluxo de trabalho de criação, envio e implantação de contêineres de aplicativos com um pequeno conjunto de comandos. Por padrão, o Skaffold usa o Docker Registry como registro de contêineres. Portanto, você precisa configurar o Skaffold para reconhecer o GAR ao enviar contêineres para.
Abra o Cloud Shell novamente e confirme se o Skaffold está instalado. O Cloud Shell instala o Skaffold no ambiente por padrão. Execute o comando a seguir e confira a versão do skaffold.
skaffold version
Resposta ao comando
v1.38.0
Agora, você pode registrar o repositório padrão para que o skaffold use. Para acessar o caminho do registro, acesse o painel do Artifact Registry e clique no nome do repositório que você acabou de configurar na etapa anterior.
Em seguida, você vai ver trilhas de navegação estrutural na parte de cima da página. Clique no ícone 
para copiar o caminho do registro para a área de transferência.
Ao clicar no botão de cópia, a caixa de diálogo na parte de baixo do navegador aparece com a mensagem:
"us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab" foi copiado
Volte ao Cloud Shell. Execute o comando skaffold config set default-repo com o valor que você acabou de copiar do painel.
skaffold config set default-repo us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab
Resposta ao comando
set value default-repo to us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab for context gke_stackdriver-sandbox-3438851889_us-central1-b_stackdriver-sandbox
Além disso, você precisa configurar o registro para a configuração do Docker. Execute este comando:
gcloud auth configure-docker us-central1-docker.pkg.dev --quiet
Resposta ao comando
{
"credHelpers": {
"gcr.io": "gcloud",
"us.gcr.io": "gcloud",
"eu.gcr.io": "gcloud",
"asia.gcr.io": "gcloud",
"staging-k8s.gcr.io": "gcloud",
"marketplace.gcr.io": "gcloud",
"us-central1-docker.pkg.dev": "gcloud"
}
}
Adding credentials for: us-central1-docker.pkg.dev
Agora você pode seguir para a próxima etapa e configurar um contêiner do Kubernetes no GKE.
Resumo
Nesta etapa, você configura o ambiente do codelab:
- Configurar o Cloud Shell
- Criou um repositório do Artifact Registry para o registro de contêineres
- Configurar o Skaffold para usar o registro de contêineres
- Crie um cluster do Kubernetes em que os microsserviços do codelab são executados.
A seguir
Na próxima etapa, você vai criar, enviar e implantar seus microsserviços no cluster.
3. Criar, enviar e implantar os microsserviços
Fazer o download do material do codelab
Na etapa anterior, configuramos todos os pré-requisitos para este codelab. Agora você está pronto para executar microsserviços completos. O material do codelab está hospedado no GitHub. Faça o download dele no ambiente do Cloud Shell com o comando git abaixo.
cd ~ git clone https://github.com/ymotongpoo/opentelemetry-trace-codelab-go.git cd opentelemetry-trace-codelab-go
A estrutura de diretórios do projeto é a seguinte:
.
├── README.md
├── step0
│ ├── manifests
│ ├── proto
│ ├── skaffold.yaml
│ └── src
├── step1
│ ├── manifests
│ ├── proto
│ ├── skaffold.yaml
│ └── src
├── step2
│ ├── manifests
│ ├── proto
│ ├── skaffold.yaml
│ └── src
├── step3
│ ├── manifests
│ ├── proto
│ ├── skaffold.yaml
│ └── src
├── step4
│ ├── manifests
│ ├── proto
│ ├── skaffold.yaml
│ └── src
├── step5
│ ├── manifests
│ ├── proto
│ ├── skaffold.yaml
│ └── src
└── step6
├── manifests
├── proto
├── skaffold.yaml
└── src
- manifests: arquivos de manifesto do Kubernetes
- proto: definição de proto para a comunicação entre cliente e servidor
- src: diretórios para o código-fonte de cada serviço
- skaffold.yaml: arquivo de configuração do Skaffold
Neste codelab, você vai atualizar o código-fonte localizado na pasta step0. Você também pode consultar o código-fonte nas pastas step[1-6] para conferir as respostas nas etapas a seguir. A Parte 1 abrange da etapa 0 à 4, e a Parte 2 abrange as etapas 5 e 6.
Executar o comando skaffold
Por fim, você está pronto para criar, enviar e implantar todo o conteúdo no cluster do Kubernetes que acabou de criar. Parece que isso contém várias etapas, mas o skaffold faz tudo por você. Vamos tentar fazer isso com o seguinte comando:
cd step0 skaffold dev
Assim que o comando for executado, você vai ver a saída do registro de docker build e poderá confirmar que elas foram enviadas ao registro.
Resposta ao comando
... ---> Running in c39b3ea8692b ---> 90932a583ab6 Successfully built 90932a583ab6 Successfully tagged us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/serverservice:step1 The push refers to repository [us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/serverservice] cc8f5a05df4a: Preparing 5bf719419ee2: Preparing 2901929ad341: Preparing 88d9943798ba: Preparing b0fdf826a39a: Preparing 3c9c1e0b1647: Preparing f3427ce9393d: Preparing 14a1ca976738: Preparing f3427ce9393d: Waiting 14a1ca976738: Waiting 3c9c1e0b1647: Waiting b0fdf826a39a: Layer already exists 88d9943798ba: Layer already exists f3427ce9393d: Layer already exists 3c9c1e0b1647: Layer already exists 14a1ca976738: Layer already exists 2901929ad341: Pushed 5bf719419ee2: Pushed cc8f5a05df4a: Pushed step1: digest: sha256:8acdbe3a453001f120fb22c11c4f6d64c2451347732f4f271d746c2e4d193bbe size: 2001
Após o envio de todos os contêineres de serviço, as implantações do Kubernetes começam automaticamente.
Resposta ao comando
sha256:b71fce0a96cea08075dc20758ae561cf78c83ff656b04d211ffa00cedb77edf8 size: 1997 Tags used in deployment: - serverservice -> us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/serverservice:step4@sha256:8acdbe3a453001f120fb22c11c4f6d64c2451347732f4f271d746c2e4d193bbe - clientservice -> us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/clientservice:step4@sha256:b71fce0a96cea08075dc20758ae561cf78c83ff656b04d211ffa00cedb77edf8 - loadgen -> us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/loadgen:step4@sha256:eea2e5bc8463ecf886f958a86906cab896e9e2e380a0eb143deaeaca40f7888a Starting deploy... - deployment.apps/clientservice created - service/clientservice created - deployment.apps/loadgen created - deployment.apps/serverservice created - service/serverservice created
Após a implantação, os registros do aplicativo serão emitidos para o stdout em cada contêiner, como este:
Resposta ao comando
[client] 2022/07/14 06:33:15 {"match_count":3040}
[loadgen] 2022/07/14 06:33:15 query 'love': matched 3040
[client] 2022/07/14 06:33:15 {"match_count":3040}
[loadgen] 2022/07/14 06:33:15 query 'love': matched 3040
[client] 2022/07/14 06:33:16 {"match_count":3040}
[loadgen] 2022/07/14 06:33:16 query 'love': matched 3040
[client] 2022/07/14 06:33:19 {"match_count":463}
[loadgen] 2022/07/14 06:33:19 query 'tear': matched 463
[loadgen] 2022/07/14 06:33:20 query 'world': matched 728
[client] 2022/07/14 06:33:20 {"match_count":728}
[client] 2022/07/14 06:33:22 {"match_count":463}
[loadgen] 2022/07/14 06:33:22 query 'tear': matched 463
Neste ponto, você quer ver todas as mensagens do servidor. Pronto. Agora você pode começar a instrumentar seu aplicativo com o OpenTelemetry para rastreamento distribuído dos serviços.
Antes de começar a instrumentação do serviço, desligue o cluster com Ctrl-C.
Resposta ao comando
...
[client] 2022/07/14 06:34:57 {"match_count":1}
[loadgen] 2022/07/14 06:34:57 query 'what's past is prologue': matched 1
^CCleaning up...
- W0714 06:34:58.464305 28078 gcp.go:120] WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead.
- To learn more, consult https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke
- deployment.apps "clientservice" deleted
- service "clientservice" deleted
- deployment.apps "loadgen" deleted
- deployment.apps "serverservice" deleted
- service "serverservice" deleted
Resumo
Nesta etapa, você preparou o material do codelab no seu ambiente e confirmou que o skaffold é executado conforme o esperado.
A seguir
Na próxima etapa, você vai modificar o código-fonte do serviço loadgen para instrumentar as informações de rastreamento.
4. Instrumentação para HTTP
Conceito de instrumentação e propagação de rastros
Antes de editar o código-fonte, vamos explicar brevemente como os rastros distribuídos funcionam em um diagrama simples.
Neste exemplo, instrumentamos o código para exportar informações de trace e span para o Cloud Trace e propagar o contexto do trace pela solicitação do serviço loadgen para o serviço do servidor.
Os aplicativos precisam enviar metadados de trace, como ID do trace e ID do período, para que o Cloud Trace monte todos os períodos que têm o mesmo ID do trace em um único trace. Além disso, o aplicativo precisa propagar contextos de rastreamento (a combinação do ID de rastreamento e do ID de período do período pai) ao solicitar serviços downstream para que eles saibam qual contexto de rastreamento está sendo processado.
O OpenTelemetry ajuda você a:
- para gerar IDs exclusivos de trace e de span
- para exportar o ID do Trace e do Span para o back-end
- para propagar contextos de rastreamento para outros serviços
- para incorporar metadados extras que ajudam a analisar rastros
Componentes no rastreamento do OpenTelemetry
O processo para instrumentar o trace do aplicativo com o OpenTelemetry é o seguinte:
- Criar um exportador
- Crie um TracerProvider que associe o exportador em 1 e defina-o como global.
- Definir TextMapPropagaror para definir o método de propagação
- Conseguir o Tracer do TracerProvider
- Gerar intervalo no Tracer
No momento, você não precisa entender as propriedades detalhadas em cada componente, mas o mais importante é lembrar:
- O exportador aqui é conectável ao TracerProvider.
- O TracerProvider contém toda a configuração relacionada à amostragem e exportação de rastros.
- Todos os rastros são agrupados no objeto Tracer
Com esse entendimento, vamos passar para o trabalho de programação real.
Primeiro período do instrumento
Serviço de gerador de carga do instrumento
Para abrir o editor do Cloud Shell, pressione o botão 
no canto superior direito do Cloud Shell. Abra step0/src/loadgen/main.go no explorador no painel esquerdo e encontre a função principal.
step0/src/loadgen/main.go
func main() {
...
for range t.C {
log.Printf("simulating client requests, round %d", i)
if err := run(numWorkers, numConcurrency); err != nil {
log.Printf("aborted round with error: %v", err)
}
log.Printf("simulated %d requests", numWorkers)
if numRounds != 0 && i > numRounds {
break
}
i++
}
}
Na função principal, você vê o loop chamando a função run. Na implementação atual, a seção tem duas linhas de registro que registram o início e o fim da chamada de função. Agora vamos instrumentar as informações do Span para acompanhar a latência da chamada de função.
Primeiro, conforme observado na seção anterior, vamos configurar todas as configurações do OpenTelemetry. Adicione os pacotes do OpenTelemetry da seguinte maneira:
step0/src/loadgen/main.go
import (
"context" // step1. add packages
"encoding/json"
"fmt"
"io"
"log"
"math/rand"
"net/http"
"net/url"
"time"
// step1. add packages
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/attribute"
stdout "go.opentelemetry.io/otel/exporters/stdout/stdouttrace"
"go.opentelemetry.io/otel/propagation"
sdktrace "go.opentelemetry.io/otel/sdk/trace"
semconv "go.opentelemetry.io/otel/semconv/v1.10.0"
"go.opentelemetry.io/otel/trace"
// step1. end add packages
)
Para facilitar a leitura, criamos uma função de configuração chamada initTracer e a chamamos na função main.
step0/src/loadgen/main.go
// step1. add OpenTelemetry initialization function
func initTracer() (*sdktrace.TracerProvider, error) {
// create a stdout exporter to show collected spans out to stdout.
exporter, err := stdout.New(stdout.WithPrettyPrint())
if err != nil {
return nil, err
}
// for the demonstration, we use AlwaysSmaple sampler to take all spans.
// do not use this option in production.
tp := sdktrace.NewTracerProvider(
sdktrace.WithSampler(sdktrace.AlwaysSample()),
sdktrace.WithBatcher(exporter),
)
otel.SetTracerProvider(tp)
otel.SetTextMapPropagator(propagation.TraceContext{})
return tp, nil
}
O procedimento para configurar o OpenTelemetry é o mesmo descrito na seção anterior. Nesta implementação, usamos um exportador stdout que exporta todas as informações de rastreamento para o stdout em um formato estruturado.
Em seguida, chame-a na função principal. Chame initTracer() e TracerProvider.Shutdown() ao fechar o aplicativo.
step0/src/loadgen/main.go
func main() {
// step1. setup OpenTelemetry
tp, err := initTracer()
if err != nil {
log.Fatalf("failed to initialize TracerProvider: %v", err)
}
defer func() {
if err := tp.Shutdown(context.Background()); err != nil {
log.Fatalf("error shutting down TracerProvider: %v", err)
}
}()
// step1. end setup
log.Printf("starting worder with %d workers in %d concurrency", numWorkers, numConcurrency)
log.Printf("number of rounds: %d (0 is inifinite)", numRounds)
...
Depois de concluir a configuração, você precisa criar um Span com um ID de Trace e um ID de Span exclusivos. O OpenTelemetry oferece uma biblioteca útil para isso. Adicione novos pacotes ao cliente HTTP do instrumento.
step0/src/loadgen/main.go
import (
"context"
"encoding/json"
"fmt"
"io"
"log"
"math/rand"
"net/http"
"net/http/httptrace" // step1. add packages
"net/url"
"time"
// step1. add packages
"go.opentelemetry.io/contrib/instrumentation/net/http/httptrace/otelhttptrace"
"go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
// step1. end add packages
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/attribute"
stdout "go.opentelemetry.io/otel/exporters/stdout/stdouttrace"
"go.opentelemetry.io/otel/propagation"
sdktrace "go.opentelemetry.io/otel/sdk/trace"
semconv "go.opentelemetry.io/otel/semconv/v1.10.0"
"go.opentelemetry.io/otel/trace"
)
Como o gerador de carga está chamando o serviço do cliente em HTTP com net/http na função runQuery, usamos o pacote contrib para net/http e ativamos a instrumentação com a extensão do pacote httptrace e otelhttp.
Primeiro, adicione uma variável httpClient global do pacote para chamar solicitações HTTP pelo cliente instrumentado.
step0/src/loadgen/main.go
var httpClient = http.Client{
Transport: otelhttp.NewTransport(http.DefaultTransport)
}
Em seguida, adicione a instrumentação na função runQuery para criar o período personalizado usando o OpenTelemetry e o período gerado automaticamente pelo cliente HTTP personalizado. O que você vai fazer é:
- Receber um Trace da
TracerProviderglobal comotel.Tracer() - Criar uma extensão raiz com o método
Tracer.Start() - Encerrar o período raiz em um momento arbitrário (neste caso, o fim da função
runQuery)
step0/src/loadgen/main.go
reqURL.RawQuery = v.Encode()
// step1. replace http.Get() with custom client call
// resp, err := http.Get(reqURL.String())
// step1. instrument trace
ctx := context.Background()
tr := otel.Tracer("loadgen")
ctx, span := tr.Start(ctx, "query.request", trace.WithAttributes(
semconv.TelemetrySDKLanguageGo,
semconv.ServiceNameKey.String("loadgen.runQuery"),
attribute.Key("query").String(s),
))
defer span.End()
ctx = httptrace.WithClientTrace(ctx, otelhttptrace.NewClientTrace(ctx))
req, err := http.NewRequestWithContext(ctx, "GET", reqURL.String(), nil)
if err != nil {
return -1, fmt.Errorf("error creating HTTP request object: %v", err)
}
resp, err := httpClient.Do(req)
// step1. end instrumentation
if err != nil {
return -1, fmt.Errorf("error sending request to %v: %v", reqURL.String(), err)
}
Agora você já terminou a instrumentação no loadgen (aplicação de cliente HTTP). Atualize o go.mod e o go.sum com o comando go mod.
go mod tidy
Serviço de cliente do instrumento
Na seção anterior, instrumentamos a parte delimitada pelo retângulo vermelho no desenho abaixo. Instrumentamos as informações de duração no serviço do gerador de carga. Assim como no serviço de gerador de carga, agora precisamos instrumentar o serviço do cliente. A diferença em relação ao serviço do gerador de carga é que o serviço do cliente precisa extrair as informações do ID de rastreamento propagadas pelo serviço do gerador de carga no cabeçalho HTTP e usar o ID para gerar spans.
Abra o Cloud Shell Editor e adicione os pacotes necessários, como fizemos para o serviço de gerador de carga.
step0/src/client/main.go
import (
"context"
"encoding/json"
"fmt"
"io"
"log"
"net/http"
"net/url"
"os"
"time"
"opentelemetry-trace-codelab-go/client/shakesapp"
// step1. add new import
"go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/attribute"
stdout "go.opentelemetry.io/otel/exporters/stdout/stdouttrace"
"go.opentelemetry.io/otel/propagation"
sdktrace "go.opentelemetry.io/otel/sdk/trace"
"go.opentelemetry.io/otel/trace"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials/insecure"
// step1. end new import
)
Novamente, precisamos configurar o OpenTelemetry. Basta copiar e colar a função initTracer do loadgen e chamá-la na função main do serviço de cliente.
step0/src/client/main.go
// step1. add OpenTelemetry initialization function
func initTracer() (*sdktrace.TracerProvider, error) {
// create a stdout exporter to show collected spans out to stdout.
exporter, err := stdout.New(stdout.WithPrettyPrint())
if err != nil {
return nil, err
}
// for the demonstration, we use AlwaysSmaple sampler to take all spans.
// do not use this option in production.
tp := sdktrace.NewTracerProvider(
sdktrace.WithSampler(sdktrace.AlwaysSample()),
sdktrace.WithBatcher(exporter),
)
otel.SetTracerProvider(tp)
otel.SetTextMapPropagator(propagation.TraceContext{})
return tp, nil
}
Agora é hora de instrumentar os spans. Como o serviço do cliente precisa aceitar solicitações HTTP do serviço loadgen, ele precisa instrumentar o gerenciador. O servidor HTTP no serviço do cliente é implementado com net/http, e você pode usar o pacote otelhttp como fizemos no loadgen.
Primeiro, substituímos o registro do gerenciador por otelhttp. Na função main, encontre as linhas em que o gerenciador HTTP está registrado com http.HandleFunc().
step0/src/client/main.go
// step1. change handler to intercept OpenTelemetry related headers
// http.HandleFunc("/", svc.handler)
otelHandler := otelhttp.NewHandler(http.HandlerFunc(svc.handler), "client.handler")
http.Handle("/", otelHandler)
// step1. end intercepter setting
http.HandleFunc("/_genki", svc.health)
Em seguida, instrumentamos o escopo real dentro do gerenciador. Encontre o manipulador de func (*clientService) e adicione a instrumentação de span com trace.SpanFromContext().
step0/src/client/main.go
func (cs *clientService) handler(w http.ResponseWriter, r *http.Request) {
...
ctx := r.Context()
ctx, cancel := context.WithCancel(ctx)
defer cancel()
// step1. instrument trace
span := trace.SpanFromContext(ctx)
defer span.End()
// step1. end instrument
...
Com essa instrumentação, você recebe os intervalos do início ao fim do método handler. Para facilitar a análise dos intervalos, adicione um atributo extra que armazene a contagem correspondente à consulta. Logo antes da linha de registro, adicione o seguinte código.
func (cs *clientService) handler(w http.ResponseWriter, r *http.Request) {
...
// step1. add span specific attribute
span.SetAttributes(attribute.Key("matched").Int64(resp.MatchCount))
// step1. end adding attribute
log.Println(string(ret))
...
Com toda a instrumentação acima, você concluiu a instrumentação de rastreamento entre o loadgen e o cliente. Como ele funciona. Execute o código com o skaffold novamente.
skaffold dev
Depois de algum tempo executando os serviços no cluster do GKE, você vai notar uma grande quantidade de mensagens de registro como esta:
Resposta ao comando
[loadgen] {
[loadgen] "Name": "query.request",
[loadgen] "SpanContext": {
[loadgen] "TraceID": "cfa22247a542beeb55a3434392d46b89",
[loadgen] "SpanID": "18b06404b10c418b",
[loadgen] "TraceFlags": "01",
[loadgen] "TraceState": "",
[loadgen] "Remote": false
[loadgen] },
[loadgen] "Parent": {
[loadgen] "TraceID": "00000000000000000000000000000000",
[loadgen] "SpanID": "0000000000000000",
[loadgen] "TraceFlags": "00",
[loadgen] "TraceState": "",
[loadgen] "Remote": false
[loadgen] },
[loadgen] "SpanKind": 1,
[loadgen] "StartTime": "2022-07-14T13:13:36.686751087Z",
[loadgen] "EndTime": "2022-07-14T13:14:31.849601964Z",
[loadgen] "Attributes": [
[loadgen] {
[loadgen] "Key": "telemetry.sdk.language",
[loadgen] "Value": {
[loadgen] "Type": "STRING",
[loadgen] "Value": "go"
[loadgen] }
[loadgen] },
[loadgen] {
[loadgen] "Key": "service.name",
[loadgen] "Value": {
[loadgen] "Type": "STRING",
[loadgen] "Value": "loadgen.runQuery"
[loadgen] }
[loadgen] },
[loadgen] {
[loadgen] "Key": "query",
[loadgen] "Value": {
[loadgen] "Type": "STRING",
[loadgen] "Value": "faith"
[loadgen] }
[loadgen] }
[loadgen] ],
[loadgen] "Events": null,
[loadgen] "Links": null,
[loadgen] "Status": {
[loadgen] "Code": "Unset",
[loadgen] "Description": ""
[loadgen] },
[loadgen] "DroppedAttributes": 0,
[loadgen] "DroppedEvents": 0,
[loadgen] "DroppedLinks": 0,
[loadgen] "ChildSpanCount": 5,
[loadgen] "Resource": [
[loadgen] {
[loadgen] "Key": "service.name",
[loadgen] "Value": {
[loadgen] "Type": "STRING",
[loadgen] "Value": "unknown_service:loadgen"
...
O exportador stdout emite essas mensagens. Os pais de todos os períodos de loadgen têm TraceID: 00000000000000000000000000000000, porque esse é o período raiz, ou seja, o primeiro no rastro. Além disso, você descobre que o atributo de incorporação "query" tem a string de consulta transmitida ao serviço de cliente.
Resumo
Nesta etapa, você instrumentou o serviço de gerador de carga e o serviço do cliente que se comunicam em HTTP e confirmou que pode propagar o contexto de rastreamento entre os serviços e exportar informações de intervalo dos dois serviços para stdout.
A seguir
Na próxima etapa, você vai instrumentar o serviço do cliente e do servidor para confirmar como propagar o contexto de trace pelo gRPC.
5. Instrumentação para gRPC
Na etapa anterior, instrumentamos a primeira metade da solicitação nesses microsserviços. Nesta etapa, tentamos instrumentar a comunicação gRPC entre o serviço do cliente e o serviço do servidor. (Retângulo verde e roxo na imagem abaixo)
Instrumentação pré-build para o cliente gRPC
O ecossistema do OpenTelemetry oferece muitas bibliotecas úteis que ajudam os desenvolvedores a instrumentar aplicativos. Na etapa anterior, usamos a instrumentação pré-build para o pacote net/http. Nesta etapa, como estamos tentando propagar o contexto de rastreamento pelo gRPC, usamos a biblioteca para isso.
Primeiro, importe o pacote gRPC pré-criado chamado otelgrpc.
step0/src/client/main.go
import (
"context"
"encoding/json"
"fmt"
"io"
"log"
"net/http"
"net/url"
"os"
"time"
"opentelemetry-trace-codelab-go/client/shakesapp"
// step2. add prebuilt gRPC package (otelgrpc)
"go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"
"go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/attribute"
stdout "go.opentelemetry.io/otel/exporters/stdout/stdouttrace"
"go.opentelemetry.io/otel/propagation"
sdktrace "go.opentelemetry.io/otel/sdk/trace"
"go.opentelemetry.io/otel/trace"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials/insecure"
)
Desta vez, o serviço do cliente é um cliente gRPC em relação ao serviço do servidor. Portanto, é necessário instrumentar o cliente gRPC. Encontre a função mustConnGRPC e adicione interceptors gRPC que instrumentem novos spans sempre que o cliente fizer solicitações ao servidor.
step0/src/client/main.go
// Helper function for gRPC connections: Dial and create client once, reuse.
func mustConnGRPC(ctx context.Context, conn **grpc.ClientConn, addr string) {
var err error
// step2. add gRPC interceptor
interceptorOpt := otelgrpc.WithTracerProvider(otel.GetTracerProvider())
*conn, err = grpc.DialContext(ctx, addr,
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor(interceptorOpt)),
grpc.WithStreamInterceptor(otelgrpc.StreamClientInterceptor(interceptorOpt)),
grpc.WithTimeout(time.Second*3),
)
// step2: end adding interceptor
if err != nil {
panic(fmt.Sprintf("Error %s grpc: failed to connect %s", err, addr))
}
}
Como você já configurou o OpenTelemetry na seção anterior, não é necessário fazer isso.
Instrumentação pré-criada para o servidor gRPC
Assim como fizemos com o cliente gRPC, chamamos o instrumento pré-criado para o servidor gRPC. Adicione um novo pacote à seção de importação, como:
step0/src/server/main.go
import (
"context"
"fmt"
"io/ioutil"
"log"
"net"
"os"
"regexp"
"strings"
"opentelemetry-trace-codelab-go/server/shakesapp"
"cloud.google.com/go/storage"
// step2. add OpenTelemetry packages including otelgrpc
"go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"
"go.opentelemetry.io/otel"
stdout "go.opentelemetry.io/otel/exporters/stdout/stdouttrace"
"go.opentelemetry.io/otel/propagation"
sdktrace "go.opentelemetry.io/otel/sdk/trace"
"google.golang.org/api/iterator"
"google.golang.org/api/option"
"google.golang.org/grpc"
healthpb "google.golang.org/grpc/health/grpc_health_v1"
)
Como esta é a primeira vez que você instrumenta o servidor, primeiro é necessário configurar o OpenTelemetry, de forma semelhante ao que fizemos para o loadgen e os serviços de cliente.
step0/src/server/main.go
// step2. add OpenTelemetry initialization function
func initTracer() (*sdktrace.TracerProvider, error) {
// create a stdout exporter to show collected spans out to stdout.
exporter, err := stdout.New(stdout.WithPrettyPrint())
if err != nil {
return nil, err
}
// for the demonstration, we use AlwaysSmaple sampler to take all spans.
// do not use this option in production.
tp := sdktrace.NewTracerProvider(
sdktrace.WithSampler(sdktrace.AlwaysSample()),
sdktrace.WithBatcher(exporter),
)
otel.SetTracerProvider(tp)
otel.SetTextMapPropagator(propagation.TraceContext{})
return tp, nil
}
func main() {
...
// step2. setup OpenTelemetry
tp, err := initTracer()
if err != nil {
log.Fatalf("failed to initialize TracerProvider: %v", err)
}
defer func() {
if err := tp.Shutdown(context.Background()); err != nil {
log.Fatalf("error shutting down TracerProvider: %v", err)
}
}()
// step2. end setup
...
Em seguida, adicione os interceptors do servidor. Na função main, encontre o local em que grpc.NewServer() é chamado e adicione os interceptors à função.
step0/src/server/main.go
func main() {
...
svc := NewServerService()
// step2: add interceptor
interceptorOpt := otelgrpc.WithTracerProvider(otel.GetTracerProvider())
srv := grpc.NewServer(
grpc.UnaryInterceptor(otelgrpc.UnaryServerInterceptor(interceptorOpt)),
grpc.StreamInterceptor(otelgrpc.StreamServerInterceptor(interceptorOpt)),
)
// step2: end adding interceptor
shakesapp.RegisterShakespeareServiceServer(srv, svc)
...
Executar o microsserviço e confirmar o rastreamento
Em seguida, execute o código modificado com o comando skaffold.
skaffold dev
Agora, você vai encontrar várias informações de extensão no stdout.
Resposta ao comando
...
[server] {
[server] "Name": "shakesapp.ShakespeareService/GetMatchCount",
[server] "SpanContext": {
[server] "TraceID": "89b472f213a400cf975e0a0041649667",
[server] "SpanID": "96030dbad0061b3f",
[server] "TraceFlags": "01",
[server] "TraceState": "",
[server] "Remote": false
[server] },
[server] "Parent": {
[server] "TraceID": "89b472f213a400cf975e0a0041649667",
[server] "SpanID": "cd90cc3859b73890",
[server] "TraceFlags": "01",
[server] "TraceState": "",
[server] "Remote": true
[server] },
[server] "SpanKind": 2,
[server] "StartTime": "2022-07-14T14:05:55.74822525Z",
[server] "EndTime": "2022-07-14T14:06:03.449258891Z",
[server] "Attributes": [
...
[server] ],
[server] "Events": [
[server] {
[server] "Name": "message",
[server] "Attributes": [
...
[server] ],
[server] "DroppedAttributeCount": 0,
[server] "Time": "2022-07-14T14:05:55.748235489Z"
[server] },
[server] {
[server] "Name": "message",
[server] "Attributes": [
...
[server] ],
[server] "DroppedAttributeCount": 0,
[server] "Time": "2022-07-14T14:06:03.449255889Z"
[server] }
[server] ],
[server] "Links": null,
[server] "Status": {
[server] "Code": "Unset",
[server] "Description": ""
[server] },
[server] "DroppedAttributes": 0,
[server] "DroppedEvents": 0,
[server] "DroppedLinks": 0,
[server] "ChildSpanCount": 0,
[server] "Resource": [
[server] {
...
[server] ],
[server] "InstrumentationLibrary": {
[server] "Name": "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc",
[server] "Version": "semver:0.33.0",
[server] "SchemaURL": ""
[server] }
[server] }
...
Você percebe que não incorporou nenhum nome de span e criou manualmente spans com trace.Start() ou span.SpanFromContext(). Ainda assim, você recebe um grande número de spans porque os interceptors do gRPC os geraram.
Resumo
Nesta etapa, você instrumentou a comunicação baseada em gRPC com o suporte das bibliotecas do ecossistema do OpenTelemetry.
A seguir
Na próxima etapa, você vai visualizar o trace com o Cloud Trace e aprender a analisar os spans coletados.
6. Visualizar o trace com o Cloud Trace
Você instrumentou rastros em todo o sistema com o OpenTelemetry. Até agora, você aprendeu a instrumentar serviços HTTP e gRPC. Embora você tenha aprendido a instrumentar, ainda não aprendeu a analisar. Nesta seção, você vai substituir os exportadores stdout pelos exportadores do Cloud Trace e aprender a analisar seus rastros.
Usar o exportador do Cloud Trace
Uma das características mais interessantes do OpenTelemetry é a capacidade de conexão. Para visualizar todos os períodos coletados pela instrumentação, basta substituir o exportador stdout pelo exportador do Cloud Trace.
Abra os arquivos main.go de cada serviço e encontre a função initTracer(). Exclua a linha para gerar um exportador stdout e crie um exportador do Cloud Trace.
step0/src/loadgen/main.go
import (
...
// step3. add OpenTelemetry for Cloud Trace package
cloudtrace "github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/trace"
)
// step1. add OpenTelemetry initialization function
func initTracer() (*sdktrace.TracerProvider, error) {
// step3. replace stdout exporter with Cloud Trace exporter
// cloudtrace.New() finds the credentials to Cloud Trace automatically following the
// rules defined by golang.org/x/oauth2/google.findDefaultCredentailsWithParams.
// https://pkg.go.dev/golang.org/x/oauth2/google#FindDefaultCredentialsWithParams
exporter, err := cloudtrace.New()
// step3. end replacing exporter
if err != nil {
return nil, err
}
// for the demonstration, we use AlwaysSmaple sampler to take all spans.
// do not use this option in production.
tp := sdktrace.NewTracerProvider(
sdktrace.WithSampler(sdktrace.AlwaysSample()),
sdktrace.WithBatcher(exporter),
)
otel.SetTracerProvider(tp)
otel.SetTextMapPropagator(propagation.TraceContext{})
return tp, nil
}
Você também precisa editar a mesma função no serviço de cliente e servidor.
Executar o microsserviço e confirmar o rastreamento
Depois da edição, basta executar o cluster como de costume com o comando skaffold.
skaffold dev
Agora você não vê muitas informações de período no formato de logs estruturados no stdout, porque substituiu o exportador pelo Cloud Trace.
Resposta ao comando
[loadgen] 2022/07/14 15:01:07 simulated 20 requests
[loadgen] 2022/07/14 15:01:07 simulating client requests, round 37
[loadgen] 2022/07/14 15:01:14 query 'sweet': matched 958
[client] 2022/07/14 15:01:14 {"match_count":958}
[client] 2022/07/14 15:01:14 {"match_count":3040}
[loadgen] 2022/07/14 15:01:14 query 'love': matched 3040
[client] 2022/07/14 15:01:15 {"match_count":349}
[loadgen] 2022/07/14 15:01:15 query 'hello': matched 349
[client] 2022/07/14 15:01:15 {"match_count":484}
[loadgen] 2022/07/14 15:01:15 query 'faith': matched 484
[loadgen] 2022/07/14 15:01:15 query 'insolence': matched 14
[client] 2022/07/14 15:01:15 {"match_count":14}
[client] 2022/07/14 15:01:21 {"match_count":484}
[loadgen] 2022/07/14 15:01:21 query 'faith': matched 484
[client] 2022/07/14 15:01:21 {"match_count":728}
[loadgen] 2022/07/14 15:01:21 query 'world': matched 728
[client] 2022/07/14 15:01:22 {"match_count":484}
[loadgen] 2022/07/14 15:01:22 query 'faith': matched 484
[loadgen] 2022/07/14 15:01:22 query 'hello': matched 349
[client] 2022/07/14 15:01:22 {"match_count":349}
[client] 2022/07/14 15:01:23 {"match_count":1036}
[loadgen] 2022/07/14 15:01:23 query 'friend': matched 1036
[loadgen] 2022/07/14 15:01:28 query 'tear': matched 463
...
Agora vamos confirmar se todos os períodos são enviados corretamente ao Cloud Trace. Acesse o console do Cloud e navegue até "Lista de traces". É fácil acessar pela caixa de pesquisa. Caso contrário, clique no menu no painel à esquerda. 
Várias manchas azuis são distribuídas pelo gráfico de latência. Cada ponto representa um único trace.
Clique em um deles para conferir os detalhes do trace. 
Mesmo com essa análise rápida, você já tem muitos insights. Por exemplo, no gráfico em cascata, é possível ver que a causa da latência é principalmente devido ao período chamado shakesapp.ShakespeareService/GetMatchCount. (Consulte 1 na imagem acima) Você pode confirmar isso na tabela de resumo. A coluna mais à direita mostra a duração de cada período. Além disso, esse trace foi para a consulta "friend". (2 na imagem acima)
Com essas análises curtas, você pode perceber que precisa saber mais sobre os intervalos granulares no método GetMatchCount. Comparada com as informações de stdout, a visualização é poderosa. Para saber mais sobre os detalhes do Cloud Trace, acesse nossa documentação oficial.
Resumo
Nesta etapa, você substituiu o exportador stdout pelo Cloud Trace e visualizou os rastros no Cloud Trace. Você também aprendeu a começar a analisar os rastros.
A seguir
Na próxima etapa, você vai modificar o código-fonte do serviço do servidor para adicionar uma subspan em GetMatchCount.
7. Adicionar subspan para uma análise melhor
Na etapa anterior, você descobriu que a causa do tempo de ida e volta observado no loadgen é principalmente o processo no método GetMatchCount, o gerenciador gRPC, no serviço do servidor. No entanto, como não instrumentamos nada além do gerenciador, não é possível encontrar outros insights no gráfico em cascata. Esse é um caso comum quando começamos a instrumentar microsserviços.
Nesta seção, vamos instrumentar uma subspan em que o servidor chama o Google Cloud Storage, porque é comum que algumas E/S de rede externas levem muito tempo no processo e é importante identificar se a chamada é a causa.
Instrumentar uma subspan no servidor
Abra main.go no servidor e encontre a função readFiles. Essa função está chamando uma solicitação para o Google Cloud Storage para buscar todos os arquivos de texto das obras de Shakespeare. Nessa função, é possível criar uma subspan, como você fez para a instrumentação do servidor HTTP no serviço do cliente.
step0/src/server/main.go
func readFiles(ctx context.Context, bucketName, prefix string) ([]string, error) {
type resp struct {
s string
err error
}
// step4: add an extra span
span := trace.SpanFromContext(ctx)
span.SetName("server.readFiles")
span.SetAttributes(attribute.Key("bucketname").String(bucketName))
defer span.End()
// step4: end add span
...
Pronto. Você adicionou um novo período. Vamos conferir como isso funciona executando o app.
Executar o microsserviço e confirmar o rastreamento
Depois da edição, basta executar o cluster como de costume com o comando skaffold.
skaffold dev
E escolha um rastro chamado query.request na lista de rastros. Você vai encontrar um gráfico de cascata de rastreamento semelhante, exceto por um novo intervalo em shakesapp.ShakespeareService/GetMatchCount. (O intervalo é cercado por um retângulo vermelho abaixo)
O que você pode dizer com base neste gráfico é que a chamada externa para o Google Cloud Storage ocupa uma grande quantidade de latência, mas outras coisas ainda estão causando a maior parte dela.
Você já obteve muitos insights com apenas algumas visualizações do gráfico de cascata do trace. Como você consegue mais detalhes de desempenho no seu aplicativo? É aqui que entra o criador de perfil, mas, por enquanto, vamos encerrar este codelab e delegar todos os tutoriais do criador de perfil para a parte 2.
Resumo
Nesta etapa, você instrumentou outro período no serviço do servidor e obteve mais insights sobre a latência do sistema.
8. Parabéns
Você criou traces distribuídos com o OpenTelemetry e confirmou latências de solicitação em todo o microsserviço no Google Cloud Trace.
Para exercícios mais avançados, tente os seguintes tópicos por conta própria.
- A implementação atual envia todos os spans gerados pela verificação de integridade. (
grpc.health.v1.Health/Check) Como filtrar esses períodos dos Cloud Traces? A dica está aqui. - Correlacione os registros de eventos com os períodos e veja como isso funciona no Google Cloud Trace e no Google Cloud Logging. A dica está aqui.
- Substitua algum serviço por um em outro idioma e tente instrumentá-lo com o OpenTelemetry para essa linguagem.
Se quiser saber mais sobre o criador de perfis depois disso, vá para a parte 2. Nesse caso, você pode pular a seção de limpeza abaixo.
Limpeza
Após este codelab, pare o cluster do Kubernetes e exclua o projeto para não receber cobranças inesperadas no Google Kubernetes Engine, no Google Cloud Trace e no Google Artifact Registry.
Primeiro, exclua o cluster. Se você estiver executando o cluster com skaffold dev, basta pressionar Ctrl-C. Se você estiver executando o cluster com skaffold run, execute o seguinte comando:
skaffold delete
Resposta ao comando
Cleaning up... - deployment.apps "clientservice" deleted - service "clientservice" deleted - deployment.apps "loadgen" deleted - deployment.apps "serverservice" deleted - service "serverservice" deleted
Depois de excluir o cluster, no painel de menu, selecione "IAM e administrador" > "Configurações" e clique no botão "DESLIGAR".
Em seguida, insira o ID do projeto (não o nome) no formulário na caixa de diálogo e confirme o encerramento.