From 2f37a997ff018af5fedd3f96a5e89ce8693ab386 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Tue, 13 Aug 2024 18:39:09 -0300 Subject: [PATCH 01/13] feat: add localization signal log --- content/pt/docs/concepts/signals/logs.md | 27 ++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 content/pt/docs/concepts/signals/logs.md diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md new file mode 100644 index 000000000000..10a01df33f45 --- /dev/null +++ b/content/pt/docs/concepts/signals/logs.md @@ -0,0 +1,27 @@ +--- +title: Logs +description: Uma gravação de um evento. +weight: 3 +cSpell:ignore: filelogreceiver semistructured transformprocessor +--- + +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. + +## Logs do OpenTelemetry + +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). + +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. + +### Logs do OpenTelemetry no OpenTelemetry Collector + +O [OpenTelemetry Collector](/docs/collector) fornece várias ferramentas para trabalhar com logs: + +- Vários _receivers_ que analisam logs de fontes específicas e conhecidas de dados de logs. +- 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. +- _Processors_ como o `transformprocessor`, permite analisar dados aninhados, simplificar estruturas complexas, adicionando/removendo/atualizando valores e mais. +- _Exporters_ permitem emitir dados de log em um formato não OpenTelemetry. + +O primeiro passo na adoção do OpenTelemetry frequentemente envolve implantar um Collector como um agente de logging de propósito geral. + + From 0e5a2192a73655e7d4ddf86a2f74a303696a8b11 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Fri, 16 Aug 2024 19:35:44 -0300 Subject: [PATCH 02/13] feat: add localization signal log --- content/pt/docs/concepts/signals/logs.md | 85 ++++++++++++++++++++++++ 1 file changed, 85 insertions(+) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index 10a01df33f45..eb243720cbf6 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -24,4 +24,89 @@ O [OpenTelemetry Collector](/docs/collector) fornece várias ferramentas para tr O primeiro passo na adoção do OpenTelemetry frequentemente envolve implantar um Collector como um agente de logging de propósito geral. +### Logs do OpenTelemetry para aplicações +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. + +### Suporte a Linguagens + +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: + +{{% signal-support-table "logs" %}} + +## Logs estruturados, não estruturados e semiestruturados + +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. + +### Logs estruturados + +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: + +```json +{ + "timestamp": "2024-08-04T12:34:56.789Z", + "level": "INFO", + "service": "user-authentication", + "environment": "production", + "message": "User login successful", + "context": { + "userId": "12345", + "username": "johndoe", + "ipAddress": "192.168.1.1", + "userAgent": "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", + "duration": 200, + "request": { + "method": "POST", + "url": "/api/v1/login", + "headers": { + "Content-Type": "application/json", + "Accept": "application/json" + }, + "body": { + "username": "johndoe", + "password": "******" + } + }, + "response": { + "statusCode": 200, + "body": { + "success": true, + "token": "jwt-token-here" + } + } +} +``` + +e para componentes de infraestrutura, o _Common Log Format (CLF)_ é frequentemente usado: + +```text +127.0.0.1 - johndoe [04/Aug/2024:12:34:56 -0400] "POST /api/v1/login HTTP/1.1" 200 1234 +``` + +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. + +```text +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"}} +``` + +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. + +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. + +### Logs não estruturados + +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. + +Exemplos de logs não estruturados: + +```text +[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 + +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. + +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 +``` + +É 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. From 3b91491a326207c8786e84db21503ec442764c2e Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Mon, 19 Aug 2024 20:11:00 -0300 Subject: [PATCH 03/13] feat: run lint --- content/pt/docs/concepts/signals/logs.md | 206 +++++++++++++++++++---- 1 file changed, 174 insertions(+), 32 deletions(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index eb243720cbf6..22d29fb33f57 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -2,45 +2,75 @@ title: Logs description: Uma gravação de um evento. weight: 3 -cSpell:ignore: filelogreceiver semistructured transformprocessor +default_lang_commit: ebc9a3a9f07278110677f4f8f69291a02704746b --- -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. - -## Logs do OpenTelemetry - -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). - -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. - -### Logs do OpenTelemetry no OpenTelemetry Collector - -O [OpenTelemetry Collector](/docs/collector) fornece várias ferramentas para trabalhar com logs: - -- Vários _receivers_ que analisam logs de fontes específicas e conhecidas de dados de logs. -- 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. -- _Processors_ como o `transformprocessor`, permite analisar dados aninhados, simplificar estruturas complexas, adicionando/removendo/atualizando valores e mais. +Um **log** é um registro de texto com uma marcação 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. + +## Logs do OpenTelemetry {#opentelemetry-logs} + +O OpenTelemetry não possui uma especificação de API ou SDK própria 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). + +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. + +### Logs do OpenTelemetry no OpenTelemetry Collector {#opentelemetry-logs-in-the-opentelemetry-collector} + +O [OpenTelemetry Collector](/docs/collector) fornece várias ferramentas para +trabalhar com logs: + +- Vários _receivers_ que analisam logs de fontes específicas e conhecidas de + dados de logs. +- 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. +- _Processors_ como o `transformprocessor`, permite analisar dados aninhados, + simplificar estruturas complexas, adicionando/removendo/atualizando valores e + mais. - _Exporters_ permitem emitir dados de log em um formato não OpenTelemetry. -O primeiro passo na adoção do OpenTelemetry frequentemente envolve implantar um Collector como um agente de logging de propósito geral. +O primeiro passo na adoção do OpenTelemetry frequentemente envolve implantar um +Collector como um agente de logging de propósito geral. -### Logs do OpenTelemetry para aplicações +### Logs do OpenTelemetry para aplicações {#opentelemetry-logs-for-applications} -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. +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. -### Suporte a Linguagens +### Suporte a linguagens {#language-support} -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: +Log é 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: {{% signal-support-table "logs" %}} -## Logs estruturados, não estruturados e semiestruturados +## Logs estruturados, não estruturados e semiestruturados {#structured-unstructured-and-semistructured-logs} -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. +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. -### Logs estruturados +### Logs estruturados {#structured-logs} -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: +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: ```json { @@ -79,25 +109,39 @@ Um log estruturado é aquele que segue um formato consistente e legível por má } ``` -e para componentes de infraestrutura, o _Common Log Format (CLF)_ é frequentemente usado: +e para componentes de infraestrutura, o _Common Log Format (CLF)_ é +frequentemente usado: ```text 127.0.0.1 - johndoe [04/Aug/2024:12:34:56 -0400] "POST /api/v1/login HTTP/1.1" 200 1234 ``` -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. +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. ```text 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"}} ``` -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. +Para aproveitar ao máximo este log, analise tanto os dados em formato JSON +quanto os em formato ELF, utilizando 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. -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. +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. -### Logs não estruturados +### Logs não estruturados {#unstructured-logs} -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. +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. Exemplos de logs não estruturados: @@ -109,4 +153,102 @@ System reboot initiated at 2024-08-04 03:00:00 by user: admin. Reason: Scheduled 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 ``` -É 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. +É possível armazenar e analisar logs não estruturados em produção, embora seja +necessário realizar um trabalho significativo para analisá-los ou processa-los +antes de serem legíveis por máquinas. 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 de forma consistente os campos da mensagem de log. +Isso geralmente é 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. + +### Logs Semiestruturados {#semistructured-logs} + +Um log semiestruturado é um log que utiliza alguns padrões autoconsistentes para +distinguir dados de forma que sejam legíveis por máquinas, mas pode não usar o +mesmo formato e delimitadores entre os dados em diferentes sistemas. + +Exemplo de um log semiestruturado: + +```text +2024-08-04T12:45:23Z level=ERROR service=user-authentication userId=12345 action=login message="Failed login attempt" error="Invalid password" ipAddress=192.168.1.1 userAgent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36" +``` + +Embora sejam legíveis por máquinas, logs semiestruturados podem precisar de +diferentes tipos de analisadores para permitir a interpretação em grande escala. + +## Componentes de logging do OpenTelemetry {#opentelemetry-logging-components} + +A seguir estão listados os conceitos e componentes que sustentam o suporte de +logging do OpenTelemetry. + +### Conector / Ponte de Log {#log-appender--bridge} + +Como desenvolvedor de aplicações, você não deve chamar diretamente a **Logs +Bridge API**, pois é destinada a desenvolvedores de bibliotecas de logging para +construir conectores ou pontes de log. Em vez disso, você deve usar sua +biblioteca de logging preferida e configurá-la para utilizar um conector de log +(ou ponte de log) capaz de emitir logs para um OpenTelemetry +_LogRecordExporter_. + +Os SDKs do OpenTelemetry oferecem essa funcionalidade. + +### Logger Provider + +> A parte da **Logs Bridge API** deve ser usada apenas por aqueles que +> desenvolvem uma biblioteca de logging. + +O Logger Provider (às vezes chamado de _LoggerProvider_) é uma fábrica de +`Logger`s. Na maioria dos casos, o Logger Provider é inicializado uma vez, e seu +ciclo de vida coincide com o ciclo de vida da aplicação. A inicialização do +Logger Provider também inclui a inicialização do Resource e Exporter. + +### Logger + +> A parte da **Logs Bridge API** deve ser usada apenas por aqueles que +> desenvolvem uma biblioteca de logging. + +Um Logger cria registros de log. Loggers são criados a partir do Log Providers. + +### Log Record Exporter + +Os Log Record Exporters enviam registros de log para um consumidor. Esse +consumidor pode ser a saída padrão para depuração de desenvolvimento, +OpenTelemetry Collector ou qualquer backend de código aberto ou de fornecedor de +sua escolha. + +### Log Record + +Um log record representa a gravação de um evento. No OpenTelemetry, um log +record contém dois tipos de campos: + +- Campos nomeados de nível superior com tipo e significado específicos +- Campos de recurso e atributos com valor e tipo variáveis + +Os campos de nível superior são: + +| Nome do Campo | Descrição | +| -------------------- | --------------------------------------------------------- | +| Timestamp | Momento em que o evento ocorreu. | +| ObservedTimestamp | Momento em que o evento foi observado. | +| TraceId | ID de rastreamento da solicitação. | +| SpanId | ID do trecho da solicitação. | +| TraceFlags | Flag de rastreamento W3C. | +| SeverityText | Texto de severidade (também conhecido como nível de log). | +| SeverityNumber | Valor numérico da severidade. | +| Body | O corpo do registro de log. | +| Resource | Descreve a origem do log. | +| InstrumentationScope | Descreve o escopo que emitiu o log. | +| Attributes | Informações adicionais sobre o evento. | + +Para mais detalhes sobre registros de log e campos de log, consulte +[Modelo de Dados de Logs](/docs/specs/otel/logs/data-model/). + +### Especificação {#specification} + +Para saber mais sobre logs no OpenTelemetry, consulte a [especificação +de logs][]. + +[especificação de logs]: /docs/specs/otel/overview/#log-signal From 6bf069875c5a470842701802beb110aa40d96b08 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Tue, 20 Aug 2024 21:10:50 -0300 Subject: [PATCH 04/13] fix: update doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Emídio Neto <9735060+emdneto@users.noreply.github.com> --- content/pt/docs/concepts/signals/logs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index 22d29fb33f57..f07582344688 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -127,7 +127,7 @@ separados por espaços em um log CLF. Para aproveitar ao máximo este log, analise tanto os dados em formato JSON quanto os em formato ELF, utilizando 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 +[OpenTelemetry Collector](/docs/collector) contém maneiras padronizadas de analisar logs como estes. Logs estruturados são a melhor forma de usar logs. Por serem emitidos em um From ef2b01f26185131e2e0e53f9349a2a571cb21ffb Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Sun, 25 Aug 2024 12:54:28 -0300 Subject: [PATCH 05/13] fix: igonre cspell --- content/pt/docs/concepts/signals/logs.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index f07582344688..4f654db1c3a2 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -3,6 +3,7 @@ title: Logs description: Uma gravação de um evento. weight: 3 default_lang_commit: ebc9a3a9f07278110677f4f8f69291a02704746b +cSpell:ignore: filelogreceiver semistructured transformprocessor --- Um **log** é um registro de texto com uma marcação de data e hora, seja @@ -127,7 +128,7 @@ separados por espaços em um log CLF. Para aproveitar ao máximo este log, analise tanto os dados em formato JSON quanto os em formato ELF, utilizando um formato compartilhado para facilitar a análise em um backend de observabilidade. O `filelogreceiver` no -[OpenTelemetry Collector](/docs/collector) contém maneiras padronizadas de +[OpenTelemetry Coletor](/docs/collector) contém maneiras padronizadas de analisar logs como estes. Logs estruturados são a melhor forma de usar logs. Por serem emitidos em um From 00d4ebe3eb42e9e2ebb47bf3a3131fc3c803d506 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Sun, 25 Aug 2024 12:58:51 -0300 Subject: [PATCH 06/13] fix: igonre cspell --- .cspell/pt-palavras.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.cspell/pt-palavras.txt b/.cspell/pt-palavras.txt index e69de29bb2d1..e44f150a1ac4 100644 --- a/.cspell/pt-palavras.txt +++ b/.cspell/pt-palavras.txt @@ -0,0 +1,2 @@ +autoinstrumentação +autoconsistentes From 63690eb4b3e2bc993fe5bba88376edd79ea88969 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Sun, 25 Aug 2024 20:47:37 -0300 Subject: [PATCH 07/13] Update content/pt/docs/concepts/signals/logs.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Emídio Neto <9735060+emdneto@users.noreply.github.com> --- content/pt/docs/concepts/signals/logs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index 4f654db1c3a2..3e6349b1085d 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -110,7 +110,7 @@ máquina. Para aplicações, um dos formatos mais comuns é o JSON: } ``` -e para componentes de infraestrutura, o _Common Log Format (CLF)_ é +e para componentes de infraestrutura, o _Common Log Format_ (CLF) é frequentemente usado: ```text From f953a7251ee1a693a32eaf3892dd296bff781c5b Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Tue, 27 Aug 2024 15:19:19 -0300 Subject: [PATCH 08/13] Update content/pt/docs/concepts/signals/logs.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Emídio Neto <9735060+emdneto@users.noreply.github.com> --- content/pt/docs/concepts/signals/logs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index 3e6349b1085d..5cf9eaf9d386 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -118,7 +118,7 @@ frequentemente usado: ``` 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 +um log no formato _Extended Log Format_ (ELF) pode combinar JSON com os dados separados por espaços em um log CLF. ```text From 758348b45ab5e256231b6ef4d229b0acc9e3d5f0 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Tue, 27 Aug 2024 15:19:52 -0300 Subject: [PATCH 09/13] fix? apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Emídio Neto <9735060+emdneto@users.noreply.github.com> --- content/pt/docs/concepts/signals/logs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index 5cf9eaf9d386..2b3db1035cf7 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -128,12 +128,12 @@ separados por espaços em um log CLF. Para aproveitar ao máximo este log, analise tanto os dados em formato JSON quanto os em formato ELF, utilizando 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 +[OpenTelemetry Collector](/docs/collector) contém maneiras padronizadas de analisar logs como estes. 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 +pré-processamento no OpenTelemetry Collector, a correlação com outros dados e, por fim, a análise em um backend de Observabilidade. ### Logs não estruturados {#unstructured-logs} From 9f4e7316afc0887bfab2c06f7a9ee9d2a50d6a89 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Tue, 27 Aug 2024 15:55:27 -0300 Subject: [PATCH 10/13] fix: run lint --- content/pt/docs/concepts/signals/logs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index 2b3db1035cf7..e78a70da193b 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -133,8 +133,8 @@ analisar logs como estes. 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 Collector, a correlação com outros dados e, por -fim, a análise em um backend de Observabilidade. +pré-processamento no OpenTelemetry Collector, a correlação com outros dados e, +por fim, a análise em um backend de Observabilidade. ### Logs não estruturados {#unstructured-logs} From 130c9565d03c8dcae56cbf2023fd5586250a45a0 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Tue, 27 Aug 2024 18:08:08 -0300 Subject: [PATCH 11/13] fix: apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Emídio Neto <9735060+emdneto@users.noreply.github.com> --- content/pt/docs/concepts/signals/logs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index e78a70da193b..9e061dac227b 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -1,6 +1,6 @@ --- title: Logs -description: Uma gravação de um evento. +description: Um registro de um evento. weight: 3 default_lang_commit: ebc9a3a9f07278110677f4f8f69291a02704746b cSpell:ignore: filelogreceiver semistructured transformprocessor From add8556d2a7b827dc2224b6c587132af46542778 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Sat, 31 Aug 2024 11:01:12 -0300 Subject: [PATCH 12/13] fix: apply suggestions from code review Co-authored-by: Luiz Aoqui --- content/pt/docs/concepts/signals/logs.md | 79 ++++++++++++------------ 1 file changed, 39 insertions(+), 40 deletions(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index 9e061dac227b..ed086b7f0bd8 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -6,22 +6,21 @@ default_lang_commit: ebc9a3a9f07278110677f4f8f69291a02704746b cSpell:ignore: filelogreceiver semistructured transformprocessor --- -Um **log** é um registro de texto com uma marcação de data e hora, seja -estruturado (recomendado) ou não estruturado, com metadados opcionais. Dentre os +Um **log** é um registro de texto com marcação de data e hora, que pode ser tanto +estruturado (recomendado) quanto não estruturado, e 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. +linguagens de programação possuem recursos nativos ou bibliotecas bem conhecidas e amplamente utilizadas para gerar logs. ## Logs do OpenTelemetry {#opentelemetry-logs} O OpenTelemetry não possui uma especificação de API ou SDK própria 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 +logs. Em vez disso, os logs no OpenTelemetry são os logs que você já +possui, que foram gerados por 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). 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 +com o 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. @@ -35,27 +34,27 @@ trabalhar com logs: - 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. - _Processors_ como o `transformprocessor`, permite analisar dados aninhados, - simplificar estruturas complexas, adicionando/removendo/atualizando valores e + simplificar estruturas complexas, adicionar/remover/atualizar valores e mais. - _Exporters_ permitem emitir dados de log em um formato não OpenTelemetry. O primeiro passo na adoção do OpenTelemetry frequentemente envolve implantar um -Collector como um agente de logging de propósito geral. +Collector como um agente de logging genérico. ### Logs do OpenTelemetry para aplicações {#opentelemetry-logs-for-applications} -Em aplicações, logs do OpenTelemetry são criados com qualquer biblioteca de -logging ou recursos integrados de logging. Quando você adiciona +Em aplicações, logs do OpenTelemetry são criados com qualquer biblioteca +ou recursos nativos para geração de logs. 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. +seus logs com os rastros e trechos, incluindo os seus IDs no corpo do log. Em +outras palavras, o OpenTelemetry automaticamente correlaciona seus logs com os +seus rastros. -### Suporte a linguagens {#language-support} +### Linguagens suportadas {#language-support} Log é 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: +especificação do OpenTelemetry. Para as implementações específicas da API +e SDK de Logs em cada linguagem, temos o seguinte estado: {{% signal-support-table "logs" %}} @@ -117,7 +116,7 @@ frequentemente usado: 127.0.0.1 - johndoe [04/Aug/2024:12:34:56 -0400] "POST /api/v1/login HTTP/1.1" 200 1234 ``` -Também é comum ter logs estruturados em diferentes formatos juntos. Por exemplo, +Também é comum ter logs estruturados com uma mistura de formatos. Por exemplo, um log no formato _Extended Log Format_ (ELF) pode combinar JSON com os dados separados por espaços em um log CLF. @@ -125,14 +124,14 @@ separados por espaços em um log CLF. 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"}} ``` -Para aproveitar ao máximo este log, analise tanto os dados em formato JSON -quanto os em formato ELF, utilizando um formato compartilhado para facilitar a -análise em um backend de observabilidade. O `filelogreceiver` no +Para aproveitar ao máximo este log, transforme tantos os dados formatados em JSON +quanto os formatados em ELF em um mesmo formato comum para facilitar a +análise em um backend de observabilidade. O `filelogreceiver` do [OpenTelemetry Collector](/docs/collector) contém maneiras padronizadas de analisar logs como estes. 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 +formato consistente, eles são simples de extrair informações, o que facilita o pré-processamento no OpenTelemetry Collector, a correlação com outros dados e, por fim, a análise em um backend de Observabilidade. @@ -158,17 +157,17 @@ DEBUG - 2024-08-04 09:30:15 - User johndoe performed action: file_upload. Filena necessário realizar um trabalho significativo para analisá-los ou processa-los antes de serem legíveis por máquinas. 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 de forma consistente os campos da mensagem de log. -Isso geralmente é necessário para que um _backend_ de logging saiba como +analisadores para extrair os campos da mensagem de log de forma consistente. +Isso geralmente é necessário para que um _backend_ de log 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 +mudar para logs estruturados, através de um framework de log padrão em suas aplicações. ### Logs Semiestruturados {#semistructured-logs} -Um log semiestruturado é um log que utiliza alguns padrões autoconsistentes para -distinguir dados de forma que sejam legíveis por máquinas, mas pode não usar o +Um log semiestruturado é um log que utiliza um padrão interno consistente para +distinguir dados de forma que sejam legíveis por máquinas, mas que pode não usar o mesmo formato e delimitadores entre os dados em diferentes sistemas. Exemplo de um log semiestruturado: @@ -178,19 +177,19 @@ Exemplo de um log semiestruturado: ``` Embora sejam legíveis por máquinas, logs semiestruturados podem precisar de -diferentes tipos de analisadores para permitir a interpretação em grande escala. +diferentes tipos de analisadores para interpretação em grande escala. -## Componentes de logging do OpenTelemetry {#opentelemetry-logging-components} +## Componentes de logs do OpenTelemetry {#opentelemetry-logging-components} A seguir estão listados os conceitos e componentes que sustentam o suporte de -logging do OpenTelemetry. +log do OpenTelemetry. ### Conector / Ponte de Log {#log-appender--bridge} -Como desenvolvedor de aplicações, você não deve chamar diretamente a **Logs -Bridge API**, pois é destinada a desenvolvedores de bibliotecas de logging para +Como desenvolvedor de aplicações, você não deve chamar diretamente a **API de Logs +Bridge**, pois ela é destinada a pessoas desenvolvendo bibliotecas de geração de logs que querem construir conectores ou pontes de log. Em vez disso, você deve usar sua -biblioteca de logging preferida e configurá-la para utilizar um conector de log +biblioteca de log preferida e configurá-la para utilizar um conector de log (ou ponte de log) capaz de emitir logs para um OpenTelemetry _LogRecordExporter_. @@ -198,26 +197,26 @@ Os SDKs do OpenTelemetry oferecem essa funcionalidade. ### Logger Provider -> A parte da **Logs Bridge API** deve ser usada apenas por aqueles que -> desenvolvem uma biblioteca de logging. +> Parte da **API de Logs Bridge** e deve ser usada apenas se você estiver +> desenvolvendo uma biblioteca de log. -O Logger Provider (às vezes chamado de _LoggerProvider_) é uma fábrica de +Um Logger Provider (às vezes chamado de `LoggerProvider`) é uma fábrica de `Logger`s. Na maioria dos casos, o Logger Provider é inicializado uma vez, e seu ciclo de vida coincide com o ciclo de vida da aplicação. A inicialização do Logger Provider também inclui a inicialização do Resource e Exporter. ### Logger -> A parte da **Logs Bridge API** deve ser usada apenas por aqueles que -> desenvolvem uma biblioteca de logging. +> Parte da **API de Logs Bridge** e deve ser usada apenas se você estiver +> desenvolvendo uma biblioteca de log. Um Logger cria registros de log. Loggers são criados a partir do Log Providers. ### Log Record Exporter Os Log Record Exporters enviam registros de log para um consumidor. Esse -consumidor pode ser a saída padrão para depuração de desenvolvimento, -OpenTelemetry Collector ou qualquer backend de código aberto ou de fornecedor de +consumidor pode ser a saída padrão de um terminal para depuração durante o desenvolvimento, +o OpenTelemetry Collector, ou qualquer backend de código aberto ou de fornecedor de sua escolha. ### Log Record From 8449c79aa10547ab297b77eb949bcf395793bec6 Mon Sep 17 00:00:00 2001 From: Ezzio Moreira Date: Sat, 31 Aug 2024 11:06:15 -0300 Subject: [PATCH 13/13] fix: run lint local --- content/pt/docs/concepts/signals/logs.md | 66 ++++++++++++------------ 1 file changed, 32 insertions(+), 34 deletions(-) diff --git a/content/pt/docs/concepts/signals/logs.md b/content/pt/docs/concepts/signals/logs.md index ed086b7f0bd8..04c928aada25 100644 --- a/content/pt/docs/concepts/signals/logs.md +++ b/content/pt/docs/concepts/signals/logs.md @@ -6,17 +6,18 @@ default_lang_commit: ebc9a3a9f07278110677f4f8f69291a02704746b cSpell:ignore: filelogreceiver semistructured transformprocessor --- -Um **log** é um registro de texto com marcação de data e hora, que pode ser tanto -estruturado (recomendado) quanto não estruturado, e com metadados opcionais. Dentre os -sinais de telemetria, os logs têm uma história mais consolidada. A maioria das -linguagens de programação possuem recursos nativos ou bibliotecas bem conhecidas e amplamente utilizadas para gerar logs. +Um **log** é um registro de texto com marcação de data e hora, que pode ser +tanto estruturado (recomendado) quanto não estruturado, e com metadados +opcionais. Dentre os sinais de telemetria, os logs têm uma história mais +consolidada. A maioria das linguagens de programação possuem recursos nativos ou +bibliotecas bem conhecidas e amplamente utilizadas para gerar logs. ## Logs do OpenTelemetry {#opentelemetry-logs} O OpenTelemetry não possui uma especificação de API ou SDK própria para gerar -logs. Em vez disso, os logs no OpenTelemetry são os logs que você já -possui, que foram gerados por um framework de _logging_ ou componente de infraestrutura. Os SDKs e a -autoinstrumentação do OpenTelemetry utilizam vários componentes para +logs. Em vez disso, os logs no OpenTelemetry são os logs que você já possui, que +foram gerados por 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). O suporte do OpenTelemetry para logs é projetado para ser totalmente compatível @@ -34,8 +35,7 @@ trabalhar com logs: - 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. - _Processors_ como o `transformprocessor`, permite analisar dados aninhados, - simplificar estruturas complexas, adicionar/remover/atualizar valores e - mais. + simplificar estruturas complexas, adicionar/remover/atualizar valores e mais. - _Exporters_ permitem emitir dados de log em um formato não OpenTelemetry. O primeiro passo na adoção do OpenTelemetry frequentemente envolve implantar um @@ -43,18 +43,17 @@ Collector como um agente de logging genérico. ### Logs do OpenTelemetry para aplicações {#opentelemetry-logs-for-applications} -Em aplicações, logs do OpenTelemetry são criados com qualquer biblioteca -ou recursos nativos para geração de logs. Quando você adiciona -autoinstrumentação ou ativa um SDK, o OpenTelemetry automaticamente correlaciona -seus logs com os rastros e trechos, incluindo os seus IDs no corpo do log. Em -outras palavras, o OpenTelemetry automaticamente correlaciona seus logs com os -seus rastros. +Em aplicações, logs do OpenTelemetry são criados com qualquer biblioteca ou +recursos nativos para geração de logs. Quando você adiciona autoinstrumentação +ou ativa um SDK, o OpenTelemetry automaticamente correlaciona seus logs com os +rastros e trechos, incluindo os seus IDs no corpo do log. Em outras palavras, o +OpenTelemetry automaticamente correlaciona seus logs com os seus rastros. ### Linguagens suportadas {#language-support} Log é um sinal [estável](/docs/specs/otel/versioning-and-stability/#stable) na -especificação do OpenTelemetry. Para as implementações específicas da API -e SDK de Logs em cada linguagem, temos o seguinte estado: +especificação do OpenTelemetry. Para as implementações específicas da API e SDK +de Logs em cada linguagem, temos o seguinte estado: {{% signal-support-table "logs" %}} @@ -124,8 +123,8 @@ separados por espaços em um log CLF. 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"}} ``` -Para aproveitar ao máximo este log, transforme tantos os dados formatados em JSON -quanto os formatados em ELF em um mesmo formato comum para facilitar a +Para aproveitar ao máximo este log, transforme tantos os dados formatados em +JSON quanto os formatados em ELF em um mesmo formato comum para facilitar a análise em um backend de observabilidade. O `filelogreceiver` do [OpenTelemetry Collector](/docs/collector) contém maneiras padronizadas de analisar logs como estes. @@ -158,17 +157,16 @@ necessário realizar um trabalho significativo para analisá-los ou processa-los antes de serem legíveis por máquinas. 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 os campos da mensagem de log de forma consistente. -Isso geralmente é necessário para que um _backend_ de log 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 log padrão em suas -aplicações. +Isso geralmente é necessário para que um _backend_ de log 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 log padrão em suas aplicações. ### Logs Semiestruturados {#semistructured-logs} Um log semiestruturado é um log que utiliza um padrão interno consistente para -distinguir dados de forma que sejam legíveis por máquinas, mas que pode não usar o -mesmo formato e delimitadores entre os dados em diferentes sistemas. +distinguir dados de forma que sejam legíveis por máquinas, mas que pode não usar +o mesmo formato e delimitadores entre os dados em diferentes sistemas. Exemplo de um log semiestruturado: @@ -186,11 +184,11 @@ log do OpenTelemetry. ### Conector / Ponte de Log {#log-appender--bridge} -Como desenvolvedor de aplicações, você não deve chamar diretamente a **API de Logs -Bridge**, pois ela é destinada a pessoas desenvolvendo bibliotecas de geração de logs que querem -construir conectores ou pontes de log. Em vez disso, você deve usar sua -biblioteca de log preferida e configurá-la para utilizar um conector de log -(ou ponte de log) capaz de emitir logs para um OpenTelemetry +Como desenvolvedor de aplicações, você não deve chamar diretamente a **API de +Logs Bridge**, pois ela é destinada a pessoas desenvolvendo bibliotecas de +geração de logs que querem construir conectores ou pontes de log. Em vez disso, +você deve usar sua biblioteca de log preferida e configurá-la para utilizar um +conector de log (ou ponte de log) capaz de emitir logs para um OpenTelemetry _LogRecordExporter_. Os SDKs do OpenTelemetry oferecem essa funcionalidade. @@ -215,9 +213,9 @@ Um Logger cria registros de log. Loggers são criados a partir do Log Providers. ### Log Record Exporter Os Log Record Exporters enviam registros de log para um consumidor. Esse -consumidor pode ser a saída padrão de um terminal para depuração durante o desenvolvimento, -o OpenTelemetry Collector, ou qualquer backend de código aberto ou de fornecedor de -sua escolha. +consumidor pode ser a saída padrão de um terminal para depuração durante o +desenvolvimento, o OpenTelemetry Collector, ou qualquer backend de código aberto +ou de fornecedor de sua escolha. ### Log Record