You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Um **log** é um registro de texto com um carimbo de data e hora, seja estruturado (recomendado) ou não estruturado, com metadados opcionais. Dentre os sinais de telemetria, os logs têm uma história mais consolidada. A maioria das linguagens de programação possui recursos de logging embutidas ou bibliotecas de logging bem conhecidas e amplamente utilizadas.
9
-
10
-
## Logs do OpenTelemetry
11
-
12
-
O OpenTelemetry não possui uma especificação de API ou SDK específica para gerar logs. Em vez disso, os logs no OpenTelemetry são os logs existentes que você já possui de um framework de logging ou componente de infraestrutura. Os SDKs e a autoinstrumentação do OpenTelemetry utilizam vários componentes para correlacionar automaticamente logs com [rastros](/docs/concepts/signals/traces).
13
-
14
-
O suporte do OpenTelemetry para logs é projetado para ser totalmente compatível ao que você já possui, oferecendo a capacidade de adicionar contextos a esses logs e uma série de ferramentas para analisar e manipular logs em um formato comum, abrangendo diversas fontes.
15
-
16
-
### Logs do OpenTelemetry no OpenTelemetry Collector
17
-
18
-
O [OpenTelemetry Collector](/docs/collector) fornece várias ferramentas para trabalhar com logs:
19
-
20
-
- Vários _receivers_ que analisam logs de fontes específicas e conhecidas de dados de logs.
21
-
- O `filelogreceiver`, que lê logs de qualquer arquivo e fornece recursos para analisá-los a partir de diferentes formatos ou usar uma expressão regular.
22
-
-_Processors_ como o `transformprocessor`, permite analisar dados aninhados, simplificar estruturas complexas, adicionando/removendo/atualizando valores e mais.
8
+
Um **log** é um registro de texto com uma marcação de data e hora, seja
9
+
estruturado (recomendado) ou não estruturado, com metadados opcionais. Dentre os
10
+
sinais de telemetria, os logs têm uma história mais consolidada. A maioria das
11
+
linguagens de programação possui recursos de logging embutidas ou bibliotecas de
12
+
logging bem conhecidas e amplamente utilizadas.
13
+
14
+
## Logs do OpenTelemetry {#opentelemetry-logs}
15
+
16
+
O OpenTelemetry não possui uma especificação de API ou SDK própria para gerar
17
+
logs. Em vez disso, os logs no OpenTelemetry são os logs existentes que você já
18
+
possui de um framework de logging ou componente de infraestrutura. Os SDKs e a
19
+
autoinstrumentação do OpenTelemetry utilizam vários componentes para
20
+
correlacionar automaticamente logs com [rastros](/docs/concepts/signals/traces).
21
+
22
+
O suporte do OpenTelemetry para logs é projetado para ser totalmente compatível
23
+
ao que você já possui, oferecendo a capacidade de adicionar contextos a esses
24
+
logs e uma série de ferramentas para analisar e manipular logs em um formato
25
+
comum, abrangendo diversas fontes.
26
+
27
+
### Logs do OpenTelemetry no OpenTelemetry Collector {#opentelemetry-logs-in-the-opentelemetry-collector}
28
+
29
+
O [OpenTelemetry Collector](/docs/collector) fornece várias ferramentas para
30
+
trabalhar com logs:
31
+
32
+
- Vários _receivers_ que analisam logs de fontes específicas e conhecidas de
33
+
dados de logs.
34
+
- O `filelogreceiver`, que lê logs de qualquer arquivo e fornece recursos para
35
+
analisá-los a partir de diferentes formatos ou usar uma expressão regular.
36
+
-_Processors_ como o `transformprocessor`, permite analisar dados aninhados,
37
+
simplificar estruturas complexas, adicionando/removendo/atualizando valores e
38
+
mais.
23
39
-_Exporters_ permitem emitir dados de log em um formato não OpenTelemetry.
24
40
25
-
O primeiro passo na adoção do OpenTelemetry frequentemente envolve implantar um Collector como um agente de logging de propósito geral.
41
+
O primeiro passo na adoção do OpenTelemetry frequentemente envolve implantar um
42
+
Collector como um agente de logging de propósito geral.
26
43
27
-
### Logs do OpenTelemetry para aplicações
44
+
### Logs do OpenTelemetry para aplicações {#opentelemetry-logs-for-applications}
28
45
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.
46
+
Em aplicações, logs do OpenTelemetry são criados com qualquer biblioteca de
47
+
logging ou recursos integrados de logging. Quando você adiciona
48
+
autoinstrumentação ou ativa um SDK, o OpenTelemetry automaticamente correlaciona
49
+
seus logs com os rastros e trechos, incluindo no corpo do log seus IDs. Em
50
+
outras palavras, o OpenTelemetry automaticamente correlaciona seus logs e
51
+
rastros.
30
52
31
-
### Suporte a Linguagens
53
+
### Suporte a linguagens {#language-support}
32
54
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:
55
+
Log é um sinal [estável](/docs/specs/otel/versioning-and-stability/#stable) na
56
+
especificação do OpenTelemetry. Para as implementações específicas de cada
57
+
linguagem da API e SDK de Logs, temos o seguinte estado:
34
58
35
59
{{% signal-support-table "logs" %}}
36
60
37
-
## Logs estruturados, não estruturados e semiestruturados
61
+
## Logs estruturados, não estruturados e semiestruturados {#structured-unstructured-and-semistructured-logs}
38
62
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.
63
+
Tecnicamente o OpenTelemetry não distingue entre logs estruturados e não
64
+
estruturados. Você pode usar qualquer log que tiver com o OpenTelemetry. No
65
+
entanto, nem todos os formatos de log são igualmente úteis! Logs estruturados,
66
+
em particular, são recomendados para observabilidade em produção porque são
67
+
fáceis de analisar e interpretar em escala. A seção a seguir explica as
68
+
diferenças entre logs estruturados, não estruturados e semiestruturados.
40
69
41
-
### Logs estruturados
70
+
### Logs estruturados {#structured-logs}
42
71
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:
72
+
Um log estruturado é aquele que segue um formato consistente e legível por
73
+
máquina. Para aplicações, um dos formatos mais comuns é o JSON:
44
74
45
75
```json
46
76
{
@@ -79,25 +109,39 @@ Um log estruturado é aquele que segue um formato consistente e legível por má
79
109
}
80
110
```
81
111
82
-
e para componentes de infraestrutura, o _Common Log Format (CLF)_ é frequentemente usado:
112
+
e para componentes de infraestrutura, o _Common Log Format (CLF)_ é
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.
119
+
Também é comum ter logs estruturados em diferentes formatos juntos. Por exemplo,
120
+
um log no formato _Extended Log Format (ELF)_ pode combinar JSON com os dados
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.
127
+
Para aproveitar ao máximo este log, analise tanto os dados em formato JSON
128
+
quanto os em formato ELF, utilizando um formato compartilhado para facilitar a
129
+
análise em um backend de observabilidade. O `filelogreceiver` no
130
+
[OpenTelemetry Coletor](/docs/collector) contém maneiras padronizadas de
131
+
analisar logs como estes.
95
132
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.
133
+
Logs estruturados são a melhor forma de usar logs. Por serem emitidos em um
134
+
formato consistente, os logs são analisados diretamente, o que facilita o
135
+
pré-processamento no OpenTelemetry Coletor, a correlação com outros dados e, por
136
+
fim, a análise em um backend de Observabilidade.
97
137
98
-
### Logs não estruturados
138
+
### Logs não estruturados {#unstructured-logs}
99
139
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.
140
+
Logs não estruturados são logs que não seguem uma estrutura consistente. Eles
141
+
podem ser mais legíveis para humanos e são frequentemente usados em
142
+
desenvolvimento. No entanto, não é aconselhável usar logs não estruturados para
143
+
fins de observabilidade em produção, pois são muito mais difíceis de analisar e
144
+
interpretar em escala.
101
145
102
146
Exemplos de logs não estruturados:
103
147
@@ -109,4 +153,102 @@ System reboot initiated at 2024-08-04 03:00:00 by user: admin. Reason: Scheduled
109
153
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
154
```
111
155
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.
156
+
É possível armazenar e analisar logs não estruturados em produção, embora seja
157
+
necessário realizar um trabalho significativo para analisá-los ou processa-los
158
+
antes de serem legíveis por máquinas. Por exemplo, os três logs acima exigirão
159
+
uma expressão regular para analisar a marcação de data e hora e personalizar
160
+
analisadores para extrair de forma consistente os campos da mensagem de log.
161
+
Isso geralmente é necessário para que um _backend_ de logging saiba como
162
+
classificar e organizar os logs por data e hora. Embora seja possível processar
163
+
logs não estruturados para análise, fazer isso pode dar mais trabalho do que
164
+
mudar para logs estruturados, através de um framework de logging padrão em suas
165
+
aplicações.
166
+
167
+
### Logs Semiestruturados {#semistructured-logs}
168
+
169
+
Um log semiestruturado é um log que utiliza alguns padrões autoconsistentes para
170
+
distinguir dados de forma que sejam legíveis por máquinas, mas pode não usar o
171
+
mesmo formato e delimitadores entre os dados em diferentes sistemas.
0 commit comments