As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Transformar logs durante a ingestão
Com a transformação e o enriquecimento dos registros, você pode normalizar todos os seus registros em um formato consistente e contextual no momento da ingestão no Logs. CloudWatch [Você pode adicionar estrutura aos seus registros usando modelos pré-configurados para AWS serviços comuns, como AWS WAF o Amazon Route 53, ou criar transformadores personalizados com analisadores nativos, como o Grok.](CloudWatch-Logs-Transformation-Configurable.md#CloudWatch-Logs-Transformation-Grok) Você também pode renomear atributos existentes e adicionar outros metadados aos seus logs, como ID da conta e região.
A transformação de logs ajuda a simplificar e encurtar suas consultas de logs nos aplicativos e ajuda a simplificar a criação de alertas em seus logs. Esse recurso fornece transformação para tipos de log comuns com modelos de out-of-the-box transformação para as principais fontes de AWS log, como registros de fluxo de VPC, Route 53 e. Amazon RDS for PostgreSQL Você pode usar modelos de transformação pré-configurados ou criar transformadores personalizados para atender às suas necessidades.
A transformação de logs ajuda você a gerenciar logs emitidos de múltiplas fontes que variam muito em formato e nomes de atributos.
Depois de criar um transformador, os eventos de log ingeridos são convertidos e armazenados em um formato padrão. Você pode aproveitar esses logs transformados para acelerar sua experiência de analytics com os seguintes recursos:
+ [Índices de campo](CloudWatchLogs-Field-Indexing.md)
+ [CloudWatch Campos descobertos do Logs Insights](CWL_AnalyzeLogData-discoverable-fields.md)
+ Flexibilidade em alarmes usando [filtros métricos](MonitoringLogData.md)
+ Encaminhamento por meio de [filtros de assinatura](Subscriptions.md)
+ Criação de dados métricos a partir de eventos de logs com o [ Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html), onde você pode optar por fazer com que a regra do Contributor Insights avalie os eventos de logs antes ou depois de serem transformados.
As transformações acontecem somente durante a ingestão de logs. Você não pode transformar eventos de logs que já foram ingeridos. As transformações não são reversíveis. Tanto os registros originais quanto os transformados são armazenados em CloudWatch registros com a mesma política de retenção. A capacidade de transformação e enriquecimento de logs está incluída no preço de ingestão da classe de log padrão existente. Os custos de armazenamento de logs serão baseados no tamanho do log após a transformação, o que pode exceder o volume original do log.
**Importante**
Depois que os eventos de registro forem transformados, você deverá usar as consultas do CloudWatch Logs Insights para visualizar as versões transformadas dos registros. As [ FilterLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_FilterLogEvents.html)ações [ GetLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_GetLogEvents.html)e retornam somente as versões originais dos eventos de log, antes de serem transformados.
**Importante**
Apesar de um único evento de log PutLogEvents permitir até 1 MB, a transformação de registros só pode lidar com eventos de log de tamanho menor que 512 kb. Qualquer evento de registro maior que 512 kb falhará na transformação e emitirá um erro. O tamanho total de ainda PutLogEvents pode ultrapassar 512 kb.
Além de se transformar em formatos diferentes, você também pode enriquecer seus logs com contexto adicional, como ID da conta, região e palavra-chave. Eles são extraídos do nome do grupo de logs e de palavras-chave estáticas.
A transformação de logs ajuda você com logs emitidos de múltiplas fontes que variam muito em formato e nomes de atributos.
A transformação e o enriquecimento de logs só são compatíveis com grupos de logs da classe de logs Padrão.
Você pode criar transformadores para grupos de logs individuais, além de criar transformadores no nível da conta que se aplicam a todos ou a muitos grupos de logs da sua conta. Se um grupo de logs tiver um transformador em nível de grupo de logs, esse transformador substituirá qualquer transformador em nível de conta que, de outra forma, se aplicaria a esse grupo de logs.
**Topics**
+ [
# Crie e gerencie transformadores de log
](CloudWatch-Logs-Transformation-Create.md)
+ [
# Processadores configuráveis do tipo analisador
](CloudWatch-Logs-Transformation-Configurable.md)
+ [
# Processadores integrados para AWS registros vendidos
](CloudWatch-Logs-Transformation-BuiltIn.md)
+ [
# Processadores de mutação de string
](CloudWatch-Logs-Transformation-StringMutate.md)
+ [
# Processadores de mutação do JSON
](CloudWatch-Logs-Transformation-JSONMutate.md)
+ [
# Processadores de conversão de tipos de dados
](CloudWatch-Logs-Transformation-Datatype.md)
+ [
# Métricas e erros de transformação
](Transformation-Errors-Metrics.md)
# Crie e gerencie transformadores de log
Um transformador de log inclui um ou mais *processadores* que estão juntos em um pipeline lógico. Cada processador é aplicado a um evento de logs, um após o outro, na ordem em que estão listados na configuração do transformador.
Alguns processadores são do tipo *analisador*. Cada transformador deve ter pelo menos um analisador, e o primeiro processador em um transformador deve ser um analisador.
Alguns dos analisadores são do tipo integrado que são configurados para um determinado tipo de log AWS fornecido.
Outros tipos de processadores são mutadores de string, mutadores JSON e processadores de dados.
Você pode criar transformadores para grupos de logs individuais, além de criar transformadores no nível da conta que se aplicam a todos ou a muitos grupos de logs da sua conta. Se um grupo de logs tiver um transformador em nível de grupo de logs, esse transformador substituirá qualquer transformador em nível de conta que, de outra forma, se aplicaria a esse grupo de logs. Você pode ter até 20 transformadores no nível da conta em uma região na sua conta.
Ao criar um transformador, você deve seguir estas diretrizes:
+ Se você incluir um analisador pré-configurado para um tipo de registros AWS vendidos, ele deverá ser o primeiro processador listado no transformador. Você pode incluir apenas um desses processadores em um transformador.
+ Você pode incluir apenas um processador `grok` em um transformador.
+ Você deve ter pelo menos um processador do tipo analisador em um transformador. Você pode incluir até cinco processadores do tipo analisador. Esse limite de cinco inclui analisadores integrados e analisadores configuráveis.
+ Você pode ter até 20 processadores em um transformador.
+ Você pode incluir somente um processador **addKeys** em um transformador.
+ Você pode incluir somente um processador **copyValue** em um transformador.
+ Cada transformador pode extrair até 200 campos de um evento de logs.
+ Cada evento de registro **DEVE** estar abaixo de 512 KB. O tamanho total dos eventos de log ainda pode ultrapassar 512 KB.
**Topics**
+ [
# Crie uma política de transformador no nível da conta
](CloudWatchLogs-Transformer-CreateAccountLevel.md)
+ [
# Editar ou excluir uma política de transformador em nível de conta
](CloudWatchLogs-Transformer-EditAccountLevel.md)
+ [
# Crie um transformador de log-group-level toras do zero
](CloudWatch-Logs-Transformation-CreateNew.md)
+ [
# Crie um log-group-level transformador copiando um existente
](CloudWatch-Logs-Transformation-Copy.md)
+ [
# Editar um log-group-level transformador
](CloudWatch-Logs-Transformation-Edit.md)
+ [
# Excluir um log-group-level transformador
](CloudWatch-Logs-Transformation-Delete.md)
# Crie uma política de transformador no nível da conta
Use as etapas desta seção para criar uma política de transformador que se aplique a todos os grupos de logs na conta ou a vários grupos de logs que tenham nomes que comecem com a mesma string (prefixo). Você pode ter até 20 políticas de transformador no nível da conta em uma região.
Você não pode criar duas políticas de transformador na mesma região que usem o mesmo prefixo ou tenham um prefixo contido em outra. Por exemplo, se você criar uma política de transformador para o prefixo de string `/aws/lambda`, não poderá criar outra com o prefixo `/aws`. Mas você poderia ter um transformador para `/aws/lambda` e outro para `/aws/waf`
**Para criar uma política de transformador no nível da conta**
1. Abra o CloudWatch console em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Na barra de navegação à esquerda, escolha **Configurações** e, em seguida, escolha **Logs**.
1. Na seção **Política de transformador para conta**, escolha **Criar política de transformador**.
1. Em **Nome da política do transformador**, insira um nome para a sua nova política.
1. Em **Selecionar grupos de logs**, execute uma das seguintes ações:
+ Escolha **Todos os grupos de logs padrão** para que a política do transformador se aplique a todos os grupos de logs da Classe Padrão na conta.
+ escolha **Grupos de logs por correspondência de prefixo** para aplicar a política a um subconjunto de grupos de logs, todos com nomes que começam com a mesma string. Em seguida, insira o prefixo desses grupos de logs em **Critérios de seleção**.
1. Na área **Selecionar analisadores**, use **Analisadores** para selecionar um analisador a ser incluído em seu transformador.
Se for um analisador pré-configurado para um tipo de registro AWS vendido, você não precisa especificar nenhuma configuração para ele.
Se for um analisador diferente, é necessário especificar sua configuração. Para obter mais informações, consulte as informações para esse processador em [Processadores configuráveis do tipo analisador](CloudWatch-Logs-Transformation-Configurable.md).
1. Para adicionar outro processador, escolha **Selecionar processador**. Em seguida, selecione o processador desejado na caixa **Processador** e preencha os parâmetros de configuração.
Lembre-se de que os processadores operam nos eventos de logs na ordem em que você os adiciona ao transformador.
1. (Opcional) Para adicionar mais processadores, escolha **\$1 Processador** e repita a etapa anterior.
1. (Opcional) A qualquer momento, você pode testar o transformador construído até agora em um evento de logs de amostra. Para fazer isso, siga um dos seguintes procedimentos na seção **Visualização do transformador**:
+ Selecione até cinco grupos de logs em **Selecionar grupos de logs ** e, em seguida, escolha **Carregar eventos de logs mais recentes**. Em seguida, escolha **Testar transformador**.
+ Copie eventos de logs diretamente em **Eventos de logs de amostra** e escolha **Testar transformador**.
Em seguida, a versão transformada do log é exibida.
1. Quando terminar de adicionar processadores e estiver satisfeito com os testes nos logs de amostra, escolha **Salvar**.
1. Quando terminar, selecione **Create (Criar)**.
# Editar ou excluir uma política de transformador em nível de conta
Use as etapas nesta seção para editar ou excluir uma política de transformação no nível da conta.
**Para editar ou excluir uma política de transformador em nível de conta**
1. Abra o CloudWatch console em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Na barra de navegação à esquerda, escolha **Configurações** e, em seguida, escolha **Logs**.
1. Na seção **Polícia da conta do transformador**, selecione **Gerenciar**.
1. Selecione o botão ao lado da política de transformador que você deseja gerenciar e, em seguida, escolha **Editar** ou **Excluir**.
Se você estiver editando a política, consulte as etapas 5 a 11 em [Processadores configuráveis do tipo analisador](CloudWatch-Logs-Transformation-Configurable.md) para ver suas opções.
# Crie um transformador de log-group-level toras do zero
Use essas etapas para criar um log-group-level transformador do zero.
**Para usar o console para criar um transformador de logs para um grupo de logs**
1. Abra o CloudWatch console em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Logs**, **Grupos de log**.
1. Escolha o grupo de logs para o qual você deseja criar o transformador.
1. Escolha a guia **Transformador**. Talvez seja necessário rolar a lista de guias para a direita para vê-la.
1. Escolha **Criar transformador**.
1. Na caixa **Escolha um analisador**, selecione um analisador para incluir em seu transformador.
Se for um analisador pré-configurado para um tipo de registro AWS vendido, você não precisa especificar nenhuma configuração para ele.
Se for um analisador diferente, é necessário especificar sua configuração. Para obter mais informações, consulte as informações para esse processador em [Processadores configuráveis do tipo analisador](CloudWatch-Logs-Transformation-Configurable.md).
1. Para adicionar outro processador, escolha **\$1 Adicionar processador**. Em seguida, selecione o processador desejado na caixa **Escolher processadores** e preencha os parâmetros de configuração.
Lembre-se de que os processadores operam nos eventos de logs na ordem em que você os adiciona ao transformador.
1. (Opcional) A qualquer momento, você pode testar o transformador construído até agora em um evento de logs de amostra. Para isso, faça o seguinte:
1. Na seção **Visualização da transformação**, escolha **Carregar log de amostra** para carregar um evento de logs de amostra do grupo de logs ao qual esse transformador se destina ou cole um evento de logs na caixa de texto.
Escolha **Testar transformador**. A versão transformada do log é exibida
1. Quando terminar de adicionar processadores e estiver satisfeito com os testes nos logs de amostra, escolha **Salvar**.
**Para usar o AWS CLI para criar um transformador de log do zero**
+ Use o comando `aws logs put-transformer`. Ao usar o `parseJSON` como primeiro processador, você deve analisar todo o evento de logs usando `@message` como campo de origem. Após a análise inicial do JSON, você pode manipular campos específicos nos processadores subsequentes. Veja a seguir um exemplo que cria um transformador que inclui os processadores `parseJSON` e `addKeys`:
```
aws logs put-transformer \
--transformer-config '[{"parseJSON":{"source":"@message"}},{"addKeys":{"entries":[{"key":"metadata.transformed_in","value":"CloudWatchLogs"},{"key":"feature","value":"Transformation"}]}},{"trimString":{"withKeys":["status"]}}]' \
--log-group-identifier my-log-group-name
```
# Crie um log-group-level transformador copiando um existente
Você pode usar o console para copiar a configuração JSON de um transformador existente. Em seguida, você pode usar esse código para criar um transformador idêntico usando o AWS CLI, ou você pode modificar a configuração primeiro.
**Para criar um transformador de logs copiando um existente**
1. Abra o CloudWatch console em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Logs**, **Grupos de log**.
1. Escolha o grupo de logs que contém o transformador que você deseja copiar.
1. Escolha a guia **Transformações**. Talvez seja necessário rolar a lista de guias para a direita para vê-la.
1. Escolha **Gerenciar transformador**.
1. Escolha **Copiar transformador**. Isso copia o transformador JSON para a área de transferência.
1. Crie um arquivo e cole na configuração do transformador. Neste exemplo, chamamos o arquivo `CopiedTransformer.json`
1. Use o AWS CLI para criar um novo transformador com essa configuração.
```
aws logs put-transformer --log-group-identifier my-log-group-name \
--transformer-config file://CopiedTransformer.json
```
# Editar um log-group-level transformador
Use essas etapas para editar um transformador de logs existente.
**Para editar um transformador de log**
1. Abra o CloudWatch console em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Logs**, **Grupos de log**.
1. Escolha o grupo de logs que tem o transformador que você deseja editar.
1. Escolha a guia **Transformações**. Talvez seja necessário rolar a lista de guias para a direita para vê-la.
1. Escolha **Gerenciar transformador**.
1. Faça suas alterações nas seções **Analisadores** e **Processadores**.
1. Para adicionar outro processador, escolha **\$1 Adicionar processador**. Em seguida, selecione o processador desejado na caixa **Processador** e preencha os parâmetros de configuração.
Lembre-se de que os processadores operam nos eventos de logs na ordem em que você os adiciona ao transformador.
1. (Opcional) A qualquer momento, você pode testar o transformador construído até agora em um evento de logs de amostra. Para isso, faça o seguinte:
1. Na seção **Visualização da transformação**, escolha **Carregar log de amostra** para carregar um evento de logs de amostra do grupo de logs ao qual esse transformador se destina ou cole um evento de logs na caixa de texto.
Escolha **Testar transformação**. A versão transformada do log é exibida
1. Quando terminar de adicionar processadores e estiver satisfeito com os testes nos logs de amostra, escolha **Salvar**.
# Excluir um log-group-level transformador
Use essas etapas para excluir um transformador de log.
**Para excluir um transformador de log**
1. Abra o CloudWatch console em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Logs**, **Grupos de log**.
1. Escolha o grupo de logs que tem o transformador que você deseja editar.
1. Escolha a guia **Transformações**. Talvez seja necessário rolar a lista de guias para a direita para vê-la.
1. Escolha **Excluir**.
1. Na caixa de confirmação, escolha **Excluir política**.
# Processadores configuráveis do tipo analisador
Esta seção contém informações sobre os processadores de analisadores de dados configuráveis que você pode usar em um transformador de eventos de log.
**Contents**
+ [
## parseJSON
](#CloudWatch-Logs-Transformation-parseJSON)
+ [
## grok
](#CloudWatch-Logs-Transformation-Grok)
+ [
### Exemplos do Grok
](#Grok-Examples)
+ [
#### Exemplo 1: use o Grok para extrair um campo de logs não estruturados
](#Grok-Example1)
+ [
#### Exemplo 2: use o Grok em combinação com parseJSON para extrair campos de um evento de logs JSON
](#Grok-Example3)
+ [
#### Exemplo 3: padrão Grok com anotação pontilhada em FIELD\$1NAME
](#Grok-Example4)
+ [
### Padrões Grok compatíveis
](#Grok-Patterns)
+ [
#### Exemplos comuns de formato de log
](#Common-Log-Examples)
+ [
##### Exemplo de log do Apache
](#Apache-Log-Example)
+ [
##### Exemplo de log do NGINX
](#NGINX-Log-Example)
+ [
##### Exemplo de log do protocolo Syslog (RFC 5424)
](#syslog5424-Log-Example)
+ [
## csv
](#CloudWatch-Logs-Transformation-csv)
+ [
## parseKeyValue
](#CloudWatch-Logs-Transformation-parseKeyValue)
## parseJSON
O processador **parseJSON** analisa os eventos de logs JSON e insere os pares de valores-chave JSON extraídos no destino. Se você não especificar um destino, o processador colocará o par de valores-chave sob o nó raiz. Ao usar o `parseJSON` como primeiro processador, você deve analisar todo o evento de logs usando `@message` como campo de origem. Após a análise inicial do JSON, você pode manipular campos específicos nos processadores subsequentes.
O conteúdo `@message` original não é alterado, as novas chaves são adicionadas à mensagem.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| origem | Caminho para o campo no evento de logs que será analisado. Use a notação de pontos para acessar os campos secundários. Por exemplo, store.book. | Não | `@message` | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| destination | O campo de destino do JSON analisado | Não | `Parent JSON node` | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
**Exemplo**
Suponha que um evento de logs ingerido seja semelhante a:
```
{
"outer_key": {
"inner_key": "inner_value"
}
}
```
Então, se tivermos esse processador **parseJSON**:
```
[
{
"parseJSON": {
"destination": "new_key"
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"new_key": {
"outer_key": {
"inner_key": "inner_value"
}
}
}
```
## grok
Use o processador Grok para analisar e estruturar dados não estruturados usando correspondência de padrões. Esse processador também pode extrair campos de mensagens de log.
| Campo | Description | Obrigatório? | Padrão | Limites | Observações |
| --- | --- | --- | --- | --- | --- |
| origem | Caminho do campo no qual aplicar a correspondência Grok | Não | `@message` | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| match | O padrão Grok para combinar com o evento de logs | Sim | | Tamanho máximo: 512 Máximo de padrões Grok: 20 Alguns tipos de padrões Grok têm limites de uso individuais. Qualquer combinação dos seguintes padrões pode ser usada até cinco vezes: \$1URI, URIPARAM, URIPATHPARAM, SPACE, DATA, GREEDYDATA, GREEDYDATA\$1MULTILINE\$1 Os padrões Grok não oferecem suporte a conversões de tipos. Para padrões de formato de log comuns (APACHE\$1ACCESS\$1LOG, NGINX\$1ACCESS\$1LOG, SYSLOG5424), somente os padrões DATA, GREEDYDATA ou GREEDYDATA\$1MULTILINE podem ser incluídos após o padrão de log comum. | [Veja todos os padrões Grok compatíveis](#Grok-Patterns) |
**Estrutura de um padrão Grok**
Esta é a estrutura do padrão Grok compatível:
```
%{PATTERN_NAME:FIELD_NAME}
```
+ **PATTERN\$1NAME**: refere-se a uma expressão regular predefinida para corresponder a um tipo específico de dados. Somente [padrões grok predefinidos são suportados](#Grok-Patterns). Não é permitido criar padrões personalizados.
+ **FIELD\$1NAME**: atribui um nome ao valor extraído. `FIELD_NAME` é opcional, mas se você não especificar esse valor, os dados extraídos serão eliminados do evento de logs transformado. Se `FIELD_NAME` usa notação pontilhada (por exemplo, “parent.child”), ele é considerado um caminho JSON.
+ **Conversão de tipo**: conversões de tipo explícitas não são suportadas. Use o [TypeConverter processador](CloudWatch-Logs-Transformation-Datatype.md#CloudWatch-Logs-Transformation-typeConverter) para converter o tipo de dados de qualquer valor extraído pelo grok.
Para criar expressões de correspondência mais complexas, você pode combinar vários padrões Grok. Até 20 padrões Grok podem ser combinados para corresponder a um evento de logs. Por exemplo, essa combinação de padrões `%{NUMBER:timestamp} [%{NUMBER:db} %{IP:client_ip}:%{NUMBER:client_port}] %{GREEDYDATA:data}` pode ser usada para extrair campos de uma entrada de log lenta do Redis, como esta:
`1629860738.123456 [0 127.0.0.1:6379] "SET" "key1" "value1"`
### Exemplos do Grok
#### Exemplo 1: use o Grok para extrair um campo de logs não estruturados
Log de amostra:
```
293750 server-01.internal-network.local OK "[Thread-000] token generated"
```
Transformador usado:
```
[
{
"grok": {
"match": "%{NUMBER:version} %{HOSTNAME:hostname} %{NOTSPACE:status} %{QUOTEDSTRING:logMsg}"
}
}
]
```
Saída:
```
{
"version": "293750",
"hostname": "server-01.internal-network.local",
"status": "OK",
"logMsg": "[Thread-000] token generated"
}
```
Log de amostra:
```
23/Nov/2024:10:25:15 -0900 172.16.0.1 200
```
Transformador usado:
```
[
{
"grok": {
"match": "%{HTTPDATE:timestamp} %{IPORHOST:clientip} %{NUMBER:response_status}"
}
}
]
```
Saída:
```
{
"timestamp": "23/Nov/2024:10:25:15 -0900",
"clientip": "172.16.0.1",
"response_status": "200"
}
```
#### Exemplo 2: use o Grok em combinação com parseJSON para extrair campos de um evento de logs JSON
Log de amostra:
```
{
"timestamp": "2024-11-23T16:03:12Z",
"level": "ERROR",
"logMsg": "GET /page.html HTTP/1.1"
}
```
Transformador usado:
```
[
{
"parseJSON": {}
},
{
"grok": {
"source": "logMsg",
"match": "%{WORD:http_method} %{NOTSPACE:request} HTTP/%{NUMBER:http_version}"
}
}
]
```
Saída:
```
{
"timestamp": "2024-11-23T16:03:12Z",
"level": "ERROR",
"logMsg": "GET /page.html HTTP/1.1",
"http_method": "GET",
"request": "/page.html",
"http_version": "1.1"
}
```
#### Exemplo 3: padrão Grok com anotação pontilhada em FIELD\$1NAME
Log de amostra:
```
192.168.1.1 GET /index.html?param=value 200 1234
```
Transformador usado:
```
[
{
"grok": {
"match": "%{IP:client.ip} %{WORD:method} %{URIPATHPARAM:request.uri} %{NUMBER:response.status} %{NUMBER:response.bytes}"
}
}
]
```
Saída:
```
{
"client": {
"ip": "192.168.1.1"
},
"method": "GET",
"request": {
"uri": "/index.html?param=value"
},
"response": {
"status": "200",
"bytes": "1234"
}
}
```
### Padrões Grok compatíveis
As tabelas a seguir listam os padrões que são compatíveis com o processador `grok`.
**Padrões Grok gerais**
| Padrão Grok | Description | Limite máximo de padrões | Exemplo |
| --- | --- | --- | --- |
| USERNAME ou USER | Corresponde a um ou mais caracteres que podem incluir letras minúsculas (a-z), letras maiúsculas (A-Z), dígitos (0-9), pontos (.), sublinhados (\$1) ou hifens (-). | 20 | Entrada: `user123.name-TEST` Padrão: `%{USERNAME:name}` Saída: `{"name": "user123.name-TEST"}` |
| INT | Corresponde a um sinal opcional de mais ou menos seguido por um ou mais dígitos. | 20 | Entrada: `-456` Padrão: `%{INT:num}` Saída: `{"num": "-456"}` |
| BASE10NUM | Corresponde a um número inteiro ou de ponto flutuante com sinal e ponto decimal opcionais | 20 | Entrada: `-0.67` Padrão: `%{BASE10NUM:num}` Saída: `{"num": "-0.67"}` |
| BASE16NUM | Combina números decimais e hexadecimais com um sinal opcional (\$1 ou -) e um prefixo 0x opcional | 20 | Entrada: `+0xA1B2` Padrão: `%{BASE16NUM:num}` Saída: `{"num": "+0xA1B2"}` |
| POSINT | Corresponde a números inteiros positivos sem zeros à esquerda, consistindo em um ou mais dígitos (1-9 seguido por 0-9) | 20 | Entrada: `123` Padrão: `%{POSINT:num}` Saída: `{"num": "123"}` |
| NONNEGINT | Corresponde a qualquer número inteiro (consistindo em um ou mais dígitos de 0 a 9), incluindo zero e números com zeros à esquerda. | 20 | Entrada: `007` Padrão: `%{NONNEGINT:num}` Saída: `{"num": "007"}` |
| WORD | Corresponde a palavras inteiras compostas por um ou mais caracteres (\$1w), incluindo letras, dígitos e sublinhados | 20 | Entrada: `user_123` Padrão: `%{WORD:user}` Saída: `{"user": "user_123"}` |
| NOTSPACE | Corresponde a um ou mais caracteres que não sejam espaços em branco. | 5 | Entrada: `hello_world123` Padrão: `%{NOTSPACE:msg}` Saída: `{"msg": "hello_world123"}` |
| SPACE | Corresponde a zero ou mais caracteres de espaço em branco. | 5 | Entrada: `" "` Padrão: `%{SPACE:extra}` Saída: `{"extra": " "}` |
| DATA | Corresponde a qualquer caractere (exceto nova linha) zero ou mais vezes, de forma não gananciosa. | 5 | Entrada: `abc def ghi` Padrão: `%{DATA:x} %{DATA:y}` Saída: `{"x": "abc", "y": "def ghi"}` |
| GREEDYDATA | Corresponde a qualquer caractere (exceto nova linha) zero ou mais vezes, de forma gananciosa. | 5 | Entrada: `abc def ghi` Padrão: `%{GREEDYDATA:x} %{GREEDYDATA:y}` Saída: `{"x": "abc def", "y": "ghi"}` |
| GREEDYDATA\$1MULTILINE | Corresponde a qualquer caractere (incluindo nova linha) zero ou mais vezes, de forma gananciosa. | 1 | Entrada: `abc` `def` `ghi` Padrão: `%{GREEDYDATA_MULTILINE:data}` Saída: `{"data": "abc\ndef\nghi"}` |
| QUOTEDSTRING | Combina cadeias de caracteres entre aspas (aspas simples ou duplas) com caracteres de escape. | 20 | Entrada: `"Hello, world!"` Padrão: `%{QUOTEDSTRING:msg}` Saída: `{"msg": "Hello, world!"}` |
| UUID | Corresponde a um formato UUID padrão: 8 caracteres hexadecimais, seguidos por três grupos de 4 caracteres hexadecimais e terminando com 12 caracteres hexadecimais, todos separados por hifens. | 20 | Entrada: `550e8400-e29b-41d4-a716-446655440000` Padrão: `%{UUID:id}` Saída: `{"id": "550e8400-e29b-41d4-a716-446655440000"}` |
| URN | Corresponde à sintaxe URN (Uniform Resource Name). | 20 | Entrada: `urn:isbn:0451450523` Padrão: `%{URN:urn}` Saída: `{"urn": "urn:isbn:0451450523"}` |
**AWS padrões grok**
| Padrão | Description | Limite máximo de padrões | Exemplo |
| --- | --- | --- | --- |
| ARN | Corresponde aos nomes de recursos da AWS Amazon (ARNs), capturando a partição (`aws`,`aws-cn`, ou`aws-us-gov`), o serviço, a região, o ID da conta e até 5 identificadores hierárquicos de recursos separados por barras. Não corresponderá às informações ARNs que faltam entre dois pontos. | 5 | Entrada: `arn:aws:iam:us-east-1:123456789012:user/johndoe` Padrão: `%{ARN:arn}` Saída: `{"arn": "arn:aws:iam:us-east-1:123456789012:user/johndoe"}` |
**Padrões Grok de redes**
| Padrão Grok | Description | Limite máximo de padrões | Exemplo |
| --- | --- | --- | --- |
| CISCOMAC | Corresponde a um endereço MAC no formato hexadecimal 4-4-4. | 20 | Entrada: `0123.4567.89AB` Padrão: `%{CISCOMAC:MacAddress}` Saída: `{"MacAddress": "0123.4567.89AB"}` |
| WINDOWSMAC | Corresponde a um endereço MAC em formato hexadecimal com hifens | 20 | Entrada: `01-23-45-67-89-AB` Padrão: `%{WINDOWSMAC:MacAddress}` Saída: `{"MacAddress": "01-23-45-67-89-AB"}` |
| COMMONMAC | Corresponde a um endereço MAC em formato hexadecimal com dois pontos. | 20 | Entrada: `01:23:45:67:89:AB` Padrão: `%{COMMONMAC:MacAddress}` Saída: `{"MacAddress": "01:23:45:67:89:AB"}` |
| Mac | Corresponde a um dos padrões Grok CISCOMAC, WINDOWSMAC ou COMMONMAC | 20 | Entrada: `01:23:45:67:89:AB` Padrão: `%{MAC:m1}` Saída: `{"m1":"01:23:45:67:89:AB"}` |
| IPV6 | Corresponde a IPv6 endereços, incluindo formulários compactados e endereços IPv4 mapeados IPv6 . | 5 | Entrada: `2001:db8:3333:4444:5555:6666:7777:8888` Padrão: `%{IPV6:ip}` Saída: `{"ip": "2001:db8:3333:4444:5555:6666:7777:8888"}` |
| IPV4 | Corresponde a um IPv4 endereço. | 20 | Entrada: `192.168.0.1` Padrão: `%{IPV4:ip}` Saída: `{"ip": "192.168.0.1"}` |
| IP | Corresponde aos IPv6 endereços suportados por% \$1IPv6\$1 ou aos IPv4 endereços compatíveis com% \$1IPv4\$1 | 5 | Entrada: `192.168.0.1` Padrão: `%{IP:ip}` Saída: `{"ip": "192.168.0.1"}` |
| HOSTNAME ou HOST | Corresponde a nomes de domínio, incluindo subdomínios | 5 | Entrada: `server-01.internal-network.local` Padrão: `%{HOST:host}` Saída: `{"host": "server-01.internal-network.local"}` |
| IPORHOST | Corresponde a um nome de host ou endereço IP | 5 | Entrada: `2001:db8:3333:4444:5555:6666:7777:8888` Padrão: `%{IPORHOST:ip}` Saída: `{"ip": "2001:db8:3333:4444:5555:6666:7777:8888"}` |
| HOSTPORT | Corresponde a um endereço IP ou nome de host, conforme suportado pelo padrão %\$1IPORHOST\$1 seguido por dois pontos e um número de porta, capturando a porta como “PORT” na saída. | 5 | Entrada: `192.168.1.1:8080` Padrão: `%{HOSTPORT:ip}` Saída: `{"ip":"192.168.1.1:8080","PORT":"8080"}` |
| URIHOST | Corresponde a um endereço IP ou nome de host, conforme suportado pelo padrão %\$1IPORHOST\$1, opcionalmente seguido por dois pontos e um número de porta, capturando a porta como “port”, se presente. | 5 | Entrada: `example.com:443 10.0.0.1` Padrão: `%{URIHOST:host} %{URIHOST:ip}` Saída: `{"host":"example.com:443","port":"443","ip":"10.0.0.1"}` |
**Padrões Grok de caminho**
| Padrão Grok | Description | Limite máximo de padrões | Exemplo |
| --- | --- | --- | --- |
| UNIXPATH | Corresponde aos caminhos de URL, incluindo potencialmente parâmetros de consulta. | 20 | Entrada: `/search?q=regex` Padrão: `%{UNIXPATH:path}` Saída: `{"path":"/search?q=regex"}` |
| WINPATH | Corresponde aos caminhos dos arquivos do Windows. | 5 | Entrada: `C:\Users\John\Documents\file.txt` Padrão: `%{WINPATH:path}` Saída: `{"path": "C:\\Users\\John\\Documents\\file.txt"}` |
| PATH | Corresponde aos caminhos de arquivo do URL ou do Windows | 5 | Entrada: `/search?q=regex` Padrão: `%{PATH:path}` Saída: `{"path":"/search?q=regex"}` |
| TTY | Combina caminhos de dispositivos Unix para terminais e pseudoterminais. | 20 | Entrada: `/dev/tty1` Padrão: `%{TTY:path}` Saída: `{"path":"/dev/tty1"}` |
| URIPROTO | Corresponde a letras, opcionalmente seguidas por um caractere de adição (\$1) e letras adicionais ou caracteres de adição (\$1) | 20 | Entrada: `web+transformer` Padrão: `%{URIPROTO:protocol}` Saída: `{"protocol":"web+transformer"}` |
| URIPATH | Corresponde ao componente de caminho de um URI | 20 | Entrada: `/category/sub-category/product_name` Padrão: `%{URIPATH:path}` Saída: `{"path":"/category/sub-category/product_name"}` |
| URIPARAM | Corresponde aos parâmetros de consulta de URL | 5 | Entrada: `?param1=value1¶m2=value2` Padrão: `%{URIPARAM:url}` Saída: `{"url":"?param1=value1¶m2=value2"}` |
| URIPATHPARAM | Corresponde a um caminho de URI, opcionalmente seguido por parâmetros de consulta | 5 | Entrada: `/category/sub-category/product?id=12345&color=red` Padrão: `%{URIPATHPARAM:path}` Saída: `{"path":"/category/sub-category/product?id=12345&color=red"}` |
| URI | Corresponde a um URI completo | 5 | Entrada: `https://user:password@example.com/path/to/resource?param1=value1¶m2=value2` Padrão: `%{URI:uri}` Saída: `{"path":"https://user:password@example.com/path/to/resource?param1=value1¶m2=value2"}` |
**Padrões Grok de data e hora**
| Padrão Grok | Description | Limite máximo de padrões | Exemplo |
| --- | --- | --- | --- |
| MONTH | Combina nomes completos ou abreviados dos meses em inglês como palavras inteiras | 20 | Entrada: `Jan` Padrão: `%{MONTH:month}` Saída: `{"month":"Jan"}` Entrada: `January` Padrão: `%{MONTH:month}` Saída: `{"month":"January"}` |
| MONTHNUM | Corresponde aos números dos meses de 1 a 12, com zero inicial opcional para meses de um dígito. | 20 | Entrada: `5` Padrão: `%{MONTHNUM:month}` Saída: `{"month":"5"}` Entrada: `05` Padrão: `%{MONTHNUM:month}` Saída: `{"month":"05"}` |
| MONTHNUM2 | Corresponde a números de meses de dois dígitos de 01 a 12. | 20 | Entrada: `05` Padrão: `%{MONTHNUM2:month}` Saída: `{"month":"05"}` |
| MONTHDAY | Corresponde ao dia do mês de 1 a 31, com zero inicial opcional. | 20 | Entrada: `31` Padrão: `%{MONTHDAY:monthDay}` Saída: `{"monthDay":"31"}` |
| YEAR | Corresponde ao ano em dois ou quatro dígitos | 20 | Entrada: `2024` Padrão: `%{YEAR:year}` Saída: `{"year":"2024"}` Entrada: `24` Padrão: `%{YEAR:year}` Saída: `{"year":"24"}` |
| DAY | Corresponde aos nomes dos dias completos ou abreviados. | 20 | Entrada: `Tuesday` Padrão: `%{DAY:day}` Saída: `{"day":"Tuesday"}` |
| HOUR | Corresponde à hora no formato de 24 horas com um zero (0)0-23 à esquerda opcional. | 20 | Entrada: `22` Padrão: `%{HOUR:hour}` Saída: `{"hour":"22"}` |
| MINUTE | Corresponde aos minutos (00-59). | 20 | Entrada: `59` Padrão: `%{MINUTE:min}` Saída: `{"min":"59"}` |
| SECOND | Corresponde a um número que representa os segundos (0)0-60, opcionalmente seguido por um ponto decimal ou dois pontos e um ou mais dígitos para minutos fracionários | 20 | Entrada: `3` Padrão: `%{SECOND:second}` Saída: `{"second":"3"}` Entrada: `30.5` Padrão: `%{SECOND:minSec}` Saída: `{"minSec":"30.5"}` Entrada: `30:5` Padrão: `%{SECOND:minSec}` Saída: `{"minSec":"30:5"}` |
| TIME | Corresponde a um formato de tempo com horas, minutos e segundos no formato (H)H:mm:(s)s. Os segundos incluem o segundo bissexto (0)0-60. | 20 | Entrada: `09:45:32` Padrão: `%{TIME:time}` Saída: `{"time":"09:45:32"}` |
| DATE\$1US | Corresponde a uma data no formato (M)M/(d)d/(aa)aa ou (M)M-(d)d-(aa)aa. | 20 | Entrada: `11/23/2024` Padrão: `%{DATE_US:date}` Saída: `{"date":"11/23/2024"}` Entrada: `1-01-24` Padrão: `%{DATE_US:date}` Saída: `{"date":"1-01-24"}` |
| DATE\$1EU | Corresponde à data no formato (d)d/(M)M/(aa)aa, (d)d-(M)M-(aa)aa ou (d)d.(M)M.(aa)aa. | 20 | Entrada: `23/11/2024` Padrão: `%{DATE_EU:date}` Saída: `{"date":"23/11/2024"}` Entrada: `1.01.24` Padrão: `%{DATE_EU:date}` Saída: `{"date":"1.01.24"}` |
| ISO8601\$1FUSO HORÁRIO | Corresponde ao deslocamento UTC 'Z' ou ao deslocamento de fuso horário com dois pontos opcionais no formato [\$1-](H)H(:)mm. | 20 | Entrada: `+05:30` Padrão: `%{ISO8601_TIMEZONE:tz}` Saída: `{"tz":"+05:30"}` Entrada: `-530` Padrão: `%{ISO8601_TIMEZONE:tz}` Saída: `{"tz":"-530"}` Entrada: `Z` Padrão: `%{ISO8601_TIMEZONE:tz}` Saída: `{"tz":"Z"}` |
| ISO8601\$1SEGUNDO | Corresponde a um número que representa os segundos (0)0-60, opcionalmente seguido por um ponto decimal ou dois pontos e um ou mais dígitos por segundos fracionários | 20 | Entrada: `60` Padrão: `%{ISO8601_SECOND:second}` Saída: `{"second":"60"}` |
| CARIMBO DE DATA/HORA \$1 ISO8601 | Corresponde ao formato de ISO8601 data e hora (yy) yy- (M) M- (d) dT (H) H:mm: ((s) s) (Z\$1 [\$1-] (H) H:mm) com segundos e fuso horário opcionais. | 20 | Entrada: `2023-05-15T14:30:00+05:30` Padrão: `%{TIMESTAMP_ISO8601:timestamp}` Saída: `{"timestamp":"2023-05-15T14:30:00+05:30"}` Entrada: `23-5-1T1:25+5:30` Padrão: `%{TIMESTAMP_ISO8601:timestamp}` Saída: `{"timestamp":"23-5-1T1:25+5:30"}` Entrada: `23-5-1T1:25Z` Padrão: `%{TIMESTAMP_ISO8601:timestamp}` Saída: `{"timestamp":"23-5-1T1:25Z"}` |
| DATE | Corresponde a uma data no formato dos EUA usando %\$1DATE\$1US\$1 ou no formato da UE usando %\$1DATE\$1EU\$1 | 20 | Entrada: `11/29/2024` Padrão: `%{DATE:date}` Saída: `{"date":"11/29/2024"}` Entrada: `29.11.2024` Padrão: `%{DATE:date}` Saída: `{"date":"29.11.2024"}` |
| DATESTAMP | Corresponde a %\$1DATE\$1 seguido pelo padrão %\$1TIME\$1, separado por espaço ou hífen. | 20 | Entrada: `29-11-2024 14:30:00` Padrão: `%{DATESTAMP:dateTime}` Saída: `{"dateTime":"29-11-2024 14:30:00"}` |
| TZ | Corresponde às abreviações de fuso horário comuns (PST, PDT, MST, MDT, CST CDT, EST, EDT, UTC). | 20 | Entrada: `PDT` Padrão: `%{TZ:tz}` Saída: `{"tz":"PDT"}` |
| CARIMBO DE DATA\$1 RFC822 | Corresponde à data e hora no formato: Dia MonthName (D) D (YY) YY (H) H:mm :( s) s Fuso horário | 20 | Entrada: `Monday Jan 5 23 1:30:00 CDT` Padrão: `%{DATESTAMP_RFC822:dateTime}` Saída: `{"dateTime":"Monday Jan 5 23 1:30:00 CDT"}` Entrada: `Mon January 15 2023 14:30:00 PST` Padrão: `%{DATESTAMP_RFC822:dateTime}` Saída: `{"dateTime":"Mon January 15 2023 14:30:00 PST"}` |
| CARIMBO DE DATA\$1 RFC2822 | Corresponde ao formato RFC2822 de data e hora: Dia, (d) d MonthName (yy) yy (H) H:mm :( s) s Z\$1 [\$1-] (H) H:mm | 20 | Entrada: `Mon, 15 May 2023 14:30:00 +0530` Padrão: `%{DATESTAMP_RFC2822:dateTime}` Saída: `{"dateTime":"Mon, 15 May 2023 14:30:00 +0530"}` Entrada: `Monday, 15 Jan 23 14:30:00 Z` Padrão: `%{DATESTAMP_RFC2822:dateTime}` Saída: `{"dateTime":"Monday, 15 Jan 23 14:30:00 Z"}` |
| DATESTAMP\$1OTHER | Corresponde à data e hora no formato: Dia MonthName (d) d (H) H:mm :( s) s Fuso horário (yy) yy | 20 | Entrada: `Mon May 15 14:30:00 PST 2023` Padrão: `%{DATESTAMP_OTHER:dateTime}` Saída: `{"dateTime":"Mon May 15 14:30:00 PST 2023"}` |
| DATESTAMP\$1EVENTLOG | Corresponde ao formato compacto de data e hora sem separadores: (aa)aaMM(d)d(H)Hmm(s)s | 20 | Entrada: `20230515143000` Padrão: `%{DATESTAMP_EVENTLOG:dateTime}` Saída: `{"dateTime":"20230515143000"}` |
**Padrões Grok de log**
| Padrão Grok | Description | Limite máximo de padrões | Exemplo |
| --- | --- | --- | --- |
| LOGLEVEL | Corresponde aos níveis de log padrão em diferentes letras maiúsculas e abreviações, incluindo as seguintes: Alert/ALERT, Trace/TRACE, Debug/DEBUG, Notice/NOTICE, Info/INFO, Warn/Warning/WARN/WARNING, Err/Error/ERR/ERROR, Crit/Critical/CRIT/CRITICAL, Fatal/FATAL, Severe/SEVERE, Emerg/Emergency/EMERG/EMERGENCY | 20 | Entrada: `INFO` Padrão: `%{LOGLEVEL:logLevel}` Saída: `{"logLevel":"INFO"}` |
| HTTPDATE | Corresponde ao formato de data e hora frequentemente usado em arquivos de log. Formato: (d) MonthName d/ (yy) yy :( H) H:mm :( s) s Fuso horário: corresponde aos nomes completos ou abreviados dos meses em inglês (exemplo MonthName: “janeiro” ou “janeiro”) Fuso horário: corresponde ao padrão% \$1INT\$1 grok | 20 | Entrada: `23/Nov/2024:14:30:00 +0640` Padrão: `%{HTTPDATE:date}` Saída: `{"date":"23/Nov/2024:14:30:00 +0640"}` |
| SYSLOGTIMESTAMP | Corresponde ao formato de data com MonthName (d) d (H) H:mm :( s) s MonthName: Corresponde aos nomes completos ou abreviados dos meses em inglês (exemplo: “janeiro” ou “janeiro”) | 20 | Entrada: `Nov 29 14:30:00` Padrão: `%{SYSLOGTIMESTAMP:dateTime}` Saída: `{"dateTime":"Nov 29 14:30:00"}` |
| PROG | Corresponde a um nome de programa que consiste em uma sequência de letras, dígitos, ponto, sublinhado, barra, sinal de porcentagem e caracteres de hífen. | 20 | Entrada: `user.profile/settings-page` Padrão: `%{PROG:program}` Saída: `{"program":"user.profile/settings-page"}` |
| SYSLOGPROG | Corresponde ao padrão Grok PROG opcionalmente seguido por um ID de processo entre colchetes. | 20 | Entrada: `user.profile/settings-page[1234]` Padrão: `%{SYSLOGPROG:programWithId}` Saída: `{"programWithId":"user.profile/settings-page[1234]","program":"user.profile/settings-page","pid":"1234"}` |
| SYSLOGHOST | Corresponde a um padrão %\$1HOST\$1 ou %\$1IP\$1 | 5 | Entrada: `2001:db8:3333:4444:5555:6666:7777:8888` Padrão: `%{SYSLOGHOST:ip}` Saída: `{"ip": "2001:db8:3333:4444:5555:6666:7777:8888"}` |
| SYSLOGFACILITY | Corresponde à prioridade do syslog no formato decimal. O valor deve estar entre colchetes angulares (<>). | 20 | Entrada: `<13.6>` Padrão: `%{SYSLOGFACILITY:syslog}` Saída: `{"syslog":"<13.6>","facility":"13","priority":"6"}` |
**Padrões Grok de log comum**
Você pode usar padrões Grok personalizados predefinidos para corresponder aos formatos de log Apache, NGINX e protocolo Syslog (RFC 5424). Quando você usa esses padrões específicos, eles devem ser os primeiros em sua configuração correspondente, e nenhum outro padrão pode precedê-los. Além disso, você pode segui-los somente com exatamente um **DADO**. Padrão **GREEDYDATA** ou **GREEDYDATA\$1MULTILINE**,
| Padrão grok | Description | Limite máximo de padrões |
| --- | --- | --- |
| APACHE ACCESS\$1LOG | Corresponde aos logs de acesso do Apache | 1 |
| NGINX\$1ACCESS\$1LOG | Corresponde aos logs de acesso do NGINX | 1 |
| SYSLOG5424 | Corresponde aos logs do protocolo Syslog (RFC 5424) | 1 |
Veja a seguir exemplos válidos e inválidos do uso desses padrões comuns de formato de log.
```
"%{NGINX_ACCESS_LOG} %{DATA}" // Valid
"%{SYSLOG5424}%{DATA:logMsg}" // Valid
"%{APACHE_ACCESS_LOG} %{GREEDYDATA:logMsg}" // Valid
"%{APACHE_ACCESS_LOG} %{SYSLOG5424}" // Invalid (multiple common log patterns used)
"%{NGINX_ACCESS_LOG} %{NUMBER:num}" // Invalid (Only GREEDYDATA and DATA patterns are supported with common log patterns)
"%{GREEDYDATA:logMsg} %{SYSLOG5424}" // Invalid (GREEDYDATA and DATA patterns are supported only after common log patterns)
```
#### Exemplos comuns de formato de log
##### Exemplo de log do Apache
Log de amostra:
```
127.0.0.1 - - [03/Aug/2023:12:34:56 +0000] "GET /page.html HTTP/1.1" 200 1234
```
Transformador:
```
[
{
"grok": {
"match": "%{APACHE_ACCESS_LOG}"
}
}
]
```
Saída:
```
{
"request": "/page.html",
"http_method": "GET",
"status_code": 200,
"http_version": "1.1",
"response_size": 1234,
"remote_host": "127.0.0.1",
"timestamp": "2023-08-03T12:34:56Z"
}
```
##### Exemplo de log do NGINX
Log de amostra:
```
192.168.1.100 - Foo [03/Aug/2023:12:34:56 +0000] "GET /account/login.html HTTP/1.1" 200 42 "https://www.amazon.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36"
```
Transformador:
```
[
{
"grok": {
"match": "%{NGINX_ACCESS_LOG}"
}
}
]
```
Saída:
```
{
"request": "/account/login.html",
"referrer": "https://www.amazon.com/",
"agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36",
"http_method": "GET",
"status_code": 200,
"auth_user": "Foo",
"http_version": "1.1",
"response_size": 42,
"remote_host": "192.168.1.100",
"timestamp": "2023-08-03T12:34:56Z"
}
```
##### Exemplo de log do protocolo Syslog (RFC 5424)
Log de amostra:
```
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource= "Application" eventID="1011"][examplePriority@32473 class="high"]
```
Transformador:
```
[
{
"grok": {
"match": "%{SYSLOG5424}"
}
}
]
```
Saída:
```
{
"pri": 165,
"version": 1,
"timestamp": "2003-10-11T22:14:15.003Z",
"hostname": "mymachine.example.com",
"app": "evntslog",
"msg_id": "ID47",
"structured_data": "exampleSDID@32473 iut=\"3\" eventSource= \"Application\" eventID=\"1011\"",
"message": "[examplePriority@32473 class=\"high\"]"
}
```
## csv
O processador **csv** analisa valores separados por vírgulas (CSV) dos eventos de logs em colunas.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| origem | Caminho para o campo no evento de logs que será analisado | Não | `@message` | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| delimitador | O caractere usado para separar cada coluna no evento de logs original com valores separados por vírgula | Não | `,` | Comprimento máximo: 1, a menos que o valor seja `\t` ou `\s` |
| quoteCharacter | Caractere usado como qualificador de texto para uma única coluna de dados | Não | `"` | Tamanho máximo: 1 |
| colunas | Lista de nomes a serem usados para as colunas no evento de logs transformado. | Não | `[column_1, column_2 ...]` | Máximo de colunas CSV: 100 Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| destination | O campo pai em que colocar os pares de valores-chave transformados | Não | `Root node` | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
Definir `delimiter` como `\t` separará cada coluna em um caractere de tabulação e `\t` separará cada coluna em um único caractere de espaço.
**Exemplo**
Suponha que parte de um evento de logs ingerido seja semelhante a:
```
'Akua Mansa':28:'New York: USA'
```
Suponha que usemos apenas o processador **csv**:
```
[
{
"csv": {
"delimiter": ":",
"quoteCharacter": "'"
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"column_1": "Akua Mansa",
"column_2": "28",
"column_3": "New York: USA"
}
```
**Exemplo 2**
Suponha que um evento de logs ingerido seja semelhante a:
```
{
"timestamp": "2024-11-23T16:03:12Z",
"type": "user_data",
"logMsg": "'Akua Mansa':28:'New York: USA'"
}
```
Suponha que analisemos o evento como JSON, eles analisam um campo JSON com o processador **csv, especificando os nomes** e o destino das colunas:
```
[
{
"parseJSON": {}
},
{
"csv": {
"source": "logMsg",
"delimiter": ":",
"quoteCharacter": "'",
"columns":["name","age","location"],
"destination": "msg"
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"timestamp": "2024-11-23T16:03:12Z",
"logMsg": "'Akua Mansa':28:'New York: USA'",
"type": "user_data",
"msg": {
"name": "Akua Mansa",
"age": "28",
"location": "New York: USA"
}
}
```
## parseKeyValue
Use o **parseKeyValue**processador para analisar um campo especificado em pares de valores-chave. Você pode personalizar o processador para analisar as informações do campo com as seguintes opções.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| origem | Caminho para o campo no evento de logs que será analisado | Não | `@message` | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| destination | O campo de destino no qual colocar os pares de valores-chave extraídos | Não | | Tamanho máximo: 128 |
| fieldDelimiter | A string delimitadora de campo que é usada entre pares de valores-chave nos eventos de logs originais | Não | `&` | Tamanho máximo: 128 |
| keyValueDelimiter | A string delimitadora a ser usada entre a chave e o valor em cada par no evento de logs transformado | Não | `=` | Tamanho máximo: 128 |
| nonMatchValue | Um valor a ser inserido no campo de valor no resultado, quando um par de valores-chave não é dividido com sucesso. | Não | | Tamanho máximo: 128 |
| keyPrefix | Se você quiser adicionar um prefixo a todas as chaves transformadas, especifique-o aqui. | Não | | Tamanho máximo: 128 |
| overwriteIfExists | Se o valor deve ser substituído caso a chave de destino já exista | Não | `false` | |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
key1:value1!key2:value2!key3:value3!key4
```
Suponha que usemos a seguinte configuração de processador:
```
[
{
"parseKeyValue": {
"destination": "new_key",
"fieldDelimiter": "!",
"keyValueDelimiter": ":",
"nonMatchValue": "defaultValue",
"keyPrefix": "parsed_"
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"new_key": {
"parsed_key1": "value1",
"parsed_key2": "value2",
"parsed_key3": "value3",
"parsed_key4": "defaultValue"
}
}
```
# Processadores integrados para AWS registros vendidos
Esta seção contém informações sobre os processadores integrados que você pode usar com AWS serviços que vendem registros.
**Contents**
+ [
## parseWAF
](#CloudWatch-Logs-Transformation-parseWAF)
+ [
## parsePostgres
](#CloudWatch-Logs-Transformation-parsePostGres)
+ [
## parseCloudfront
](#CloudWatch-Logs-Transformation-parseCloudFront)
+ [
## parseRoute53
](#CloudWatch-Logs-Transformation-parseRoute53)
+ [
## parseVPC
](#CloudWatch-Logs-Transformation-parseVPC)
+ [
# parseToOCSF
](CloudWatch-Logs-Transformation-parseToOCSF.md)
## parseWAF
Use esse processador para analisar registros vendidos. Ele pega o conteúdo `httpRequest.headers` e cria chaves JSON a partir de cada nome de cabeçalho, com o AWS WAF valor correspondente. Também faz o mesmo para `labels`. Essas transformações podem facilitar muito a consulta aos AWS WAF registros. Para obter mais informações sobre o formato de AWS WAF log, consulte [Exemplos de log para tráfego de ACL da web](https://docs.aws.amazon.com/waf/latest/developerguide/logging-examples.html).
Esse processador aceita somente `@message` como entrada.
**Importante**
Se você usa esse processador, ele deve ser o primeiro em seu transformador.
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"timestamp": 1576280412771,
"formatVersion": 1,
"webaclId": "arn:aws:wafv2:ap-southeast-2:111122223333:regional/webacl/STMTest/1EXAMPLE-2ARN-3ARN-4ARN-123456EXAMPLE",
"terminatingRuleId": "STMTest_SQLi_XSS",
"terminatingRuleType": "REGULAR",
"action": "BLOCK",
"terminatingRuleMatchDetails": [
{
"conditionType": "SQL_INJECTION",
"sensitivityLevel": "HIGH",
"location": "HEADER",
"matchedData": ["10", "AND", "1"]
}
],
"httpSourceName": "-",
"httpSourceId": "-",
"ruleGroupList": [],
"rateBasedRuleList": [],
"nonTerminatingMatchingRules": [],
"httpRequest": {
"clientIp": "1.1.1.1",
"country": "AU",
"headers": [
{ "name": "Host", "value": "localhost:1989" },
{ "name": "User-Agent", "value": "curl/7.61.1" },
{ "name": "Accept", "value": "*/*" },
{ "name": "x-stm-test", "value": "10 AND 1=1" }
],
"uri": "/myUri",
"args": "",
"httpVersion": "HTTP/1.1",
"httpMethod": "GET",
"requestId": "rid"
},
"labels": [{ "name": "value" }]
}
```
A configuração do processador é a seguinte:
```
[
{
"parseWAF": {}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"httpRequest": {
"headers": {
"Host": "localhost:1989",
"User-Agent": "curl/7.61.1",
"Accept": "*/*",
"x-stm-test": "10 AND 1=1"
},
"clientIp": "1.1.1.1",
"country": "AU",
"uri": "/myUri",
"args": "",
"httpVersion": "HTTP/1.1",
"httpMethod": "GET",
"requestId": "rid"
},
"labels": { "name": "value" },
"timestamp": 1576280412771,
"formatVersion": 1,
"webaclId": "arn:aws:wafv2:ap-southeast-2:111122223333:regional/webacl/STMTest/1EXAMPLE-2ARN-3ARN-4ARN-123456EXAMPLE",
"terminatingRuleId": "STMTest_SQLi_XSS",
"terminatingRuleType": "REGULAR",
"action": "BLOCK",
"terminatingRuleMatchDetails": [
{
"conditionType": "SQL_INJECTION",
"sensitivityLevel": "HIGH",
"location": "HEADER",
"matchedData": ["10", "AND", "1"]
}
],
"httpSourceName": "-",
"httpSourceId": "-",
"ruleGroupList": [],
"rateBasedRuleList": [],
"nonTerminatingMatchingRules": []
}
```
## parsePostgres
Use esse processador para analisar Amazon RDS for PostgreSQL registros vendidos, extrair campos e convertê-los para o formato JSON. Para obter mais informações sobre o formato de log do RDS para PostgreSQL, consulte [ RDS para arquivos de log do banco de dados PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.PostgreSQL.html#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix).
Esse processador aceita somente `@message` como entrada.
**Importante**
Se você usa esse processador, ele deve ser o primeiro em seu transformador.
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
2019-03-10 03:54:59 UTC:10.0.0.123(52834):postgres@logtestdb:[20175]:ERROR: column "wrong_column_name" does not exist at character 8
```
A configuração do processador é a seguinte:
```
[
{
"parsePostgres": {}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"logTime": "2019-03-10 03:54:59 UTC",
"srcIp": "10.0.0.123(52834)",
"userName": "postgres",
"dbName": "logtestdb",
"processId": "20175",
"logLevel": "ERROR"
}
```
## parseCloudfront
Use esse processador para analisar Amazon CloudFront registros vendidos, extrair campos e convertê-los em formato JSON. Os valores de campo codificados são decodificados. Valores que são inteiros e de ponto flutuante são tratados como tal. Para obter mais informações sobre o formato do Amazon CloudFront registro, consulte [Configurar e usar registros padrão (registros de acesso)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html).
Esse processador aceita somente `@message` como entrada.
**Importante**
Se você usa esse processador, ele deve ser o primeiro em seu transformador.
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
2019-12-04 21:02:31 LAX1 392 192.0.2.24 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit SOX4xwn4XV6Q4rgb7XiVGOHms_BGlTAC4KyHmureZmBNrjGdRLiNIQ== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - -
```
A configuração do processador é a seguinte:
```
[
{
"parseCloudfront": {}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"date": "2019-12-04",
"time": "21:02:31",
"x-edge-location": "LAX1",
"sc-bytes": 392,
"c-ip": "192.0.2.24",
"cs-method": "GET",
"cs(Host)": "d111111abcdef8.cloudfront.net",
"cs-uri-stem": "/index.html",
"sc-status": 200,
"cs(Referer)": "-",
"cs(User-Agent)": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36",
"cs-uri-query": "-",
"cs(Cookie)": "-",
"x-edge-result-type": "Hit",
"x-edge-request-id": "SOX4xwn4XV6Q4rgb7XiVGOHms_BGlTAC4KyHmureZmBNrjGdRLiNIQ==",
"x-host-header": "d111111abcdef8.cloudfront.net",
"cs-protocol": "https",
"cs-bytes": 23,
"time-taken": 0.001,
"x-forwarded-for": "-",
"ssl-protocol": "TLSv1.2",
"ssl-cipher": "ECDHE-RSA-AES128-GCM-SHA256",
"x-edge-response-result-type": "Hit",
"cs-protocol-version": "HTTP/2.0",
"fle-status": "-",
"fle-encrypted-fields": "-",
"c-port": 11040,
"time-to-first-byte": 0.001,
"x-edge-detailed-result-type": "Hit",
"sc-content-type": "text/html",
"sc-content-len": 78,
"sc-range-start": "-",
"sc-range-end": "-"
}
```
## parseRoute53
Use esse processador para analisar Amazon Route 53 Public Data Plane registros vendidos, extrair campos e convertê-los em formato JSON. Os valores de campo codificados são decodificados. Esse processador não oferece suporte a Amazon Route 53 Resolver registros.
Esse processador aceita somente `@message` como entrada.
**Importante**
Se você usa esse processador, ele deve ser o primeiro em seu transformador.
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
1.0 2017-12-13T08:15:50.235Z Z123412341234 example.com AAAA NOERROR TCP IAD12 192.0.2.0 198.51.100.0/24
```
A configuração do processador é a seguinte:
```
[
{
"parseRoute53": {}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"version": 1.0,
"queryTimestamp": "2017-12-13T08:15:50.235Z",
"hostZoneId": "Z123412341234",
"queryName": "example.com",
"queryType": "AAAA",
"responseCode": "NOERROR",
"protocol": "TCP",
"edgeLocation": "IAD12",
"resolverIp": "192.0.2.0",
"ednsClientSubnet": "198.51.100.0/24"
}
```
## parseVPC
Use esse processador para analisar logs fornecidos pelo Amazon VPC, extrair campos e convertê-los no formato JSON. Os valores de campo codificados são decodificados.
Esse processador aceita somente `@message` como entrada.
**Importante**
Se você usa esse processador, ele deve ser o primeiro em seu transformador.
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
2 123456789010 eni-abc123de 192.0.2.0 192.0.2.24 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK
```
A configuração do processador é a seguinte:
```
[
{
"parseVPC": {}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"version": 2,
"accountId": "123456789010",
"interfaceId": "eni-abc123de",
"srcAddr": "192.0.2.0",
"dstAddr": "192.0.2.24",
"srcPort": 20641,
"dstPort": 22,
"protocol": 6,
"packets": 20,
"bytes": 4249,
"start": 1418530010,
"end": 1418530070,
"action": "ACCEPT",
"logStatus": "OK"
}
```
# parseToOCSF
O processador `parseToOCSF` converte logs em eventos do Open Cybersecurity Schema Framework (OCSF). O OCSF é um padrão aberto que fornece um esquema comum para dados de segurança, permitindo melhor interoperabilidade e análise em diferentes ferramentas e plataformas de segurança.
Esse processador é particularmente útil para fluxos de trabalho de análise de segurança em que você precisa padronizar formatos de log de vários AWS serviços em um esquema consistente para análise posterior.
**Parâmetros**
`eventSource`(obrigatório)
Especifica o AWS serviço ou processo que produz os eventos de log a serem convertidos. Os valores válidos são:
+ `CloudTrail`- CloudTrail troncos
+ `Route53Resolver` - Logs do Route 53 Resolver
+ `VPCFlow` - Logs do Amazon VPC Flow
+ `EKSAudit` - Logs de auditoria do Amazon EKS
+ `AWSWAF`- AWS WAF troncos
`ocsfVersion`(obrigatório)
Especifica qual versão do esquema OCSF usar para os eventos de logs transformados. Versões atualmente suportadas: `V1.1, V1.5`
`mappingVersion` (opcional)
Especifica a versão do mapeamento de transformação do OCSF. Controla qual lógica de transformação é aplicada ao converter registros para o formato OCSF. Se não for especificado, usa a versão mais recente disponível no momento da criação da política. As políticas existentes não são atualizadas automaticamente quando novas versões de mapeamento são lançadas. Versão mais recente atual:`v1.5.0`.
**Nota:** Não é suportado quando `ocsfVersion` é`V1.1`.
`source` (opcional)
O caminho para o campo no evento de logs que você deseja analisar. Se for omitida, toda a mensagem do log será analisada.
**Exemplo**
O seguinte exemplo mostra como usar `parseToOCSF` para converter logs do VPC Flow para o formato OCSF:
```
{
"parseToOCSF": {
"eventSource": "VPCFlow",
"ocsfVersion": "V1.1"
}
}
```
O exemplo a seguir mostra como especificar uma versão de mapeamento específica para um comportamento de transformação consistente:
```
{
"parseToOCSF": {
"eventSource": "CloudTrail",
"ocsfVersion": "V1.5",
"mappingVersion": "v1.5.0"
}
}
```
# Processadores de mutação de string
Esta seção contém informações sobre os processadores de mutação de string que você pode usar com um transformador de eventos de log.
**Contents**
+ [
## lowerCaseString
](#CloudWatch-Logs-Transformation-lowerCaseString)
+ [
## upperCaseString
](#CloudWatch-Logs-Transformation-upperCaseString)
+ [
## splitString
](#CloudWatch-Logs-Transformation-splitString)
+ [
## substituteString
](#CloudWatch-Logs-Transformation-substituteString)
+ [
## trimString
](#CloudWatch-Logs-Transformation-trimString)
## lowerCaseString
O processador `lowerCaseString` converte uma string em sua versão em minúsculas.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| withKeys | Uma lista de chaves a serem convertidas em letras minúsculas | Sim | | Máximo de entradas: 10 |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key": "INNER_VALUE"
}
}
```
A configuração do transformador é esta, usando `lowerCaseString` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"lowerCaseString": {
"withKeys":["outer_key.inner_key"]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {
"inner_key": "inner_value"
}
}
```
## upperCaseString
O processador `upperCaseString` converte uma string em sua versão em maiúsculas.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| withKeys | Uma lista de chaves a serem convertidas em maiúsculas | Sim | | Máximo de entradas: 10 |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key": "inner_value"
}
}
```
A configuração do transformador é esta, usando `upperCaseString` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"upperCaseString": {
"withKeys":["outer_key.inner_key"]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {
"inner_key": "INNER_VALUE"
}
}
```
## splitString
O processador `splitString` é um tipo de processador de mutação de string que divide um campo em uma matriz usando um caractere delimitador.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| entries | Matriz de entradas. Cada item na matriz deve conter os campos source e delimiter. | Sim | | Máximo de entradas: 10 |
| origem | A chave do valor do campo a ser dividido | Sim | | Tamanho máximo: 128 |
| delimitador | A string delimitadora onde dividir o valor do campo | Sim | | Tamanho máximo: 128 |
**Exemplo 1**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key": "inner_value"
}
}
```
A configuração do transformador é esta, usando `splitString` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"splitString": {
"entries": [
{
"source": "outer_key.inner_key",
"delimiter": "_"
}
]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {
"inner_key": [
"inner",
"value"
]
}
}
```
**Exemplo 2**
O delimitador para dividir a string pode ter vários caracteres.
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key": "item1, item2, item3"
}
}
```
A configuração do transformador é a seguinte:
```
[
{
"parseJSON": {}
},
{
"splitString": {
"entries": [
{
"source": "outer_key.inner_key",
"delimiter": ", "
}
]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {
"inner_key": [
"item1",
"item2",
"item3"
]
}
}
```
## substituteString
O processador `substituteString` é um tipo de processador de mutação de string que combina o valor de uma chave com uma expressão regular e substitui todas as correspondências por uma string de substituição.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| entries | Matriz de entradas. Cada item na matriz deve conter os campos source, from e to. | Sim | | Máximo de entradas: 10 |
| origem | A chave do campo a ser modificado | Sim | | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| from | A string de expressão regular a ser substituída. Caracteres regex especiais, como [ e ], devem ser escapados usando \$1\$1 ao usar aspas duplas e com \$1 ao usar aspas simples ou quando configurados a partir do Console de gerenciamento da AWS. Para obter mais informações, consulte o [ Padrão de classe](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/regex/Pattern.html) no site da Oracle. Você pode agrupar um padrão em `(...)` para criar um grupo de captura numerado e criar grupos de captura denominados `(?P...)` que possam ser referenciados no campo `to`. | Sim | | Tamanho máximo: 128 |
| para | A string a ser substituída para cada correspondência de from. Podem ser usadas referências anteriores para os grupos de captura. Use o formulário \$1n para grupos numerados como \$11, e use \$1\$1group\$1name\$1 para grupos nomeados, como \$1\$1my\$1group\$1.> | Sim | | Tamanho máximo: 128 Número máximo de referências anteriores: 10 Número máximo de referências anteriores duplicadas: 2 |
**Exemplo 1**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key1": "[]",
"inner_key2": "123-345-567",
"inner_key3": "A cat takes a catnap."
}
}
```
A configuração do transformador é esta, usando `substituteString` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"substituteString": {
"entries": [
{
"source": "outer_key.inner_key1",
"from": "\\[\\]",
"to": "value1"
},
{
"source": "outer_key.inner_key2",
"from": "[0-9]{3}-[0-9]{3}-[0-9]{3}",
"to": "xxx-xxx-xxx"
},
{
"source": "outer_key.inner_key3",
"from": "cat",
"to": "dog"
}
]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {
"inner_key1": "value1",
"inner_key2": "xxx-xxx-xxx",
"inner_key3": "A dog takes a dognap."
}
}
```
**Exemplo 2**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key1": "Tom, Dick, and Harry",
"inner_key2": "arn:aws:sts::123456789012:assumed-role/MyImportantRole/MySession"
}
}
```
A configuração do transformador é esta, usando `substituteString` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"substituteString": {
"entries": [
{
"source": "outer_key.inner_key1",
"from": "(\w+), (\w+), and (\w+)",
"to": "$1 and $3"
},
{
"source": "outer_key.inner_key2",
"from": "^arn:aws:sts::(?P\\d{12}):assumed-role/(?P[\\w+=,.@-]+)/(?P[\\w+=,.@-]+)$",
"to": "${account_id}:${role_name}:${role_session_name}"
}
]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {
"inner_key1": "Tom and Harry",
"inner_key2": "123456789012:MyImportantRole:MySession"
}
}
```
## trimString
O processador `trimString` remove o espaço em branco do início e do fim de uma chave.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| withKeys | Uma lista de chaves a serem tratadas | Sim | | Máximo de entradas: 10 |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key": " inner_value "
}
}
```
A configuração do transformador é esta, usando `trimString` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"trimString": {
"withKeys":["outer_key.inner_key"]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {
"inner_key": "inner_value"
}
}
```
# Processadores de mutação do JSON
Esta seção contém informações sobre os processadores de mutação JSON que você pode usar com um transformador de eventos de log.
**Contents**
+ [
## addKeys
](#CloudWatch-Logs-Transformation-addKeys)
+ [
## deleteKeys
](#CloudWatch-Logs-Transformation-deleteKeys)
+ [
## moveKeys
](#CloudWatch-Logs-Transformation-moveKeys)
+ [
## renameKeys
](#CloudWatch-Logs-Transformation-renameKeys)
+ [
## copyValue
](#CloudWatch-Logs-Transformation-copyValue)
+ [
## listToMap
](#CloudWatch-Logs-Transformation-listToMap)
## addKeys
Use o processador `addKeys` para adicionar novos pares de chave-valor ao evento de logs.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| entries | Matriz de entradas. Cada item na matriz pode conter os campos key, value e overwriteIfExists. | Sim | | Máximo de entradas: 5 |
| key | A chave da nova entrada a ser adicionada | Sim | | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| valor | O valor da nova entrada a ser adicionada | Sim | | Tamanho máximo = 256 |
| overwriteIfExists | Se você definir isso como true, o valor existente será substituído se key já existir no evento. O valor padrão é false. | Não | false | Sem limite |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key": "inner_value"
}
}
```
A configuração do transformador é esta, usando `addKeys` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"addKeys": {
"entries": [
{
"key": "outer_key.new_key",
"value": "new_value"
}
]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {
"inner_key": "inner_value",
"new_key": "new_value"
}
}
```
## deleteKeys
Use o processador `deleteKeys` para excluir campos de um evento de logs. Esses campos podem incluir pares de chave-valor.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| withKeys | Uma lista de chaves a serem excluídas. | Sim | Sem limite | Máximo de entradas: 5 |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key": "inner_value"
}
}
```
A configuração do transformador é esta, usando `deleteKeys` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"deleteKeys": {
"withKeys":["outer_key.inner_key"]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {}
}
```
## moveKeys
Use o processador `moveKeys` para mover uma chave de um campo para outro.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| entries | Matriz de entradas. Cada item na matriz pode conter os campos source, target e overwriteIfExists. | Sim | | Máximo de entradas: 5 |
| origem | A chave a ser movida | Sim | | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| target | A chave a ser movida para | Sim | | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| overwriteIfExists | Se você definir isso como true, o valor existente será substituído se key já existir no evento. O valor padrão é false. | Não | false | Sem limite |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key1": {
"inner_key1": "inner_value1"
},
"outer_key2": {
"inner_key2": "inner_value2"
}
}
```
A configuração do transformador é esta, usando `moveKeys` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"moveKeys": {
"entries": [
{
"source": "outer_key1.inner_key1",
"target": "outer_key2"
}
]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key1": {},
"outer_key2": {
"inner_key2": "inner_value2",
"inner_key1": "inner_value1"
}
}
```
## renameKeys
Use o processador `renameKeys` para renomear as chaves em um evento de logs.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| entries | Matriz de entradas. Cada item na matriz pode conter os campos key, target e overwriteIfExists. | Sim | Sem limite | Máximo de entradas: 5 |
| key | A chave a ser renomeada | Sim | Sem limite | Tamanho máximo: 128 |
| target | O novo nome da chave | Sim | Sem limite | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| overwriteIfExists | Se você definir isso como true, o valor existente será substituído se key já existir no evento. O valor padrão é false. | Não | false | Sem limite |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key": "inner_value"
}
}
```
A configuração do transformador é esta, usando `renameKeys` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"renameKeys": {
"entries": [
{
"key": "outer_key",
"target": "new_key"
}
]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"new_key": {
"inner_key": "inner_value"
}
}
```
## copyValue
Use o processador `copyValue` para copiar valores em um evento de logs. Você também pode usar esse processador para adicionar metadados aos eventos de logs, copiando os valores das seguintes chaves de metadados nos eventos de logs:`@logGroupName`, `@logGroupStream`, `@accountId`, `@regionName`. Isso é ilustrado no exemplo a seguir.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| entries | Matriz de entradas. Cada item na matriz pode conter os campos source, target e overwriteIfExists. | Sim | | Máximo de entradas: 5 |
| origem | A chave a ser copiada | Sim | | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| target | A chave cujo valor será copiado para | Sim | Sem limite | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| overwriteIfExists | Se você definir isso como true, o valor existente será substituído se key já existir no evento. O valor padrão é false. | Não | false | Sem limite |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": {
"inner_key": "inner_value"
}
}
```
A configuração do transformador é esta, usando `copyValue` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"copyValue": {
"entries": [
{
"key": "outer_key.new_key",
"target": "new_key"
},
{
"source": "@logGroupName",
"target": "log_group_name"
},
{
"source": "@logGroupStream",
"target": "log_group_stream"
},
{
"source": "@accountId",
"target": "account_id"
},
{
"source": "@regionName",
"target": "region_name"
}
]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": {
"inner_key": "inner_value"
},
"new_key": "inner_value",
"log_group_name": "myLogGroupName",
"log_group_stream": "myLogStreamName",
"account_id": "012345678912",
"region_name": "us-east-1"
}
```
## listToMap
O processador `listToMap` pega uma lista de objetos que contêm campos-chave e os converte em um mapa das chaves de destino.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| origem | A chave no ProcessingEvent com uma lista de objetos que serão convertidos em um mapa | Sim | | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| key | A chave dos campos a serem extraídos como chaves no mapa gerado | Sim | | Tamanho máximo: 128 |
| valueKey | Se isso for especificado, os valores especificados nesse parâmetro serão extraídos dos objetos source e colocados nos valores do mapa gerado. Caso contrário, os objetos originais na lista da origem serão colocados nos valores do mapa gerado. | Não | | Tamanho máximo: 128 |
| target | A chave do campo que conterá o mapa gerado | Não | Nó raiz | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| nivelamento | Um valor booleano para indicar se a lista será nivelada em itens únicos ou se os valores no mapa gerado serão listas. Por padrão, os valores das chaves correspondentes serão representados em uma matriz. Defina `flatten` como `true` para converter a matriz em um único valor com base no valor de `flattenedElement`. | Não | false | |
| flattenedElement | Se você definir flatten como true, use flattenedElement para especificar qual elemento manter, first ou last. | Obrigatório quando `flatten` estiver definido como `true` | | O valor pode ser somente first ou last |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"outer_key": [
{
"inner_key": "a",
"inner_value": "val-a"
},
{
"inner_key": "b",
"inner_value": "val-b1"
},
{
"inner_key": "b",
"inner_value": "val-b2"
},
{
"inner_key": "c",
"inner_value": "val-c"
}
]
}
```
**Transformador para caso de uso 1:** `flatten` é `false`
```
[
{
"parseJSON": {}
},
{
"listToMap": {
"source": "outer_key"
"key": "inner_key",
"valueKey": "inner_value",
"flatten": false
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": [
{
"inner_key": "a",
"inner_value": "val-a"
},
{
"inner_key": "b",
"inner_value": "val-b1"
},
{
"inner_key": "b",
"inner_value": "val-b2"
},
{
"inner_key": "c",
"inner_value": "val-c"
}
],
"a": [
"val-a"
],
"b": [
"val-b1",
"val-b2"
],
"c": [
"val-c"
]
}
```
**Transformador para o caso de uso 2:** `flatten` é `true` e `flattenedElement` é `first`
```
[
{
"parseJSON": {}
},
{
"listToMap": {
"source": "outer_key"
"key": "inner_key",
"valueKey": "inner_value",
"flatten": true,
"flattenedElement": "first"
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": [
{
"inner_key": "a",
"inner_value": "val-a"
},
{
"inner_key": "b",
"inner_value": "val-b1"
},
{
"inner_key": "b",
"inner_value": "val-b2"
},
{
"inner_key": "c",
"inner_value": "val-c"
}
],
"a": "val-a",
"b": "val-b1",
"c": "val-c"
}
```
**Transformador para o caso de uso 3:** `flatten` é `true` e `flattenedElement` é `last`
```
[
{
"parseJSON": {}
},
{
"listToMap": {
"source": "outer_key"
"key": "inner_key",
"valueKey": "inner_value",
"flatten": true,
"flattenedElement": "last"
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"outer_key": [
{
"inner_key": "a",
"inner_value": "val-a"
},
{
"inner_key": "b",
"inner_value": "val-b1"
},
{
"inner_key": "b",
"inner_value": "val-b2"
},
{
"inner_key": "c",
"inner_value": "val-c"
}
],
"a": "val-a",
"b": "val-b2",
"c": "val-c"
}
```
# Processadores de conversão de tipos de dados
Esta seção contém informações sobre os processadores conversores de tipos de dados que você pode usar com um transformador de eventos de log.
**Contents**
+ [
## typeConverter
](#CloudWatch-Logs-Transformation-typeConverter)
+ [
## datetimeConverter
](#CloudWatch-Logs-Transformation-datetimeConverter)
## typeConverter
Use o processador `typeConverter` para converter um tipo de valor associado à chave especificada para o tipo especificado. É um processador de conversão que altera os tipos dos campos especificados. Os valores podem ser convertidos em um dos seguintes tipos de dados: `integer`, `double`, `string` e `boolean`.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| entries | Matriz de entradas. Cada item na matriz deve conter os campos key e type. | Sim | | Máximo de entradas: 10 |
| key | A chave com o valor que deve ser convertido em um tipo diferente | Sim | | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| type | O tipo para o qual converter. Os valores válidos são integer, double, string e boolean. | Sim | | |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{
"name": "value",
"status": "200"
}
```
A configuração do transformador é esta, usando `typeConverter` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"typeConverter": {
"entries": [
{
"key": "status",
"type": "integer"
}
]
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"name": "value",
"status": 200
}
```
## datetimeConverter
Use o processador `datetimeConverter` para converter uma string de data e hora em um formato que você especificar.
| Campo | Description | Obrigatório? | Padrão | Limites |
| --- | --- | --- | --- | --- |
| origem | A chave na qual aplicar a conversão de data. | Sim | | Máximo de entradas: 10 |
| matchPatterns | Uma lista de padrões para combinar com o campo source | Sim | | Máximo de entradas: 5 |
| target | O campo JSON no qual armazenar o resultado. | Sim | | Tamanho máximo: 128 Profundidade máxima de chave aninhada: 3 |
| targetFormat | O formato de data e hora a ser usado para os dados convertidos no campo de destino. | Não | ` yyyy-MM-dd'T'HH:mm:ss.SSS'Z` | Tamanho máximo: 64 |
| sourceTimezone | O fuso horário do campo de origem. Para obter uma lista de valores possíveis, consulte [ Ids e deslocamentos de zona aceitos pelo Java](https://howtodoinjava.com/java/date-time/supported-zone-ids-offsets/#3-java-supported-zone-ids-and-offsets). | Não | UTC | Tamanho mínimo: 1 |
| targetTimezone | O fuso horário do campo de destino. Para obter uma lista de valores possíveis, consulte [ Ids e deslocamentos de zona aceitos pelo Java](https://howtodoinjava.com/java/date-time/supported-zone-ids-offsets/#3-java-supported-zone-ids-and-offsets). | Não | UTC | Tamanho mínimo: 1 |
| locale | O locale do campo de origem. Para obter uma lista de valores possíveis, consulte o [Método Locale getAvailableLocales () em Java com exemplos](https://www.geeksforgeeks.org/locale-getavailablelocales-method-in-java-with-examples/). | Sim | | Tamanho mínimo: 1 |
**Exemplo**
Observe o seguinte exemplo de evento de logs:
```
{"german_datetime": "Samstag 05. Dezember 1998 11:00:00"}
```
A configuração do transformador é esta, usando `dateTimeConverter` com `parseJSON`:
```
[
{
"parseJSON": {}
},
{
"dateTimeConverter": {
"source": "german_datetime",
"target": "target_1",
"locale": "de",
"matchPatterns": ["EEEE dd. MMMM yyyy HH:mm:ss"],
"sourceTimezone": "Europe/Berlin",
"targetTimezone": "America/New_York",
"targetFormat": "yyyy-MM-dd'T'HH:mm:ss z"
}
}
]
```
O evento de logs transformado seria o seguinte.
```
{
"german_datetime": "Samstag 05. Dezember 1998 11:00:00",
"target_1": "1998-12-05T17:00:00 MEZ"
}
```
# Métricas e erros de transformação
CloudWatch O Logs publica métricas de transformação em CloudWatch. Essas métricas são `TransformedLogEvents`, `TransformedBytes` e `TransformationErrors`. Para obter mais informações, consulte [Métricas e dimensões do transformador de log](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md#CloudWatchLogs-Transformer-Metrics).
Sempre que o CloudWatch Logs tenta e não consegue transformar um evento de registro, ele adiciona um campo `@transformationError` do sistema a esse evento de registro. Ao executar uma consulta do CloudWatch Logs Insights, você verá esse campo em todos os eventos de log que tiveram uma falha na transformação. Você pode consultar esse campo com uma consulta como `filter ispresent(@transformationError)` para encontrar todos os eventos de transformação com falha.