Este producto no es compatible con el sitio Datadog seleccionado. ().
Disponible para:

Registros | Métricas

Descripción general

Utilice la fuente de OpenTelemetry (OTel) de Observability Pipelines para recopilar registros o métricas desde su OTel Collector a través de HTTP o gRPC.

Notas:

  • Si está utilizando la distribución de Datadog del Collector de OpenTelemetry (DDOT), utilice la fuente de OpenTelemetry para enviar datos a Observability Pipelines.
  • Si está utilizando la distribución de Splunk HEC del Collector de OpenTelemetry, utilice la fuente Splunk HEC para enviar registros a Observability Pipelines.

Cuándo utilizar esta fuente

Escenarios comunes en los que podría utilizar esta fuente:

  • Usted utiliza OpenTelemetry como su método estándar para recopilar y enrutar datos, y desea normalizar esos datos antes de enrutarlos a diferentes destinos.
  • Usted está recopilando datos de múltiples fuentes y desea agregarlos en un lugar central para un procesamiento consistente.
    • Por ejemplo, si algunos de sus servicios exportan registros utilizando OpenTelemetry, mientras que otros servicios utilizan Datadog Agents u otras fuentes de Observability Pipelines, puede enviar todos sus datos a Observability Pipelines para su procesamiento.

Requisitos previos

Si sus reenviadores están configurados globalmente para habilitar SSL, necesita los certificados TLS apropiados y la contraseña que utilizó para crear su clave privada.

Configuración

Para la gestión de secretos: Solo ingrese los identificadores para las direcciones de escucha HTTP y gRPC de OpenTelemetry y, si corresponde, la contraseña de la clave TLS. No ingrese los valores reales.

Configure esta fuente cuando configure una canalización. Puede configurar una canalización en el UI, usando la API o con Terraform. Las instrucciones de esta sección son para configurar la fuente en la interfaz de usuario.

Después de seleccionar la fuente OpenTelemetry en la interfaz de usuario de la canalización:

  1. Ingrese el identificador para su dirección de escucha HTTP. Si lo deja en blanco, se utiliza el predeterminado.
  2. Ingrese el identificador para su dirección de escucha gRPC. Si lo deja en blanco, se utiliza el predeterminado.
If you enter secret identifiers and then choose to use environment variables, the environment variable is the identifier entered and prepended with DD_OP_. For example, if you entered PASSWORD_1 for a password identifier, the environment variable for that password is DD_OP_PASSWORD_1.

Configuración de TLS opcional

