Información general

Utiliza el worker de pipelines de observabilidad para enviar tus logs procesados a diferentes destinos.

Selecciona y configura tus destinos cuando configures un pipeline. Este es el paso 4 del proceso de configuración de pipelines:

  1. Ve a Pipelines de observabilidad.
  2. Selecciona una plantilla.
  3. Selecciona y configura tu fuente.
  4. Selecciona y configura tus destinos.
  5. Configura tus procesadores.
  6. Instala el worker de pipelines de observabilidad.

Sintaxis de la plantilla

Los logs suelen almacenarse en índices independientes basados en datos de logs, como el servicio o el entorno de los que proceden los logs u otro atributo de log. En Observability Pipelines, puedes utilizar la sintaxis de plantilla para dirigir tus logs a diferentes índices basados en campos de log específicos.

Cuando el worker de Observability Pipelines no puede resolver el campo con la sintaxis de la plantilla, el worker adopta por defecto un comportamiento especificado para ese destino. Por ejemplo, si estás utilizando la plantilla {{application_id}} para el campo Prefix (Prefijo) del destino de Amazon S3, pero no hay un campo application_id en el log, el worker crea una carpeta llamada OP_UNRESOLVED_TEMPLATE_LOGS/ y publica los logs allí.

La siguiente tabla enumera los destinos y campos que admiten la sintaxis de plantilla, y explica qué ocurre cuando el worker no puede resolver el campo:

DestinoCampos compatibles con la sintaxis de plantillaComportamiento cuando no se puede resolver el campo
Amazon OpensearchÍndiceEl worker escribe logs en el índice datadog-op.
Amazon S3PrefijoEl worker crea una carpeta llamada OP_UNRESOLVED_TEMPLATE_LOGS/ y escribe allí los logs.
Azure BlobPrefijoEl worker crea una carpeta llamada OP_UNRESOLVED_TEMPLATE_LOGS/ y escribe allí los logs.
ElasticsearchTipo de fuenteEl worker escribe logs en el índice datadog-op.
Google ChronicleTipo de logPor defecto el tipo de log es DATADOG.
Google CloudPrefijoEl worker crea una carpeta llamada OP_UNRESOLVED_TEMPLATE_LOGS/ y escribe allí los logs.
OpensearchÍndiceEl worker escribe logs en el índice datadog-op.
Splunk HECÍndice
Tipo de fuente
El worker envía los logs al índice por defecto configurado en Splunk.
El worker envía por defecto el tipo de fuente httpevent.

Ejemplo

Si deseas enrutar logs según el campo de ID de aplicación del log (por ejemplo, application_id) al destino de Amazon S3, utiliza la sintaxis de campos de evento en el campo Prefix to apply to all object keys (Prefijo para aplicar a todas las claves de objeto).

El destino de Amazon S3 que muestra el campo de prefijo mediante la sintaxis de campos de evento /application_id={{ application_id }}/

Sintaxis

Campos de evento

Utiliza {{ <field_name> }} para acceder a los campos de evento de logs individuales. Por ejemplo:

{{ application_id }}

Especificadores Strftime

Utiliza especificadores strftime para la fecha y la hora. Por ejemplo:

year=%Y/month=%m/day=%d

Caracteres de escape

Utiliza un prefijo en un carácter con \ para escapar del carácter. En este ejemplo, se escapa la sintaxis del campo de evento:

\{{ field_name }}

Este ejemplo escapa de los especificadores strftime:

year=\%Y/month=\%m/day=\%d/

Colocación de eventos en lotes

Los destinos de los pipelines de observabilidad envían eventos en lotes a la integración aguas abajo. Un lote de eventos se descarga cuando se cumple uno de los siguientes parámetros:

  • Número máximo de eventos
  • Número máximo de bytes
  • Tiempo de espera (segundos)

Por ejemplo, si los parámetros de un destino son:

  • Número máximo de eventos = 2
  • Número máximo de bytes = 100.000
  • Tiempo de espera (segundos) = 5

Y el destino recibe 1 evento en una ventana de 5 segundos, descarga el lote en el tiempo de espera de 5 segundos.

Si el destino recibe 3 eventos en 2 segundos, descarga un lote con 2 eventos y descarga un segundo lote con el evento restante luego de 5 segundos. Si el destino recibe 1 evento que supera los 100.000 bytes, descarga este lote con ese evento.

DestinationMaximum EventsMaximum BytesTimeout (seconds)
Amazon OpenSearchNone10,000,0001
Amazon S3 (Datadog Log Archives)None100,000,000900
Amazon Security LakeNone256,000,000300
Azure Storage (Datadog Log Archives)None100,000,000900
Datadog Logs1,0004,250,0005
ElasticsearchNone10,000,0001
Google ChronicleNone1,000,00015
Google Cloud Storage (Datadog Log Archives)None100,000,000900
Microsoft SentinelNone10,000,0001
New Relic1001,000,0001
OpenSearchNone10,000,0001
SentinelOneNone1,000,0001
Splunk HTTP Event Collector (HEC)None1,000,0001
Sumo Logic Hosted CollecterNone10,000,0001

Note: The rsyslog and syslog-ng destinations do not batch events.

PREVIEWING: dgreen15/github-error-fix