Este procesador analiza logs mediante las reglas de parseo grok disponibles para un conjunto de orígenes. Las reglas se aplican automáticamente a logs basándose en el origen del log. Por lo tanto, los logs deben tener un campo source con el nombre del origen. Si este campo no se añade cuando el log se envía al worker de pipelines de observabilidad, puedes utilizar el procesador Add field (Añadir campo) para añadirlo.

Si el campo source de un log coincide con uno de los conjuntos de reglas de parseo grok, el campo message del log se comprueba con esas reglas. Si una regla coincide, los datos analizados resultantes se añaden al campo message como un objeto JSON, sobrescribiendo el message original.

Si no hay un campo source en el log, o ninguna regla coincide con el log message, entonces no se realizan cambios en el log y se envía al siguiente paso del pipeline.

Para configurar el analizador sintáctico grok, define un filtro de consulta. Sólo se procesan los logs que coincidan con la [consulta de filtro] especificada (#filter-query-syntax). Todos los logs, independientemente de si coinciden o no con la consulta de filtro, se envían al siguiente paso del pipeline.

Para probar muestras de log para las reglas predefinidas:

1. Haz clic en el botón Preview Library Rules (Previsualizar reglas de biblioteca).
2. Busca o selecciona un origen en el menú desplegable.
3. Introduce una muestra de log para probar las reglas de parseo para ese origen.

Para añadir una regla personalizada de parseo:

1. Haz clic en Add Custom Rule (Añadir regla personalizada).
2. Si deseas clonar una regla de biblioteca, selecciona Clone library rule (Clonar regla de biblioteca) y, a continuación, el origen de biblioteca en el menú desplegable.
3. Si deseas crear una regla personalizada, selecciona Custom (Personalizada) y, a continuación, introduce el source. Las reglas de parseo se aplican a logs con ese source.
4. Introduce muestras de log para probar las reglas de parseo.
5. Introduce las reglas para el parseo de los logs. Consulta Parseo para obtener más información sobre la escritura de reglas de parseo.
   Nota: Los filtros url, useragent y csv no están disponibles.
6. Haz clic en Advanced Settings (Configuración avanzada) si deseas añadir reglas auxiliares. Consulta Uso de reglas auxiliares para factorizar varias reglas de parseo para obtener más información.
7. Haz clic en Add Rule (Añadir regla).

Filter query syntax

Each processor has a corresponding filter query in their fields. Processors only process logs that match their filter query. And for all processors except the filter processor, logs that do not match the query are sent to the next step of the pipeline. For the filter processor, logs that do not match the query are dropped.

For any attribute, tag, or key:value pair that is not a reserved attribute, your query must start with @. Conversely, to filter reserved attributes, you do not need to append @ in front of your filter query.

For example, to filter out and drop status:info logs, your filter can be set as NOT (status:info). To filter out and drop system-status:info, your filter must be set as NOT (@system-status:info).

Filter query examples:

• NOT (status:debug): This filters for only logs that do not have the status DEBUG.
• status:ok service:flask-web-app: This filters for all logs with the status OK from your flask-web-app service.
  • This query can also be written as: status:ok AND service:flask-web-app.
• host:COMP-A9JNGYK OR host:COMP-J58KAS: This filter query only matches logs from the labeled hosts.
• @user.status:inactive: This filters for logs with the status inactive nested under the user attribute.

Queries run in the Observability Pipelines Worker are case sensitive. Learn more about writing filter queries in Datadog’s Log Search Syntax.