Analisando dados log

Um registro de log poderia ser algo assim:

{
  "message": "54.3.120.2 2048 0"
}

Esta informação é precisa, mas não é exatamente intuitiva o que significa. Os padrões Grok ajudam você a extrair e compreender os dados de telemetria desejados. Por exemplo, um registro de log como este é muito mais fácil de usar:

{
  "host_ip": "43.3.120.2",
  "bytes_received": 2048,
  "bytes_sent": 0
}

Para fazer isso, crie um padrão Grok que extraia esses três campos; por exemplo:

%{IP:host_ip} %{INT:bytes_received} %{INT:bytes_sent}

Após o processamento, seu registro de log incluirá os campos host_ip, bytes_received e bytes_sent. Agora você pode usar esses campos no New Relic para filtrar, facetar e realizar operações estatísticas em seus dados de log. Para obter mais detalhes sobre como analisar logs com padrões Grok no New Relic, consulte nossa postagem no blog.

Se você tiver as permissões corretas, poderá criar regras de análise em nossa interface para criar, testar e ativar a análise Grok. Por exemplo, para obter um tipo específico de mensagem de erro para um de seus microsserviços chamado Inventory Services, você criaria uma regra de análise Grok que procura uma mensagem de erro e um produto específicos. Para fazer isso:

1. Dê um nome à regra; por exemplo, Inventory Services error parsing.

2. Selecione um campo existente para analisar (padrão = message) ou insira um novo nome de campo.

3. Identifique a cláusula NRQL WHERE que atua como pré-filtro para o log de entrada; por exemplo, entity.name='Inventory Service'. Esse pré-filtro restringe o número de logs que precisam ser processados pela sua regra, removendo processamento desnecessário.

4. Selecione um log correspondente, se existir, ou clique na guia Colar log para colar um log de amostra.

5. Adicione a regra de análise Grok; por exemplo:

   Inventory error: %{DATA:error_message} for product %{INT:product_id}

   Copiar

   Onde:

• Inventory error: o nome da sua regra de análise
• error_message: A mensagem de erro que você deseja selecionar
• product_id: o ID do produto para o serviço de inventário

6. Ative e salve a regra de análise.

   Em breve você verá que seu log do Inventory Service foi enriquecido com dois novos campos: error_message e product_id. A partir daqui você pode consultar esses campos, criar gráficos e dashboards, definir alertas, etc.

   Para obter detalhes completos, consulte nossos documentos para adicionar regras de análise personalizadas na interface.

O campo OPTIONAL_TYPE especifica o tipo de valor de atributo a ser extraído. Se omitido, os valores serão extraídos como strings.

Os tipos suportados são:

Se você tiver log multilinha, esteja ciente de que o padrão GREEDYDATA Grok não corresponde a novas linhas (é equivalente a .*).

Portanto, em vez de usar %{GREEDYDATA:some_attribute} diretamente, você precisará adicionar o sinalizador multilinha na frente dele: (?s)%{GREEDYDATA:some_attribute}

O pipeline do New Relic Logs analisa suas mensagens JSON de log por padrão, mas às vezes você tem mensagens JSON do log misturadas com texto simples. Nessa situação, você pode querer analisá-los e depois filtrar usando o atributo JSON. Se for esse o caso, você pode usar o tipo json grok , que analisará o JSON capturado pelo padrão grok. Este formato depende de 3 partes principais: a sintaxe grok, o prefixo que você gostaria de atribuir ao atributo json analisado e o json tipo grok. Usando o tipo json grok, você pode extrair e analisar JSON do log que não está formatado corretamente; por exemplo, se o seu log tiver como prefixo uma string de data/hora:

2015-05-13T23:39:43.945958Z {"event": "TestRequest", "status": 200, "response": {"headers": {"X-Custom": "foo"}}, "request": {"headers": {"X-Custom": "bar"}}}

Para extrair e analisar os dados JSON deste formato de log, crie a seguinte expressão Grok:

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json}

O log resultante é:

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.status: 200
my_attribute_prefix.response.headers.X-Custom: "foo"
my_attribute_prefix.request.headers.X-Custom: "bar"

Você pode definir a lista de atributos a serem extraídos ou descartados com as opções keepAttributes ou dropAttributes. Por exemplo, com a seguinte expressão Grok:

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"keepAttributes": ["my_attribute_prefix.event", "my_attribute_prefix.response.headers.X-Custom"]})}

