El procesador de deduplicación elimina copias de datos para reducir el volumen y el ruido. Almacena en caché 5000 mensajes a la vez y compara el tráfico entrante de logs con los mensajes almacenados en caché. Por ejemplo, este procesador puede utilizarse para conservar sólo logs de advertencia únicos en el caso de que se envíen varios logs de advertencia idénticos seguidos.

Para configurar el procesador de deduplicación:

1. Define una consulta de filtro. Sólo se procesan los logs que coinciden con la [consulta de filtro] especificada (#filter-query-syntax). Todos los logs deduplicados y los logs que no coinciden con la consulta de filtro se envían al siguiente paso del pipeline.
2. En el menú desplegable Type of deduplication (Tipo de deduplicación), selecciona si deseas Match en o Ignore los campos especificados a continuación.
   • Si se selecciona Match, después de que pase un log, se eliminarán los futuros logs que tengan los mismos valores para todos los campos que especifiques a continuación.
   • Si se selecciona Ignore, después de que pase un log, se eliminarán los futuros logs que tengan los mismos valores para todos los campos, excepto los que especifiques a continuación.
3. Introduce los campos con los que deseas establecer una correspondencia o ignorarlos. Se requiere al menos un campo, y puedes especificar un máximo de tres campos.
   • Utiliza la notación de ruta <OUTER_FIELD>.<INNER_FIELD> para hacer coincidir subcampos. Consulta el Ejemplo de notación de ruta más abajo.
4. Haz clic en Add field (Añadir campo) para añadir los campos adicionales que desees filtrar.

Ejemplo de notación de ruta

Para la siguiente estructura de mensajes, utiliza outer_key.inner_key.double_inner_key para referirse a la clave con el valor double_inner_value.

{
    "outer_key": {
        "inner_key": "inner_value",
            "a": {
                    "double_inner_key": "double_inner_value",
                    "b": "b value"
                },
            "c": "c value"
        },
        "d": "d value"
    }

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.