Analizando datos log

Un registro log podría verse así:

{
  "message": "54.3.120.2 2048 0"
}

Esta información es precisa, pero no es exactamente intuitivo lo que significa. Los patrones de Grok lo ayudan a extraer y comprender los telemetry data que desea. Por ejemplo, un log como este es mucho más fácil de usar:

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

Para hacer esto, cree un patrón Grok que extraiga estos tres campos; Por ejemplo:

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

Después del procesamiento, su log incluirá los campos host_ip, bytes_received y bytes_sent. Ahora puede utilizar estos campos en New Relic para filtrar, facetar y realizar operaciones estadísticas en sus datos log . Para obtener más detalles sobre cómo analizar registros con patrones de Grok en New Relic, consulte nuestra publicación de blog.

Si tiene los permisos correctos, puede crear reglas de análisis en nuestra UI para crear, probar y habilitar el análisis de Grok. Por ejemplo, para obtener un tipo específico de mensaje de error para uno de sus microservicios llamado Servicios de inventario, crearía una regla de análisis de Grok que busque un mensaje de error y un producto específicos. Para hacer esto:

1. Dale un nombre a la regla; por ejemplo, Inventory Services error parsing.

2. Seleccione un campo existente para analizar (predeterminado = message) o ingrese un nuevo nombre de campo.

3. Identifique la cláusula NRQL WHERE que actúa como filtro previo para el registro entrante; por ejemplo, entity.name='Inventory Service'. Este prefiltro reduce la cantidad de registros que su regla debe procesar, eliminando el procesamiento innecesario.

4. Seleccione un log coincidente, si existe, o haga clic en la pestaña Pegar log para pegar un log de muestra.

5. Agregue la regla de análisis de Grok; Por ejemplo:

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

   Copia

   Dónde:

• Inventory error: el nombre de su regla de análisis
• error_message: El mensaje de error que desea seleccionar
• product_id: El ID del producto para el servicio de inventario.

6. Habilite y guarde la regla de análisis.

   Pronto verá que su registro del Servicio de inventario se enriquece con dos campos nuevos: error_message y product_id. Desde aquí, puedes consultar estos campos, crear gráficos y paneles, establecer alertas, etc.

   Para obtener detalles completos, consulte nuestros documentos para agregar reglas de análisis personalizadas en la UI.

El campo OPTIONAL_TYPE especifica el tipo de valor de atributo que se extraerá. Si se omite, los valores se extraen como cadenas.

Los tipos admitidos son:

Si tiene un registro de varias líneas, tenga en cuenta que el patrón GREEDYDATA Grok no coincide con las nuevas líneas (es equivalente a .*).

Entonces, en lugar de usar %{GREEDYDATA:some_attribute} directamente, necesitarás agregar la bandera multilínea delante: (?s)%{GREEDYDATA:some_attribute}

El pipeline New Relic Logs analiza los mensajes JSON de log de forma predeterminada, pero a veces tiene mensajes de registro JSON que se mezclan con texto sin formato. En esta situación, es posible que desee poder analizarlos y luego filtrarlos utilizando el atributo JSON. Si ese es el caso, puede utilizar el tipo grok json , que analizará el JSON capturado por el patrón grok. Este formato se basa en 3 partes principales: la sintaxis grok, el prefejo que le gustaría asignar al atributo json analizado y el tipo json grok. Usando el tipo grok json , puede extraer y analizar JSON de registros que no están formateados correctamente; por ejemplo, si su registro tiene como prefijo una cadena de fecha/hora:

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

Para extraer y analizar los datos JSON de este formato log , cree la siguiente expresión de Grok:

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

El log resultante es:

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"

Puede definir la lista de atributos a extraer o soltar con las opciones keepAttributes o dropAttributes. Por ejemplo, con la siguiente expresión de Grok:

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

El log resultante es:

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

Si desea omitir el prefijo my_attribute_prefix , puede incluir el "noPrefix": true en la configuración.

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

Si desea omitir el prefijo my_attribute_prefix y conservar solo el atributo status , puede incluir "noPrefix": true y "keepAttributes: ["status"] en la configuración.

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

Si se escapó su JSON, puede usar la opción isEscaped para poder analizarlo. Si su JSON se escapó y luego se citó, también debe hacer coincidir las comillas, como se muestra a continuación. Por ejemplo, con la siguiente expresión de Grok:

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

Podría analizar el mensaje escapado:

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

El log resultante es:

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 el tipo json Grok, emplee :json(_CONFIG_):