O log resultante é:

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.request.headers.X-Custom: "bar"

Se quiser omitir o prefixo my_attribute_prefix , você poderá incluir "noPrefix": true na configuração.

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"noPrefix": true})}

Se desejar omitir o prefixo my_attribute_prefix e manter apenas o atributo status , você poderá incluir "noPrefix": true e "keepAttributes: ["status"] na configuração.

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"noPrefix": true, "keepAttributes": ["status"]})}

Se seu JSON tiver escapado, você poderá usar a opção isEscaped para poder analisá-lo. Se o seu JSON tiver sido escapado e depois citado, você também precisará combinar as aspas, conforme mostrado abaixo. Por exemplo, com a seguinte expressão Grok:

%{TIMESTAMP_ISO8601:containerTimestamp} "%{GREEDYDATA:my_attribute_prefix:json({"isEscaped": true})}"

Seria capaz de analisar a mensagem escapada:

2015-05-13T23:39:43.945958Z "{\"event\": \"TestRequest\", \"status\": 200, \"response\": {\"headers\": {\"X-Custom\": \"foo\"}}, \"request\": {\"headers\": {\"X-Custom\": \"bar\"}}}"

O log resultante é:

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.status: 200
my_attribute_prefix.response.headers.X-Custom: "foo"
my_attribute_prefix.request.headers.X-Custom: "bar"

Para configurar o tipo json Grok, use :json(_CONFIG_):

