Skip to content

Commit a7b2925

Browse files
EzzioMoreiraedsoncelioemdneto
authored
[pt] Add /pt/docs/concepts/signals/trace.md (#5019)
Co-authored-by: Edson C. <[email protected]> Co-authored-by: Emídio Neto <[email protected]>
1 parent 8e100fd commit a7b2925

File tree

1 file changed

+398
-0
lines changed

1 file changed

+398
-0
lines changed
+398
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,398 @@
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

Comments
 (0)