Utiliza este procesador para añadir un nombre de campo y el valor de una variable de entorno al mensaje de log.

Para configurar este procesador:

1. Define una consulta de filtro. Sólo se procesan los logs que coinciden con la consulta de filtro especificada. Todos los logs, independientemente de si coinciden con la consulta de filtro, se envían al siguiente paso del pipeline.
2. Introduce el nombre del campo para la variable de entorno.
3. Introduce el nombre de la variable de entorno.
4. Haz clic en Add Environment Variable (Añadir variable de entorno) si deseas añadir otra variable de entorno.

Variables de entorno bloqueadas

Las variables de entorno que coincidan con alguno de los siguientes patrones no podrán añadirse a los mensajes de log porque la variable de entorno podría contener datos confidenciales.

• CONNECTIONSTRING / CONNECTION-STRING / CONNECTION_STRING
• AUTH
• CERT
• CLIENTID / CLIENT-ID / CLIENT_ID
• CREDENTIALS
• DATABASEURL / DATABASE-URL / DATABASE_URL
• DBURL / DB-URL / DB_URL
• KEY
• OAUTH
• PASSWORD
• PWD
• ROOT
• SECRET
• TOKEN
• USER

La variable de entorno coincide con el patrón y no con la palabra literal. Por ejemplo, PASSWORD bloquea las variables de entorno como USER_PASSWORD y PASSWORD_SECRET para que no se añadan a los mensajes de log.

Sintaxis de las consultas de filtro

Cada procesador tiene una consulta de filtro correspondiente en sus campos. Los procesadores sólo procesan los logs que coinciden con su consulta de filtro. Y en todos los procesadores, excepto el procesador de filtro, los logs que no coinciden con la consulta se envían al siguiente paso de la cadena. Para el procesador de filtro, los logs que no coinciden con la consulta se descartan.

Para cualquier atributo, etiqueta (tag) o par key:value que no sea un atributo reservado, la consulta debe empezar por @. Por el contrario, para filtrar atributos reservados, no es necesario añadir @ delante de la consulta de filtro.

Por ejemplo, para filtrar y descartar logs status:info, tu filtro puede definirse como NOT (status:info). Para filtrar y descartar system-status:info, el filtro debe ser NOT (@system-status:info).

Ejemplos de consulta de filtro:

• NOT (status:debug): Esto filtra sólo los logs que no tienen el estado DEBUG.
• status:ok service:flask-web-app: Esto filtra todos los logs con el estado OK de tu servicioflask-web-app.
  • Esta consulta también se puede escribir como: status:ok AND service:flask-web-app.
• host:COMP-A9JNGYK OR host:COMP-J58KAS: Esta consulta de filtro sólo coincide con los logs de hosts etiquetados.
• @user.status:inactive: Esto filtra los logs con el estado inactive anidado bajo el atributo user.

Las consultas ejecutadas en el worker de Observability Pipelines distinguen entre mayúsculas y minúsculas. Obtén más información sobre cómo escribir consultas de filtro con la sintaxis de búsqueda de logs de Datadog.