|
| 1 | +--- |
| 2 | +title: Rastros |
| 3 | +weight: 1 |
| 4 | +description: O caminho de uma solicitação através do seu aplicativo. |
| 5 | +default_lang_commit: 57cd4f78d61cc1642ce56089aeec7ae278544194 |
| 6 | +--- |
| 7 | + |
| 8 | +Os **rastros** nos fornecem uma visão geral do que acontece quando uma |
| 9 | +solicitação é feita para uma aplicação. Seja sua aplicação um monólito com um |
| 10 | +único banco de dados ou uma grande variedade de serviços, os rastros são |
| 11 | +essenciais para compreender o "caminho" completo que uma solicitação percorreu |
| 12 | +na sua aplicação. |
| 13 | + |
| 14 | +Vamos explorar isso com três unidades de trabalho, representadas como |
| 15 | +[Trechos](#spans): |
| 16 | + |
| 17 | +{{% alert title="Note" %}} |
| 18 | + |
| 19 | +Os exemplos JSON a seguir não apresentam um formato específico, especialmente o |
| 20 | +[OTLP/JSON](/docs/specs/otlp/#json-protobuf-encoding), que é mais verboso. |
| 21 | + |
| 22 | +{{% /alert %}} |
| 23 | + |
| 24 | +trecho `olá`: |
| 25 | + |
| 26 | +```json |
| 27 | +{ |
| 28 | + "name": "olá", |
| 29 | + "context": { |
| 30 | + "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", |
| 31 | + "span_id": "0x051581bf3cb55c13" |
| 32 | + }, |
| 33 | + "parent_id": null, |
| 34 | + "start_time": "2022-04-29T18:52:58.114201Z", |
| 35 | + "end_time": "2022-04-29T18:52:58.114687Z", |
| 36 | + "attributes": { |
| 37 | + "http.route": "alguma_rota1" |
| 38 | + }, |
| 39 | + "events": [ |
| 40 | + { |
| 41 | + "name": "Guten Tag!", |
| 42 | + "timestamp": "2022-04-29T18:52:58.114561Z", |
| 43 | + "attributes": { |
| 44 | + "event_attributes": 1 |
| 45 | + } |
| 46 | + } |
| 47 | + ] |
| 48 | +} |
| 49 | +``` |
| 50 | + |
| 51 | +Este é o trecho raiz, sinalizando o início e o fim de toda a operação. Note que |
| 52 | +ele possui um campo `trace_id` indicando o rastro, mas não possui `parent_id`. É |
| 53 | +assim que você sabe que é o trecho raiz. |
| 54 | + |
| 55 | +O trecho `olá-cumprimentos`: |
| 56 | + |
| 57 | +```json |
| 58 | +{ |
| 59 | + "name": "olá-cumprimentos", |
| 60 | + "context": { |
| 61 | + "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", |
| 62 | + "span_id": "0x5fb397be34d26b51" |
| 63 | + }, |
| 64 | + "parent_id": "0x051581bf3cb55c13", |
| 65 | + "start_time": "2022-04-29T18:52:58.114304Z", |
| 66 | + "end_time": "2022-04-29T22:52:58.114561Z", |
| 67 | + "attributes": { |
| 68 | + "http.route": "alguma_rota2" |
| 69 | + }, |
| 70 | + "events": [ |
| 71 | + { |
| 72 | + "name": "e aí!", |
| 73 | + "timestamp": "2022-04-29T18:52:58.114561Z", |
| 74 | + "attributes": { |
| 75 | + "event_attributes": 1 |
| 76 | + } |
| 77 | + }, |
| 78 | + { |
| 79 | + "name": "até logo!", |
| 80 | + "timestamp": "2022-04-29T18:52:58.114585Z", |
| 81 | + "attributes": { |
| 82 | + "event_attributes": 1 |
| 83 | + } |
| 84 | + } |
| 85 | + ] |
| 86 | +} |
| 87 | +``` |
| 88 | + |
| 89 | +Este trecho encapsula tarefas específicas, como dizer saudações, e seu pai é o |
| 90 | +trecho `olá`. Note que ele compartilha o mesmo `trace_id` que o trecho raiz, |
| 91 | +indicando que faz parte do mesmo rastro. Além disso, ele possui um `parent_id` |
| 92 | +que corresponde ao `span_id` do trecho `olá`. |
| 93 | + |
| 94 | +O trecho `olá-saudações`: |
| 95 | + |
| 96 | +```json |
| 97 | +{ |
| 98 | + "name": "olá-saudações", |
| 99 | + "context": { |
| 100 | + "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", |
| 101 | + "span_id": "0x93564f51e1abe1c2" |
| 102 | + }, |
| 103 | + "parent_id": "0x051581bf3cb55c13", |
| 104 | + "start_time": "2022-04-29T18:52:58.114492Z", |
| 105 | + "end_time": "2022-04-29T18:52:58.114631Z", |
| 106 | + "attributes": { |
| 107 | + "http.route": "alguma_rota3" |
| 108 | + }, |
| 109 | + "events": [ |
| 110 | + { |
| 111 | + "name": "olá!", |
| 112 | + "timestamp": "2022-04-29T18:52:58.114561Z", |
| 113 | + "attributes": { |
| 114 | + "event_attributes": 1 |
| 115 | + } |
| 116 | + } |
| 117 | + ] |
| 118 | +} |
| 119 | +``` |
| 120 | + |
| 121 | +Este trecho representa a terceira operação neste rastro e assim como o anterior, |
| 122 | +é um filho do trecho `olá`. Isso também o torna um irmão do trecho |
| 123 | +`olá-cumprimentos`. |
| 124 | + |
| 125 | +Esses três blocos de JSON compartilham o mesmo `trace_id`, e o campo `parent_id` |
| 126 | +que representa uma hierarquia. Isso o torna um rastro! |
| 127 | + |
| 128 | +Outra coisa que você notará é que cada trecho se parece com um log estruturado. |
| 129 | +Isso porque, de certa forma, é mesmo! Uma maneira de pensar em rastros é como |
| 130 | +uma coleção de logs estruturados com contexto, correlação, hierarquia e outros |
| 131 | +recursos. No entanto, esses "logs estruturados" podem vir de diferentes |
| 132 | +processos, serviços, VMs, data centers, e assim por diante. Isso torna possível |
| 133 | +que o rastreamento represente uma visão de ponta a ponta de qualquer sistema. |
| 134 | + |
| 135 | +Para compreender como o rastreamento no OpenTelemetry funciona, vamos analisar |
| 136 | +uma lista de componentes que terão um papel fundamental na instrumentação do |
| 137 | +nosso código. |
| 138 | + |
| 139 | +## Trace Provider |
| 140 | + |
| 141 | +Um Trace Provider (às vezes chamado de `TracerProvider`) é uma fábrica de |
| 142 | +`rastros`. Na maioria das aplicações, um Trace Provider é inicializado uma vez e |
| 143 | +seu ciclo de vida corresponde ao ciclo de vida da aplicação. A inicialização do |
| 144 | +Trace Provider também inclui a inicialização de Resource e Exporter. Geralmente |
| 145 | +é a primeira etapa do rastreamento com OpenTelemetry. Em alguns SDKs, um Trace |
| 146 | +Provider global já é inicializado para você. |
| 147 | + |
| 148 | +## Rastro {#tracer} |
| 149 | + |
| 150 | +Um rastro cria trechos contendo mais informações sobre o que está acontecendo em |
| 151 | +uma determinada operação, como uma solicitação em um serviço. Rastros são |
| 152 | +criados a partir de Trace Providers. |
| 153 | + |
| 154 | +## Trace Exporters |
| 155 | + |
| 156 | +Trace Exporters enviam rastros para um consumidor. Esse consumidor pode ser a |
| 157 | +saída padrão para depuração em tempo de desenvolvimento, o OpenTelemetry |
| 158 | +Collector ou qualquer backend de código aberto ou fornecedor de sua escolha. |
| 159 | + |
| 160 | +## Propagação de Contexto {#context-propagation} |
| 161 | + |
| 162 | +A propagação de contexto é o conceito central que possibilita o rastreamento |
| 163 | +distribuído. Com a propagação de contexto, trechos podem ser correlacionados |
| 164 | +entre si e montados em um rastro, independentemente de onde os trechos são |
| 165 | +gerados. Para saber mais sobre este tópico, consulte a página de conceitos sobre |
| 166 | +[Propagação de Contexto](/docs/concepts/context-propagation). |
| 167 | + |
| 168 | +## Trechos {#spans} |
| 169 | + |
| 170 | +Um **trecho** representa uma unidade de trabalho ou operação. Trechos são os |
| 171 | +blocos que compõem os rastros. No OpenTelemetry, eles incluem as seguintes |
| 172 | +informações: |
| 173 | + |
| 174 | +- Nome |
| 175 | +- ID do trecho pai (vazio para trecho raiz) |
| 176 | +- Marcação de tempo do início e fim |
| 177 | +- [Contexto do Trecho](#span-context) |
| 178 | +- [Atributos](#attributes) |
| 179 | +- [Eventos do Trecho](#span-events) |
| 180 | +- [Links do Trecho](#span-links) |
| 181 | +- [Estado do Trecho](#span-status) |
| 182 | + |
| 183 | +Exemplo de trecho: |
| 184 | + |
| 185 | +```json |
| 186 | +{ |
| 187 | + "name": "/v1/sys/health", |
| 188 | + "context": { |
| 189 | + "trace_id": "7bba9f33312b3dbb8b2c2c62bb7abe2d", |
| 190 | + "span_id": "086e83747d0e381e" |
| 191 | + }, |
| 192 | + "parent_id": "", |
| 193 | + "start_time": "2021-10-22 16:04:01.209458162 +0000 UTC", |
| 194 | + "end_time": "2021-10-22 16:04:01.209514132 +0000 UTC", |
| 195 | + "status_code": "STATUS_CODE_OK", |
| 196 | + "status_message": "", |
| 197 | + "attributes": { |
| 198 | + "net.transport": "IP.TCP", |
| 199 | + "net.peer.ip": "172.17.0.1", |
| 200 | + "net.peer.port": "51820", |
| 201 | + "net.host.ip": "10.177.2.152", |
| 202 | + "net.host.port": "26040", |
| 203 | + "http.method": "GET", |
| 204 | + "http.target": "/v1/sys/health", |
| 205 | + "http.server_name": "mortar-gateway", |
| 206 | + "http.route": "/v1/sys/health", |
| 207 | + "http.user_agent": "Consul Health Check", |
| 208 | + "http.scheme": "http", |
| 209 | + "http.host": "10.177.2.152:26040", |
| 210 | + "http.flavor": "1.1" |
| 211 | + }, |
| 212 | + "events": [ |
| 213 | + { |
| 214 | + "name": "", |
| 215 | + "message": "OK", |
| 216 | + "timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC" |
| 217 | + } |
| 218 | + ] |
| 219 | +} |
| 220 | +``` |
| 221 | + |
| 222 | +Trechos podem ser aninhados, como é indicado pela presença de um ID de trecho |
| 223 | +pai: trechos filhos representam sub-operações. Isso permite que os trechos |
| 224 | +capturem de forma mais precisa o trabalho realizado em uma aplicação. |
| 225 | + |
| 226 | +### Contexto do Trecho {#span-context} |
| 227 | + |
| 228 | +O contexto do trecho é um objeto imutável em cada trecho que contém o seguinte: |
| 229 | + |
| 230 | +- O Trace ID que representando o rastro do qual o trecho faz parte |
| 231 | +- O Span ID do trecho |
| 232 | +- Trace Flags, uma codificação binária contendo informações sobre o rastro |
| 233 | +- Trace State, uma lista de pares chave-valor que podem carregar informações de |
| 234 | + rastro específicos do fornecedor |
| 235 | + |
| 236 | +O contexto do trecho é a parte de um trecho que é serializada e propagada junto |
| 237 | +com a [propagação de contexto](#context-propagation) e |
| 238 | +[baggage](/docs/concepts/signals/baggage). |
| 239 | + |
| 240 | +Como o contexto do trecho contém o trace ID, o trace ID é usado ao criar |
| 241 | +[links de trechos](#span-links). |
| 242 | + |
| 243 | +### Atributos {#attributes} |
| 244 | + |
| 245 | +Atributos são pares chave-valor que contêm metadados que você pode usar para |
| 246 | +anotar um trecho e carregar informações sobre a operação que ele está |
| 247 | +acompanhando. |
| 248 | + |
| 249 | +Por exemplo, se um trecho rastreia uma operação que adiciona um item ao carrinho |
| 250 | +de compras de um usuário em um sistema de eCommerce, é possível obter o ID do |
| 251 | +usuário o ID do item a ser adicionado ao carrinho e o ID do carrinho. |
| 252 | + |
| 253 | +Você pode adicionar atributos aos trecho durante ou após a criação do trecho. |
| 254 | +Prefira adicionar atributos na criação do trecho para disponibilizar os |
| 255 | +atributos para a amostragem do SDK. Se precisar adicionar um valor após a |
| 256 | +criação do trecho, atualize o trecho com o valor. |
| 257 | + |
| 258 | +Os atributos têm as seguintes regras que é implementada por cada SDK: |
| 259 | + |
| 260 | +- Chaves devem ser valores de string não nulos |
| 261 | +- Valores devem ser uma string não nula, boolean, valor de ponto flutuante, |
| 262 | + inteiro ou um array desses valores |
| 263 | + |
| 264 | +Além disso, existem [atributos semânticos](/docs/specs/semconv/general/trace/), |
| 265 | +que são convenções de nomenclatura conhecidas para metadados que estão |
| 266 | +tipicamente presentes em operações comuns. É útil usar a nomenclatura de |
| 267 | +atributos semânticos sempre que possível para que tipos comuns de metadados |
| 268 | +sejam padronizados entre sistemas. |
| 269 | + |
| 270 | +### Eventos de Trechos {#span-events} |
| 271 | + |
| 272 | +Um evento de trecho pode ser considerado como uma mensagem de log estruturada |
| 273 | +(ou anotação) em um trecho, tipicamente usada para apresentar um ponto |
| 274 | +significativo e único no tempo durante a duração do trecho. |
| 275 | + |
| 276 | +Por exemplo, considere dois cenários em um navegador web: |
| 277 | + |
| 278 | +1. Rastrear o carregamento de uma página |
| 279 | +2. Apontar quando uma página se torna interativa |
| 280 | + |
| 281 | +Um trecho é mais adequado para o primeiro cenário, pois é uma operação que tem |
| 282 | +início e fim. |
| 283 | + |
| 284 | +Um evento de trecho é mais adequado para rastrear o segundo cenário porque |
| 285 | +representa um ponto relevante e único na solicitação. |
| 286 | + |
| 287 | +#### Quando usar eventos de trecho versus atributos de trecho {#when-to-use-span-events-versus-span-attributes} |
| 288 | + |
| 289 | +Como eventos de trecho também contêm atributos, a questão de quando usar eventos |
| 290 | +em vez de atributos nem sempre tem uma resposta óbvia. Para confirmar sua |
| 291 | +decisão, verifique se uma data e hora específicas são relevantes para você. |
| 292 | + |
| 293 | +Por exemplo, quando você está rastreando uma operação com um trecho e a mesma é |
| 294 | +finalizada, você pode querer adicionar dados da operação à sua telemetria. |
| 295 | + |
| 296 | +- Se a data e hora em que a operação é finalizada for significativo ou |
| 297 | + relevante, anexe os dados a um evento de trecho. |
| 298 | +- Se a data e hora não forem relevantes, anexe os dados como atributos de |
| 299 | + trecho. |
| 300 | + |
| 301 | +### Links de Trechos {#span-links} |
| 302 | + |
| 303 | +Os links existem para que você possa associar um trecho a um ou mais trechos, |
| 304 | +resultando em uma relação causal. Por exemplo, imagine que temos um sistema |
| 305 | +distribuído onde algumas operações são rastreadas por um rastro. |
| 306 | + |
| 307 | +Em resposta a algumas dessas ações, uma operação adicional é enfileirada para |
| 308 | +ser executada, mas sua execução é assíncrona. Podemos rastrear essa operação |
| 309 | +seguinte através de um rastro. |
| 310 | + |
| 311 | +Gostaríamos de associar o rastro das operações subsequentes ao primeiro rastro, |
| 312 | +mas não podemos prever quando as operações subsequentes começarão. Precisamos |
| 313 | +associar os dois rastros, então utilizaremos um link de trecho. |
| 314 | + |
| 315 | +Você pode vincular o último trecho do primeiro rastro ao primeiro trecho do |
| 316 | +segundo rastro. Agora, eles estão causalmente associados entre si. |
| 317 | + |
| 318 | +Os links são opcionais, mas servem como uma boa maneira de associar trechos de |
| 319 | +rastro uns aos outros. |
| 320 | + |
| 321 | +### O estado do Trecho {#span-status} |
| 322 | + |
| 323 | +Cada trecho tem um estado. Os três valores possíveis são: |
| 324 | + |
| 325 | +- `Unset` |
| 326 | +- `Error` |
| 327 | +- `OK` |
| 328 | + |
| 329 | +O valor padrão é `Unset`. Um estado de trecho `Unset` significa que a operação |
| 330 | +rastreada foi concluída com sucesso, sem erro. |
| 331 | + |
| 332 | +Quando o estado de um trecho é `Error`, isso significa que algum erro ocorreu na |
| 333 | +operação rastreada. Por exemplo, isso pode ser devido a um erro de HTTP 500 em |
| 334 | +um servidor que está lidando com uma solicitação. |
| 335 | + |
| 336 | +Quando o estado de um trecho é `OK`, isso significa que o trecho foi |
| 337 | +expressamente marcado como livre de erros pelo desenvolvedor. Apesar de parecer |
| 338 | +contraditório, não é necessário definir o estado de um trecho como `OK` quando |
| 339 | +se sabe que foi concluído sem erros, pois já está implícito em `Unset`. O estado |
| 340 | +de `OK` representa uma "decisão final" clara sobre o estado de um trecho que foi |
| 341 | +explicitamente definido por um usuário. Isso é útil em qualquer situação em que |
| 342 | +um desenvolvedor deseje que não haja outra interpretação de um trecho além de |
| 343 | +"bem-sucedido". |
| 344 | + |
| 345 | +Para reiterar: `Unset` representa um trecho que foi concluído sem erro. `OK` |
| 346 | +representa quando um desenvolvedor marca explicitamente um trecho como |
| 347 | +bem-sucedido. Na maioria dos casos, não é necessário marcar explicitamente um |
| 348 | +trecho como OK. |
| 349 | + |
| 350 | +### Tipo de Trecho {#span-kind} |
| 351 | + |
| 352 | +Quando um trecho é criado, ele pode ser do tipo: `Client`, `Server`, `Internal`, |
| 353 | +`Producer` ou `Consumer`. Esse tipo de trecho indica ao backend de rastreamento |
| 354 | +como o rastro deve ser montado. De acordo com a especificação do OpenTelemetry, |
| 355 | +o trecho pai de um servidor geralmente é um trecho de cliente remoto, e o trecho |
| 356 | +filho de um cliente geralmente é um trecho de servidor. Da mesma forma, o trecho |
| 357 | +pai de um consumidor é sempre um fornecedor, e o trecho filho de um fornecedor é |
| 358 | +sempre um consumidor. Se o tipo de trecho não for especificado, ele será |
| 359 | +assumido como interno. |
| 360 | + |
| 361 | +Para mais informações sobre o tipo de Trecho, consulte |
| 362 | +[SpanKind](/docs/specs/otel/trace/api/#spankind). |
| 363 | + |
| 364 | +#### Client |
| 365 | + |
| 366 | +Um trecho de client representa uma chamada remota síncrona de saída, como uma |
| 367 | +solicitação HTTP ou uma chamada de banco de dados. Observe que, neste contexto, |
| 368 | +"síncrono" não se refere a operações `async/await`, mas sim ao fato de que a |
| 369 | +chamada não é enfileirada para processamento posterior. |
| 370 | + |
| 371 | +#### Server |
| 372 | + |
| 373 | +Um trecho de servidor representa uma chamada remota síncrona de entrada, como |
| 374 | +uma solicitação HTTP de entrada ou uma chamada de procedimento remoto. |
| 375 | + |
| 376 | +#### Internal |
| 377 | + |
| 378 | +Trechos internos representam operações que não atravessam uma fronteira de |
| 379 | +processo. Coisas como instrumentar uma chamada de função ou um Express |
| 380 | +middleware podem usar trechos internos. |
| 381 | + |
| 382 | +#### Producer |
| 383 | + |
| 384 | +Trechos de fornecedor representam a criação de um trabalho que pode ser |
| 385 | +processado de forma assíncrona mais tarde. Pode ser uma tarefa remota, como uma |
| 386 | +adição em uma fila de tarefas, ou uma tarefa local processada por um ouvinte de |
| 387 | +eventos. |
| 388 | + |
| 389 | +### Consumer |
| 390 | + |
| 391 | +Trechos de consumidor representam o processamento de um trabalho criado por um |
| 392 | +produtor e podem começar muito tempo depois que o trecho de produtor já |
| 393 | +terminou. |
| 394 | + |
| 395 | +## Especificação {#specification} |
| 396 | + |
| 397 | +Para mais informações, consulte |
| 398 | +[especificação de rastros](/docs/specs/otel/overview/#tracing-signal). |
0 commit comments