Skip to content

Commit 0e5a219

Browse files
EzzioMoreiraEzzioMoreira
committed
feat: add localization signal log
1 parent 2f37a99 commit 0e5a219

File tree

1 file changed

+85
-0
lines changed
  • content/pt/docs/concepts/signals

1 file changed

+85
-0
lines changed

‎content/pt/docs/concepts/signals/logs.md

+85
Original file line numberDiff line numberDiff line change
@@ -24,4 +24,89 @@ O [OpenTelemetry Collector](/docs/collector) fornece várias ferramentas para tr
2424

2525
O primeiro passo na adoção do OpenTelemetry frequentemente envolve implantar um Collector como um agente de logging de propósito geral.
2626

27+
### Logs do OpenTelemetry para aplicações
2728

29+
Em aplicações, logs do OpenTelemetry são criados com qualquer biblioteca de logging ou recursos integrados de logging. Quando você adiciona autoinstrumentação ou ativa um SDK, o OpenTelemetry automaticamente correlaciona seus logs com os rastros e trechos, incluindo no corpo do log seus IDs. Em outras palavras, o OpenTelemetry automaticamente correlaciona seus logs e rastros.
30+
31+
### Suporte a Linguagens
32+
33+
Logs é um sinal [estável](/docs/specs/otel/versioning-and-stability/#stable) na especificação do OpenTelemetry. Para as implementações específicas de cada linguagem da API e SDK de Logs, temos o seguinte estado:
34+
35+
{{% signal-support-table "logs" %}}
36+
37+
## Logs estruturados, não estruturados e semiestruturados
38+
39+
Tecnicamente o OpenTelemetry não distingue entre logs estruturados e não estruturados. Você pode usar qualquer log que tiver com o OpenTelemetry. No entanto, nem todos os formatos de log são igualmente úteis! Logs estruturados, em particular, são recomendados para observabilidade em produção porque são fáceis de analisar e interpretar em escala. A seção a seguir explica as diferenças entre logs estruturados, não estruturados e semiestruturados.
40+
41+
### Logs estruturados
42+
43+
Um log estruturado é aquele que segue um formato consistente e legível por máquina. Para aplicações, um dos formatos mais comuns é o JSON:
44+
45+
```json
46+
{
47+
"timestamp": "2024-08-04T12:34:56.789Z",
48+
"level": "INFO",
49+
"service": "user-authentication",
50+
"environment": "production",
51+
"message": "User login successful",
52+
"context": {
53+
"userId": "12345",
54+
"username": "johndoe",
55+
"ipAddress": "192.168.1.1",
56+
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
57+
},
58+
"transactionId": "abcd-efgh-ijkl-mnop",
59+
"duration": 200,
60+
"request": {
61+
"method": "POST",
62+
"url": "/api/v1/login",
63+
"headers": {
64+
"Content-Type": "application/json",
65+
"Accept": "application/json"
66+
},
67+
"body": {
68+
"username": "johndoe",
69+
"password": "******"
70+
}
71+
},
72+
"response": {
73+
"statusCode": 200,
74+
"body": {
75+
"success": true,
76+
"token": "jwt-token-here"
77+
}
78+
}
79+
}
80+
```
81+
82+
e para componentes de infraestrutura, o _Common Log Format (CLF)_ é frequentemente usado:
83+
84+
```text
85+
127.0.0.1 - johndoe [04/Aug/2024:12:34:56 -0400] "POST /api/v1/login HTTP/1.1" 200 1234
86+
```
87+
88+
Também é comum ter logs estruturados em diferentes formatos juntos. Por exemplo, um log no formato _Extended Log Format (ELF)_ pode combinar JSON com os dados separados por espaços em um log CLF.
89+
90+
```text
91+
192.168.1.1 - johndoe [04/Aug/2024:12:34:56 -0400] "POST /api/v1/login HTTP/1.1" 200 1234 "http://example.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36" {"transactionId": "abcd-efgh-ijkl-mnop", "responseTime": 150, "requestBody": {"username": "johndoe"}, "responseHeaders": {"Content-Type": "application/json"}}
92+
```
93+
94+
Para aproveitar ao máximo este log, analise tanto as partes relacionadas ao JSON quanto ao ELF em um formato compartilhado para facilitar a análise em um backend de observabilidade. O `filelogreceiver` no [OpenTelemetry Coletor](/docs/collector) contém maneiras padronizadas de analisar logs como estes.
95+
96+
Logs estruturados são a melhor forma de usar logs. Por serem emitidos em um formato consistente, os logs são analisados diretamente, o que facilita o pré-processamento no OpenTelemetry Coletor, a correlação com outros dados e, por fim, a análise em um backend de Observabilidade.
97+
98+
### Logs não estruturados
99+
100+
Logs não estruturados são logs que não seguem uma estrutura consistente. Eles podem ser mais legíveis para humanos e são frequentemente usados em desenvolvimento. No entanto, não é aconselhável usar logs não estruturados para fins de observabilidade em produção, pois são muito mais difíceis de analisar e interpretar em escala.
101+
102+
Exemplos de logs não estruturados:
103+
104+
```text
105+
[ERROR] 2024-08-04 12:45:23 - Failed to connect to database. Exception: java.sql.SQLException: Timeout expired. Attempted reconnect 3 times. Server: db.example.com, Port: 5432
106+
107+
System reboot initiated at 2024-08-04 03:00:00 by user: admin. Reason: Scheduled maintenance. Services stopped: web-server, database, cache. Estimated downtime: 15 minutes.
108+
109+
DEBUG - 2024-08-04 09:30:15 - User johndoe performed action: file_upload. Filename: report_Q3_2024.pdf, Size: 2.3 MB, Duration: 5.2 seconds. Result: Success
110+
```
111+
112+
É possível armazenar e analisar logs não estruturados em produção, embora você possa precisar fazer um trabalho substancial para analisá-los ou processa-los previamente de outra forma para que sejam legíveis por máquina. Por exemplo, os três logs acima exigirão uma expressão regular para analisar a marcação de data e hora e personalizar analisadores para extrair consistentemente os corpos da mensagem de log. Isso geralmente será necessário para que um backend de logging saiba como classificar e organizar os logs por data e hora. Embora seja possível processar logs não estruturados para análise, fazer isso pode dar mais trabalho do que mudar para logs estruturados, através de um framework de logging padrão em suas aplicações.

0 commit comments

Comments
 (0)