Toggle the switch to Enable TLS.

  • If you are using Secrets Management, enter the identifier for the key pass. See Secret defaults for the default used if the field is left blank.
  • Enter the following certificate and key files:
    • Server Certificate Path: The path to the certificate file that has been signed by your Certificate Authority (CA) root file in DER, PEM, or CRT (X.509).
    • (Optional) CA Certificate Path: The path to the certificate file that is your Certificate Authority (CA) root file in DER, PEM, or CRT (X.509).
    • (Optional) Private Key Path: The path to the .key private key file that belongs to your Server Certificate Path in DER, PEM, or CRT (PKCS #8) format.
    • Notes:
      • The configuration data directory /var/lib/observability-pipelines-worker/config/ is automatically appended to the file paths. See Advanced Worker Configurations for more information.
      • The file must be readable by the observability-pipelines-worker group and user.
  • (Optional) Toggle Verify certificate to require connecting clients to present a valid client certificate. This enforces mutual TLS (mTLS), where the Worker verifies the identity of each connecting client.
La configuración de la fuente OpenTelemetry

Valores predeterminados de Secret

These are the defaults used for secret identifiers and environment variables.

  • Identificador de dirección HTTP:
    • Hace referencia a la dirección de socket HTTP en la que el Observability Pipelines Worker escucha los datos del OTel Collector.
    • El identificador predeterminado es SOURCE_OTEL_HTTP_ADDRESS.
  • Identificador de dirección gRPC:
    • Hace referencia a la dirección del socket gRPC en la que el Observability Pipelines Worker escucha los datos del OTel Collector.
    • El identificador predeterminado es SOURCE_OTEL_GRPC_ADDRESS.
  • Identificador de frase de contraseña TLS (cuando TLS está habilitado):
    • El identificador predeterminado es SOURCE_OTEL_KEY_PASS.

You must provide both HTTP and gRPC endpoints. Configure your OTLP exporters to point to one of these endpoints. See Send data to the Observability Pipelines Worker for more information.

  • HTTP listener address

    • The Observability Pipelines Worker listens to this socket address to receive data from the OTel collector.
    • The default environment variable is DD_OP_SOURCE_OTEL_HTTP_ADDRESS.
  • gRPC listener address

    • The Observability Pipelines Worker listens to this socket address to receive data from the OTel collector.
    • The default environment variable is DD_OP_SOURCE_OTEL_GRPC_ADDRESS.

If TLS is enabled:

  • OpenTelemetry TLS passphrase
    • The default environment variable is DD_OP_SOURCE_OTEL_KEY_PASS.

Envíe datos al Observability Pipelines Worker

Configure sus exportadores de OTel para que apunten a HTTP o gRPC. El Worker expone puertos de escucha configurables para cada protocolo.

Los puertos 4318 (HTTP) y 4317 (gRPC) que se muestran a continuación son solo ejemplos. Puede configurar el valor del puerto para cualquiera de los protocolos en el Worker. Asegúrese de que sus exportadores de OTel coincidan con el valor de puerto que elija.

Ejemplo de configuración HTTP

El Worker expone el punto de conexión HTTP en el puerto 4318, que es el puerto predeterminado. Puede configurar el valor del puerto en el Worker.

Por ejemplo, para configurar un exportador de registros de OTel a través de HTTP en Python:

    from opentelemetry.exporter.otlp.proto.http._log_exporter import OTLPLogExporter
    http_exporter = OTLPLogExporter(
        endpoint="http://worker:4318/v1/logs"
    )

Ejemplo de configuración gRPC

El Worker expone el punto de conexión gRPC en el puerto 4317, que es el puerto predeterminado. Puede configurar el valor del puerto en el Worker.

Por ejemplo, para configurar un exportador de registros de OTel a través de gRPC en Python:

    from opentelemetry.exporter.otlp.proto.grpc._log_exporter import OTLPLogExporter
    grpc_exporter = OTLPLogExporter(
        endpoint="grpc://worker:4317"
    )

Establezca las variables de entorno de la dirección de escucha en los siguientes valores predeterminados. Si configuró valores de puerto diferentes en el Worker, utilice esos en su lugar.

  • Dirección de escucha HTTP: worker:4318
  • Dirección de escucha gRPC: worker:4317

Ejemplo de configuración HTTP

El Worker expone el punto de conexión HTTP en el puerto 4318, que es el puerto predeterminado. Puede configurar el valor del puerto en el Worker.

Por ejemplo, para configurar un exportador de métricas OTel a través de HTTP en Python:

    from opentelemetry.exporter.otlp.proto.http.metric_exporter import OTLPMetricExporter
    http_exporter = OTLPMetricExporter(
        endpoint="http://worker:4318/v1/metrics"
    )

Ejemplo de configuración gRPC

El Worker expone el punto de conexión gRPC en el puerto 4317, que es el puerto predeterminado. Puede configurar el valor del puerto en el Worker.

Por ejemplo, para configurar un exportador de métricas OTel a través de gRPC en Python:

    from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
    grpc_exporter = OTLPMetricExporter(
        endpoint="grpc://worker:4317"
    )

Establezca las variables de entorno de la dirección de escucha en los siguientes valores predeterminados. Si configuró valores de puerto diferentes en el Worker, utilice esos en su lugar.

  • Dirección de escucha HTTP: worker:4318
  • Dirección de escucha gRPC: worker:4317

Enviar datos desde la distribución de Datadog del OpenTelemetry Collector a Observability Pipelines

Para enviar registros desde la distribución de Datadog del OpenTelemetry (DDOT) Collector:

  1. Despliegue el DDOT Collector usando Helm. Consulte Instalar el DDOT Collector como un DaemonSet de Kubernetes para obtener instrucciones.
  2. Configure una canalización en Observability Pipelines usando la fuente de OpenTelemetry.
    1. (Opcional) Datadog recomienda agregar un procesador de edición de campos a la canalización que añada el campo op_otel_ddot:true en caso de que el registro no tenga el campo source.
    2. Cuando instale el Worker, para las variables de entorno de la fuente de OpenTelemetry:
      1. Configure su dirección de escucha HTTP en 0.0.0.0:4318.
      2. Configure su dirección de escucha gRPC en 0.0.0.0:4317.
    3. Después de instalar el Worker y desplegar la canalización, actualice el otel-config.yaml del OpenTelemetry Collector para incluir un exportador que envíe registros a Observability Pipelines. Por ejemplo:
      exporters:
          otlphttp:
              endpoint: http://opw-observability-pipelines-worker.<NAMESPACE>.svc.cluster.local:4318
      ...
      service:
          pipelines:
              logs:
                  exporters: [otlphttp]
      
      Replace <NAMESPACE> with the Kubernetes namespace where the Observability Pipelines Worker is deployed (for example, default).
    4. Redeploy the Datadog Agent with the updated otel-config.yaml. For example, if the Agent is installed in Kubernetes:
      helm upgrade --install datadog-agent datadog/datadog \
      --values ./agent.yaml \
      --set-file datadog.otelCollector.config=./otel-config.yaml
      

Notas:

  • Debido a que DDOT envía registros a Observability Pipelines y no al Datadog Agent, la siguiente configuración no funciona para enviar registros desde DDOT a Observability Pipelines:
    • DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_ENABLED
    • DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_URL
  • Los registros enviados desde DDOT pueden tener objetos anidados que impiden que Datadog realice el parseo de los registros correctamente. Para resolver esto, Datadog recomienda usar el Custom Processor para aplanar el objeto resource anidado.
  • Si el DDOT Collector y el Observability Pipelines Worker se ejecutan en el mismo servidor, sus puertos de receptor OTLP predeterminados (4317/4318) pueden entrar en conflicto. En una implementación típica de Kubernetes, el Collector y el Worker se ejecutan en pods separados, por lo que esto no es un problema.

Para enviar métricas desde la distribución de Datadog del OpenTelemetry (DDOT) Collector:

  1. Despliegue el DDOT Collector usando Helm. Consulte Instalar el DDOT Collector como un DaemonSet de Kubernetes para obtener instrucciones.
  2. Configure una canalización en Observability Pipelines usando la fuente de OpenTelemetry.
    1. (Opcional) Datadog recomienda agregar un procesador de edición de campos a la canalización que anexe el campo op_otel_ddot:true.
    2. Cuando instale el Worker, para las variables de entorno de la fuente de OpenTelemetry:
      1. Configure su dirección de escucha HTTP en 0.0.0.0:4318.
      2. Configure su dirección de escucha gRPC en 0.0.0.0:4317.
    3. Después de instalar el Observability Pipelines Worker y de desplegar la canalización, actualice el otel-config.yaml del OpenTelemetry Collector para incluir un exportador que envíe métricas a Observability Pipelines. Por ejemplo:
      exporters:
          otlphttp:
              endpoint: http://opw-observability-pipelines-worker.<NAMESPACE>.svc.cluster.local:4318
      ...
      service:
          pipelines:
              metrics:
                  exporters: [otlphttp]
      
      Replace <NAMESPACE> with the Kubernetes namespace where the Observability Pipelines Worker is deployed (for example, default).
    4. Redeploy the Datadog Agent with the updated otel-config.yaml. For example, if the Agent is installed in Kubernetes:
      helm upgrade --install datadog-agent datadog/datadog \
      --values ./agent.yaml \
      --set-file datadog.otelCollector.config=./otel-config.yaml
      

Notas:

  • Debido a que DDOT envía métricas a Observability Pipelines, y no al Datadog Agent, la siguiente configuración no funciona para enviar métricas desde DDOT a Observability Pipelines:
    • DD_OBSERVABILITY_PIPELINES_WORKER_METRICS_ENABLED
    • DD_OBSERVABILITY_PIPELINES_WORKER_METRICS_URL
  • Las métricas enviadas desde DDOT pueden tener objetos anidados que impiden que Datadog realice el parseo de las métricas correctamente. Para resolver esto, Datadog recomienda usar el Custom Processor para aplanar el objeto resource anidado.
  • Si el DDOT Collector y el Observability Pipelines Worker se ejecutan en el mismo servidor, sus puertos de receptor OTLP predeterminados (4317/4318) pueden entrar en conflicto. En una implementación típica de Kubernetes, el Collector y el Worker se ejecutan en pods separados, por lo que esto no es un problema.

Lecturas adicionales