Si experimentas un comportamiento inesperado en Observability Pipelines (OP) de Datadog, hay algunos problemas comunes que puedes investigar y esta guía puede ayudarte a resolver los problemas rápidamente. Si sigues teniendo problemas, ponte en contacto con el servicio de asistencia de Datadog para obtener más ayuda.
Ver logs y estadísticas del worker de Observability Pipelines
Para ver información sobre los workers de Observability Pipelines que se están ejecutando para un pipeline activo:
- Ve a Observability Pipelines.
- Selecciona tu pipeline.
- Haz clic en la pestaña Workers para ver el uso de memoria y CPU de los workers, las estadísticas de tráfico y cualquier error.
- Para ver el estado y la versión de los workers, haz clic en la pestaña Último despliegue y configuración.
- Para ver logs de los workers, haz clic en el engranaje situado en la parte superior derecha de la página y selecciona Ver logs OPW. Para obtener más detalles sobre cómo filtrar tus logs, consulta Sintaxis de búsqueda de logs. Para ver los logs de un worker específico, añade
@op_work.id:<worker_id> a la consulta de búsqueda.
Inspeccionar eventos enviados a través de tu pipeline para identificar problemas de configuración
Si puedes acceder a tus workers de Observability Pipelines localmente, utiliza el comando tap para ver los datos sin procesar enviados a través del origen y los procesadores de tu pipeline.
Habilitar la API del worker de Observability Pipelines
La API del worker de Observability Pipelines te permite interactuar con procesos del worker con el comando tap. Si estás utilizando los Helm charts proporcionados cuando configuraste un pipeline, entonces la API ya ha sido habilitada. De lo contrario, asegúrate de que la variable de entorno DD_OP_API_ENABLED esté configurara como true en /etc/observability-pipelines-worker/bootstrap.yaml. Para obtener más información, consulta Opciones de bootstrap. Esto configura la API para que escuche en localhost y el puerto 8686, que es lo que espera la CLI para tap.
Uso de top para encontrar el ID del componente
Necesitas el ID del componente de la fuente o el procesador para tap. Utiliza el comando top para encontrar el ID del componente en el que quieres tap:
observability-pipelines-worker top
Uso de tap para ver tus datos
Si te encuentras en el mismo host que el worker, ejecuta el siguiente comando para tap el resultado del componente:
observability-pipelines-worker tap <component_ID>
Si estás utilizando un entorno en contenedor, utiliza el comando docker exec o kubectl exec a fin de tener un intérprete de comandos en el contenedor para ejecutar el comando tap anterior.
Ver logs retrasados en el destino
Los destinos de Observability Pipelines colocan los eventos en lotes antes de enviarlos a la integración posterior. Por ejemplo, los destinos Amazon S3, Google Cloud Storage y Azure Storage tienen un tiempo de espera de lote de 900 segundos. Si los otros parámetros del lote (eventos máximos y bytes máximos) no se han cumplido dentro del tiempo de espera de 900 segundos, el lote se vacía a los 900 segundos. Esto significa que el componente de destino puede tardar hasta 15 minutos en enviar un lote de eventos a la integración posterior.
Estos son los parámetros de lote para cada destino:
| Destination | Maximum Events | Maximum Bytes | Timeout (seconds) |
|---|
| Amazon OpenSearch | None | 10,000,000 | 1 |
| Amazon S3 (Datadog Log Archives) | None | 100,000,000 | 900 |
| Azure Storage (Datadog Log Archives) | None | 100,000,000 | 900 |
| Datadog Logs | 1,000 | 4,250,000 | 5 |
| Elasticsearch | None | 10,000,000 | 1 |
| Google Chronicle | None | 1,000,000 | 15 |
| Google Cloud Storage (Datadog Log Archives) | None | 100,000,000 | 900 |
| New Relic | 100 | 1,000,000 | 1 |
| OpenSearch | None | 10,000,000 | 1 |
| Splunk HTTP Event Collector (HEC) | None | 1,000,000 | 1 |
| Sumo Logic Hosted Collecter | None | 10,000,000 | 1 |
Note: The rsyslog and syslog-ng destinations do not batch events.
Para obtener más información, consulta la colocación de eventos en lotes.