• json({"dropOriginal": true}): elimine o trecho JSON que foi usado na análise. Quando definido como true (valor padrão), a regra de análise eliminará o trecho JSON original. Observe que o atributo JSON permanecerá no campo da mensagem.
• json({"dropOriginal": false}): isso mostrará a carga JSON que foi extraída. Quando definido como false, a carga completa somente JSON será exibida em um atributo nomeado em my_attribute_prefix acima. Observe que o atributo JSON permanecerá no campo de mensagem aqui, dando ao usuário 3 visualizações diferentes dos dados JSON. Se o armazenamento de todas as três versões for uma preocupação, é recomendado usar o padrão true aqui.
• json({"depth": 62}): níveis de profundidade que você deseja analisar o valor JSON (padrão 62).
• json({"keepAttributes": ["attr1", "attr2", ..., "attrN"]}): Especifica qual atributo será extraído do JSON. A lista fornecida não pode estar vazia. Se esta opção de configuração não estiver definida, todos os atributos serão extraídos.
• json({"dropAttributes": ["attr1", "attr2", ..., "attrN"]}): Especifica qual atributo será retirado do JSON. Se esta opção de configuração não for definida, nenhum atributo será eliminado.
• json({"noPrefix": true}): Defina esta opção como true para remover o prefixo do atributo extraído do JSON.
• json({"isEscaped": true}): Defina esta opção como true para analisar o JSON que foi escapado (que normalmente você vê quando o JSON é stringificado, por exemplo {\"key\": \"value\"})

Se o seu sistema envia log de valores separados por vírgula (CSV) e você precisa analisá-los no New Relic, você pode usar o tipo csv Grok, que analisa o CSV capturado pelo padrão Grok. Este formato depende de 3 partes principais: a sintaxe Grok, o prefixo que você gostaria de atribuir ao atributo CSV analisado e o csv tipo Grok. Usando o tipo csv Grok, você pode extrair e analisar CSV do log.

Dada a seguinte linha de log CSV como exemplo:

"2015-05-13T23:39:43.945958Z,202,POST,/shopcart/checkout,142,10"

E uma regra de análise com o seguinte formato:

%{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"]})}

Irá analisar seu log da seguinte maneira:

log.timestamp: "2015-05-13T23:39:43.945958Z"
log.status: "202"
log.method: "POST"
log.url: "/shopcart/checkout"
log.time: "142"
log.bytes: "10"

Se precisar omitir o prefixo "log", você poderá incluir "noPrefix": true na configuração.

%{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"], "noPrefix": true})}

Configuração de colunas:

• É obrigatório indicar as colunas na configuração do tipo CSV Grok (que deve ser um JSON válido).
• Você pode ignorar qualquer coluna definindo "_" (sublinhado) como o nome da coluna para removê-la do objeto resultante.

Opções de configuração opcionais:

Embora a configuração de “colunas” seja obrigatória, é possível alterar a análise do CSV com as seguintes configurações.

• dropOriginal: (o padrão é true) Elimine o trecho CSV usado na análise. Quando definida como true (valor padrão), a regra de análise descarta o campo original.
• noPrefix: (o padrão é false) Não inclui o nome do campo Grok como prefixo no objeto resultante.
• separator: (O padrão é ,) Define o caractere/string que divide cada coluna.
  • Outro cenário comum são os valores separados por tabulações (TSV), para isso você deve indicar \t como separador, ex. %{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"], "separator": "\t"})
• quoteChar: (O padrão é ") Define o caractere que opcionalmente envolve o conteúdo de uma coluna.

Se o seu sistema enviar log contendo endereços IPv4, New Relic poderá localizá-los geograficamente e enriquecer o evento de log com o atributo especificado. Você pode usar o tipo geo Grok, que encontra a posição de um endereço IP capturado pelo padrão Grok. Este formato pode ser configurado para retornar um ou mais campos relacionados ao endereço, como cidade, país e latitude/longitude do IP.

Dada a seguinte linha de log como exemplo:

2015-05-13T23:39:43.945958Z 146.190.212.184

E uma regra de análise com o seguinte formato:

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:ip:geo({"lookup":["city","region","countryCode", "latitude","longitude"]})}

Analisaremos seu log da seguinte maneira:

ip: 146.190.212.184
ip.city: North Bergen
ip.countryCode: US
ip.countryName: United States
ip.latitude: 40.793
ip.longitude: -74.0247
ip.postalCode: 07047
ip.region: NJ
ip.regionName: New Jersey
containerTimestamp:2015-05-13T23:39:43.945958Z
ISO8601_TIMEZONE:Z

Configuração de pesquisa:

É obrigatório especificar os campos lookup desejados retornados pela ação geo . É necessário pelo menos um item das opções a seguir.

• city: Nome da cidade
• countryCode: Abreviatura do país
• countryName: Nome de país
• latitude: Latitude
• longitude: Longitude
• postalCode: Código postal, CEP ou similar
• region: Abreviatura de estado, província ou território
• regionName: Nome do estado, província ou território

Adicione logtype como um attribute. Você deve configurar o tipo de log para cada origem nomeada.

logs:
  - name: file-simple
    file: /path/to/file
    attributes:
      logtype: fileRaw
  - name: nginx-example
    file: /var/log/nginx.log
    attributes:
      logtype: nginx

Adicione um bloco de filtro ao arquivo .conf , que usa um record_transformer para adicionar um novo campo. Neste exemplo, usamos um logtype de nginx para acionar a regra de análise NGINX integrada. Confira outros exemplos do Fluentd.

<filter containers>
  @type record_transformer
  enable_ruby true
  <record>
    #Add logtype to trigger a built-in parsing rule for nginx access logs
    logtype nginx
    #Set timestamp from the value contained in the field "time"
    timestamp record["time"]
    #Add hostname and tag fields to all records
    hostname "#{Socket.gethostname}"
    tag ${tag}
  </record>
</filter>

Adicione um bloco de filtro ao arquivo .conf que usa um record_modifier para adicionar um novo campo. Neste exemplo, usamos um logtype de nginx para acionar a regra de análise NGINX integrada. Confira outros exemplos do Fluent Bit.

[FILTER]
    Name   record_modifier
    Match  *
    Record logtype nginx
    Record hostname ${HOSTNAME}
    Record service_name Sample-App-Name

Adicione um bloco de filtro à configuração do Logstash que usa um filtro de mutação add_field para adicionar um novo campo. Neste exemplo, usamos um logtype de nginx para acionar a regra de análise NGINX integrada. Confira outros exemplos do Logstash.

filter {
  mutate {
    add_field => {
      "logtype" => "nginx"
      "service_name" => "myservicename"
      "hostname" => "%{host}"
    }
  }
}

Você pode adicionar um atributo à solicitação JSON enviada para New Relic. Neste exemplo, adicionamos um atributo logtype de valor nginx para acionar a regra de análise NGINX integrada. Saiba mais sobre como usar a API Logs.

POST /log/v1 HTTP/1.1
Host: log-api.newrelic.com
Content-Type: application/json
X-License-Key: YOUR_LICENSE_KEY
Accept: */*
Content-Length: 133
{
  "timestamp": TIMESTAMP_IN_UNIX_EPOCH,
  "message": "User 'xyz' logged in",
  "logtype": "nginx",
  "service": "login-service",
  "hostname": "login.example.com"
}