• json({"dropOriginal": true}): elimine el fragmento JSON que se utilizó en el análisis. Cuando se establece en true (valor predeterminado), la regla de análisis eliminará el fragmento JSON original. Tenga en cuenta que el atributo JSON permanecerá en el campo del mensaje.
• json({"dropOriginal": false}): Esto mostrará la carga útil JSON que se extrajo. Cuando se establece en false, la carga útil completa solo JSON se mostrará bajo un atributo denominado en my_attribute_prefix arriba. Tenga en cuenta que el atributo JSON permanecerá aquí en el campo de mensaje y también brindará al usuario 3 vistas diferentes de los datos JSON. Si le preocupa el almacenamiento de las tres versiones, se recomienda utilizar el valor predeterminado true aquí.
• json({"depth": 62}): Niveles de profundidad que desea analizar el valor JSON (predeterminado en 62).
• json({"keepAttributes": ["attr1", "attr2", ..., "attrN"]}): Especifica qué atributo se extraerá del JSON. La lista proporcionada no puede estar vacía. Si esta opción de configuración no está configurada, se extraen todos los atributos.
• json({"dropAttributes": ["attr1", "attr2", ..., "attrN"]}): Especifica qué atributo se eliminará del JSON. Si esta opción de configuración no está configurada, no se elimina ningún atributo.
• json({"noPrefix": true}): establezca esta opción en true para eliminar el prefijo del atributo extraído del JSON.
• json({"isEscaped": true}): Establezca esta opción en true para analizar JSON que se escapó (lo que normalmente se ve cuando JSON está encadenado, por ejemplo, {\"key\": \"value\"}).

Si su sistema envía un registro de valores separados por comas (CSV) y necesita analizarlos en New Relic, puede usar el tipo csv Grok, que analiza el CSV capturado por el patrón Grok. Este formato se basa en 3 partes principales: la sintaxis de Grok, el prefijo que le gustaría asignar al atributo CSV analizado y el tipo csv de Grok. Usando el tipo csv Grok, puede extraer y analizar CSV del registro.

Dada la siguiente línea log CSV como ejemplo:

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

Y una regla de análisis con la siguiente forma:

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

Analizará su log de la siguiente manera:

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

Si necesita omitir el prefijo "log", puede incluir el "noPrefix": true en la configuración.

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

Configuración de columnas:

• Es obligatorio indicar las columnas en la configuración del tipo CSV Grok (que debe ser un JSON válido).
• Puede ignorar cualquier columna estableciendo "_" (guión bajo) como nombre de la columna para eliminarla del objeto resultante.

Opciones de configuración opcionales:

Si bien la configuración de "columnas" es obligatoria, es posible cambiar el análisis del CSV con las siguientes configuraciones.

• dropOriginal: (El valor predeterminado es true) Suelte el fragmento CSV utilizado en el análisis. Cuando se establece en true (valor predeterminado), la regla de análisis descarta el campo original.
• noPrefix: (El valor predeterminado es false) No incluye el nombre del campo Grok como prefijo en el objeto resultante.
• separator: (Predeterminado en ,) Define el carácter/cadena que divide cada columna.
  • Otro escenario común son los valores separados por tabulaciones (TSV), para eso debes indicar \t como separador, ej. %{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"], "separator": "\t"})
• quoteChar: (Predeterminado en ") Define el carácter que opcionalmente rodea el contenido de una columna.

Si su sistema envía registros que contienen direcciones IPv4, New Relic puede ubicarlas geográficamente y enriquecer el registro de eventos con el atributo especificado. Puede utilizar el tipo geo Grok, que encuentra la posición de una dirección IP capturada por el patrón Grok. Este formato se puede configurar para devolver uno o más campos relacionados con la dirección, como la ciudad, el país y la latitud/longitud de la IP.

Dada la siguiente línea log como ejemplo:

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

Y una regla de análisis con la siguiente forma:

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

Analizaremos su log de la siguiente manera:

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

Configuración de búsqueda:

Es obligatorio especificar los campos lookup deseados devueltos por la acción geo . Se requiere al menos un elemento de las siguientes opciones.

• city: Nombre de la ciudad
• countryCode: Abreviatura de país
• countryName: Nombre del país
• latitude: Latitud
• longitude: Longitud
• postalCode: Código postal, código postal o similar
• region: Abreviatura de estado, provincia o territorio
• regionName: Nombre del estado, provincia o territorio

Agregue logtype como attribute. Debe configurar el tipo de registro para cada fuente nombrada.

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

Agregue un bloque de filtro al archivo .conf , que utiliza un record_transformer para agregar un nuevo campo. En este ejemplo utilizamos un logtype de nginx para activar la regla de análisis NGINX incorporada. Mira otros ejemplos de 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>

Agregue un bloque de filtro al archivo .conf que use un record_modifier para agregar un nuevo campo. En este ejemplo utilizamos un logtype de nginx para activar la regla de análisis NGINX incorporada. Consulte otros ejemplos de Fluent Bit.

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

Agregue un bloque de filtro a la configuración de Logstash que utiliza un filtro de mutación add_field para agregar un nuevo campo. En este ejemplo utilizamos un logtype de nginx para activar la regla de análisis NGINX incorporada. Consulte otros ejemplos de Logstash.

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

Puede agregar atributo a la solicitud JSON enviada a New Relic. En este ejemplo, agregamos un atributo logtype de valor nginx para activar la regla de análisis NGINX incorporada. Obtenga más información sobre el uso de la API de registros.

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"
}