(LEGACY) Configurar Observability Pipelines en Datadog
Observability Pipelines is not available on the US1-FED Datadog site.
If you upgrade your OP Workers version 1.8 or below to version 2.0 or above, your existing pipelines will break. Do not upgrade your OP Workers if you want to continue using OP Workers version 1.8 or below. If you want to use OP Worker 2.0 or above, you must migrate your OP Worker 1.8 or earlier pipelines to OP Worker 2.x.
Datadog recommends that you update to OP Worker versions 2.0 or above. Upgrading to a major OP Worker version and keeping it updated is the only supported way to get the latest OP Worker functionality, fixes, and security updates.
Overview
The Observability Pipelines Worker can collect, process, and route logs from any source to any destination. Using Datadog, you can build and manage all of your Observability Pipelines Worker deployments at scale.
This guide walks you through deploying the Worker in your common tools cluster and configuring the Datadog Agent to send logs and metrics to the Worker.
Deployment Modes
Remote configuration for Observability Pipelines is in private beta. Contact
Datadog support or your Customer Success Manager for access.
If you are enrolled in the private beta of Remote Configuration, you can remotely roll out changes to your Workers from the Datadog UI, rather than make updates to your pipeline configuration in a text editor and then manually rolling out your changes. Choose your deployment method when you create a pipeline and install your Workers.
See Updating deployment modes on how to change the deployment mode after a pipeline is deployed.
Assumptions
- You are already using Datadog and want to use Observability Pipelines.
- You have administrative access to the clusters where the Observability Pipelines Worker is going to be deployed, as well as to the workloads that are going to be aggregated.
- You have a common tools or security cluster for your environment to which all other clusters are connected.
Prerequisites
Before installing, make sure you have:
You can generate both of these in Observability Pipelines.
Provider-specific requirements
Ensure that your machine is configured to run Docker.
To run the Worker on your Kubernetes nodes, you need a minimum of two nodes with one CPU and 512MB RAM available. Datadog recommends creating a separate node pool for the Workers, which is also the recommended configuration for production deployments.
The EBS CSI driver is required. To see if it is installed, run the following command and look for ebs-csi-controller in the list:
kubectl get pods -n kube-system
A StorageClass is required for the Workers to provision the correct EBS drives. To see if it is installed already, run the following command and look for io2 in the list:
If io2 is not present, download the StorageClass YAML and kubectl apply it.
The AWS Load Balancer controller is required. To see if it is installed, run the following command and look for aws-load-balancer-controller in the list:
Datadog recommends using Amazon EKS >= 1.16.
See Best Practices for OPW Aggregator Architecture for production-level requirements.
To run the Worker on your Kubernetes nodes, you need a minimum of two nodes with one CPU and 512 MB RAM available. Datadog recommends creating a separate node pool for the Workers, which is also the recommended configuration for production deployments.
See Best Practices for OPW Aggregator Architecture for production-level requirements.
To run the Worker on your Kubernetes nodes, you need a minimum of two nodes with one CPU and 512MB RAM available. Datadog recommends creating a separate node pool for the Workers, which is also the recommended configuration for production deployments.
See Best Practices for OPW Aggregator Architecture for production-level requirements.
There are no provider-specific requirements for APT-based Linux.
There are no provider-specific requirements for RPM-based Linux.
In order to run the Worker in your AWS account, you need administrative access to that account. Collect the following pieces of information to run the Worker instances:
- The VPC ID your instances will run in.
- The subnet IDs your instances will run in.
- The AWS region your VPC is located in.
CloudFormation installs only support Remote Configuration.
Only use CloudFormation installs for non-production-level workloads.
Para ejecutar el worker en tu cuenta AWS, necesitas acceso administrativo a esa cuenta. Recopila la siguiente información para ejecutar las instancias del worker:
- El ID de VPC en el que se ejecutarán tus instancias.
- Los ID de subred en los que se ejecutarán tus instancias.
- La región AWS en la que se encuentra tu VPC.
Instalación del worker de Observability Pipelines
La imagen Docker del worker de Observability Pipelines está publicada en Docker Hub aquí.
Descarga el archivo de configuración de pipelines de ejemplo.
Ejecuta el siguiente comando para iniciar el worker de Observability Pipelines con Docker:
docker run -i -e DD_API_KEY=<API_KEY> \
-e DD_OP_PIPELINE_ID=<PIPELINE_ID> \
-e DD_SITE=<SITE> \
-p 8282:8282 \
-v ./pipeline.yaml:/etc/observability-pipelines-worker/pipeline.yaml:ro \
datadog/observability-pipelines-worker run
Sustituye <API_KEY> por tu clave de API Datadog, <PIPELINES_ID> por tu ID de configuración de Observability Pipelines y <SITE> por ./pipeline.yaml debe ser la ruta relativa o absoluta a la configuración que descargaste en el paso 1.
Descarga el archivo de valores de Helm chart para AWS EKS.
En el Helm chart, reemplaza los valores datadog.apiKey y datadog.pipelineId a fin de que coincidan con tu pipeline y usa site. Luego, instálalo en tu clúster con los siguientes comandos:
helm repo add datadog https://helm.datadoghq.com
helm upgrade --install \
opw datadog/observability-pipelines-worker \
-f aws_eks.yaml
Descarga el archivo de valores de Helm chart para Azure AKS.
En el Helm chart, sustituye los valores datadog.apiKey y datadog.pipelineId a fin de que coincidan con tu pipeline y utiliza site. Luego, instálalo en tu clúster con los siguientes comandos:
helm repo add datadog https://helm.datadoghq.com
helm upgrade --install \
opw datadog/observability-pipelines-worker \
-f azure_aks.yaml
Descarga el archivo de valores de Helm chart para Google GKE.
En el Helm chart, sustituye los valores datadog.apiKey y datadog.pipelineId a fin de que coincidan con tu pipeline y utiliza site. Luego, instálalo en tu clúster con los siguientes comandos:
helm repo add datadog https://helm.datadoghq.com
helm upgrade --install \
opw datadog/observability-pipelines-worker \
-f google_gke.yaml
Ejecuta los siguientes comandos a fin de configurar APT para descargar a través de HTTPS:
sudo apt-get update
sudo apt-get install apt-transport-https curl gnupg
Ejecuta los siguientes comandos para configurar el repositorio Datadog deb en tu sistema y crear un llavero de archivos de Datadog:
sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://apt.datadoghq.com/ stable observability-pipelines-worker-1' > /etc/apt/sources.list.d/datadog-observability-pipelines-worker.list"
sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg
sudo chmod a+r /usr/share/keyrings/datadog-archive-keyring.gpg
curl https://keys.datadoghq.com/DATADOG_APT_KEY_CURRENT.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
curl https://keys.datadoghq.com/DATADOG_APT_KEY_06462314.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
curl https://keys.datadoghq.com/DATADOG_APT_KEY_C0962C7D.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
Ejecuta los siguientes comandos para actualizar tu repositorio local apt e instalar el worker:
sudo apt-get update
sudo apt-get install observability-pipelines-worker datadog-signing-keys
Añade tus claves y el sitio (
sudo cat <<-EOF > /etc/default/observability-pipelines-worker
DD_API_KEY=<API_KEY>
DD_OP_PIPELINE_ID=<PIPELINE_ID>
DD_SITE=<SITE>
EOF
Descarga el archivo de configuración de ejemplo en /etc/observability-pipelines-worker/pipeline.yaml en el host.
Inicia el worker:
sudo systemctl restart observability-pipelines-worker
Ejecuta los siguientes comandos para configurar el repositorio rpm de Datadog en tu sistema:
cat <<EOF > /etc/yum.repos.d/datadog-observability-pipelines-worker.repo
[observability-pipelines-worker]
name = Observability Pipelines Worker
baseurl = https://yum.datadoghq.com/stable/observability-pipelines-worker-1/\$basearch/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_4F09D16B.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
EOF
Nota: Si estás ejecutando RHEL v8.1 o CentOS v8.1, utiliza repo_gpgcheck=0 en lugar de repo_gpgcheck=1 en la configuración anterior.
Actualiza tus paquetes e instala el worker:
sudo yum makecache
sudo yum install observability-pipelines-worker
Añade tus claves y el sitio (
sudo cat <<-EOF > /etc/default/observability-pipelines-worker
DD_API_KEY=<API_KEY>
DD_OP_PIPELINE_ID=<PIPELINE_ID>
DD_SITE=<SITE>
EOF
Descarga el archivo de configuración de ejemplo en /etc/observability-pipelines-worker/pipeline.yaml en el host.
Inicia el worker:
sudo systemctl restart observability-pipelines-worker
- Descarga la configuración de ejemplo.
- Configura el módulo del worker en tu Terraform existente con la configuración de ejemplo. Asegúrate de actualizar los valores en
vpc-id, subnet-ids y region para que coincidan con tu despliegue AWS en la configuración. Además, actualiza los valores en datadog-api-key y pipeline-id para que coincidan con tu pipeline.
Utiliza sólo instalaciones de CloudFormation para cargas de trabajo que no sean de nivel de producción.
Para instalar el worker en tu cuenta AWS, utiliza la plantilla de CloudFormation para crear un stack tecnológico:
Descarga la plantilla de CloudFormation para el worker.
En la consola CloudFormation, haz clic en *Create stack (Crear stack tecnológico) y selecciona la opción Con nuevos recursos (estándar).
Asegúrate de que la opción Plantilla lista está seleccionada y selecciona Cargar un archivo de plantilla. Haz clic en Choose file (Seleccionar archivo) y añade el archivo de plantilla de CloudFormation que descargaste anteriormente. Haz clic en Next (Siguiente).
Introduce un nombre para el stack tecnológico en Especificar detalles del stack tecnológico.
Rellena los parámetros de la plantilla de CloudFormation. Algunos requieren una atención especial:
Para APIKey y PipelineID, proporcione la clave y el ID que recopilaste anteriormente en la sección Requisitos previos.
Para VPCID y SubnetIDs, proporciona las subredes y la VPC que elegiste anteriormente.
Todos los demás parámetros están configurados con valores predeterminados razonables para un despliegue del worker, pero puedes adaptarlos a tu caso de uso según sea necesario.
Haz clic en Next (Siguiente).
Revisa y asegúrate de que los parámetros son los esperados. Haz clic en las casillas de verificación de los permisos necesarios para IAM y luego haz clic en Submit (Enviar) para crear el stack tecnológico.
CloudFormation se encarga de la instalación en este punto; las instancias de worker se lanzan, se descarga el software necesario y comienza a ejecutarse automáticamente.
Consulta Configuraciones para obtener más información sobre la fuente, la transformación y el sumidero utilizados en la configuración de ejemplo. Consulta Trabajar con datos para obtener más información sobre la transformación de tus datos.
Balanceo de carga
La configuración orientada a la producción no se incluye en las instrucciones de Docker. En su lugar, consulta las normas de tu empresa para el balanceo de carga en entornos en contenedores. Si estás realizando tests en tu máquina local, no es necesario configurar un balanceador de carga.
Utiliza los balanceadores de carga proporcionados por tu proveedor de nube.
Se ajustan en base a los eventos de escalado automático para los que está configurada la configuración de Helm por defecto. Los balanceadores de carga son internos,
por lo que sólo son accesibles dentro de tu red.
Utiliza la URL del balanceador de carga que te proporciona Helm cuando configuras el Datadog Agent.
Se utilizan NLB suministrados por el controlador del balanceador de carga AWS.
Para obtener recomendaciones sobre el balanceador de carga al escalar el worker, consulta Planificación de la capacidad y escalado.
Balanceo de carga en zonas de disponibilidad cruzadas
La configuración de Helm proporcionada intenta simplificar el balanceo de carga, pero debes tener en cuenta las posibles implicaciones de precio del tráfico en zonas de disponibilidad cruzadas. En la medida de lo posible, las muestras intentan evitar crear situaciones en las que puedan producirse múltiples saltos entre zonas de disponibilidad.
Las configuraciones de ejemplo no habilitan la función de balanceo de carga en zonas cruzadas, disponible en este controlador. Para habilitarla, añade la siguiente anotación al bloque service:
service.beta.kubernetes.io/aws-load-balancer-attributes: load_balancing.cross_zone.enabled=true
Para obtener más información, consulta el controlador del balanceador de carga AWS.
Utiliza los balanceadores de carga proporcionados por tu proveedor de nube.
Se ajustan en base a los eventos de escalado automático para los que está configurada la configuración de Helm por defecto. Los balanceadores de carga son internos,
por lo que sólo son accesibles dentro de tu red.
Utiliza la URL del balanceador de carga que te proporciona Helm cuando configuras el Datadog Agent.
Para obtener recomendaciones sobre el balanceador de carga al escalar el worker, consulta Planificación de la capacidad y escalado.
Balanceo de carga en zonas de disponibilidad cruzadas
La configuración de Helm proporcionada intenta simplificar el balanceo de carga, pero debes tener en cuenta las posibles implicaciones de precio del tráfico en zonas de disponibilidad cruzadas. En la medida de lo posible, las muestras intentan evitar crear situaciones en las que puedan producirse múltiples saltos entre zonas de disponibilidad.
Utiliza los balanceadores de carga proporcionados por tu proveedor de nube.
Se ajustan en base a los eventos de escalado automático para los que está configurada la configuración de Helm por defecto. Los balanceadores de carga son internos,
por lo que sólo son accesibles dentro de tu red.
Utiliza la URL del balanceador de carga que te proporciona Helm cuando configuras el Datadog Agent.
Para obtener recomendaciones sobre el balanceador de carga al escalar el worker, consulta Planificación de la capacidad y escalado.
Balanceo de carga en zonas de disponibilidad cruzadas
La configuración de Helm proporcionada intenta simplificar el balanceo de carga, pero debes tener en cuenta las posibles implicaciones de precio del tráfico en zonas de disponibilidad cruzadas. En la medida de lo posible, las muestras intentan evitar crear situaciones en las que puedan producirse múltiples saltos entre zonas de disponibilidad.
El acceso global está activado por defecto ya que es probable que se requiera para su uso en un clúster de herramientas compartidas.
No se proporciona compatibilidad integrada para el balanceo de carga, dada la naturaleza de máquina única de la instalación. Necesitas suministrar tus propios balanceadores de carga utilizando cualquiera que sea el estándar de tu empresa.
No se proporciona compatibilidad integrada para el balanceo de carga, dada la naturaleza de máquina única de la instalación. Necesitas suministrar tus propios balanceadores de carga utilizando cualquiera que sea el estándar de tu empresa.
Un NLB es suministrado por el módulo Terraform y está configurado para apuntar a las instancias. Tu dirección DNS se devuelve en el resultado lb-dns en Terraform.
Utiliza sólo instalaciones de CloudFormation para cargas de trabajo que no sean de nivel de producción.
Un NLB es suministrado por la plantilla de CloudFormation y está configurado para apuntar al grupo de escalado automático. Su dirección DNS se devuelve en el resultado LoadBalancerDNS en CloudFormation.
Almacenamiento en buffer
Observability Pipelines incluye múltiples estrategias de almacenamiento en buffer que te permiten aumentar la resiliencia de tu clúster ante fallos posteriores. Las configuraciones de ejemplo proporcionadas utilizan buffers de disco, cuyas capacidades están clasificadas para aproximadamente 10 minutos de datos a 10 Mbps/núcleo para despliegues de Observability Pipelines. Suele ser tiempo suficiente para que los problemas transitorios se resuelvan por sí solos o para que los responsables de la respuesta a incidentes decidan qué hay que hacer con los datos de observabilidad.
Por defecto, el directorio de datos del worker de Observability Pipelines está configurado en /var/lib/observability-pipelines-worker. Asegúrate de que tu máquina host tiene una cantidad suficiente de capacidad de almacenamiento asignado al punto de montaje del contenedor.
Para AWS, Datadog recomienda utilizar la familia de unidades io2 EBS. También puedes utilizar las unidades gp3.
Para Azure AKS, Datadog recomienda utilizar los discos default (también conocidos como managed-csi).
Para Google GKE, Datadog recomienda utilizar la clase de unidades premium-rwo ya que está respaldada por SSD. La clase respaldada por HDD, standard-rwo, podría no proporcionar suficiente rendimiento de escritura para que los buffers sean útiles.
Por defecto, el directorio de datos del worker de Observability Pipelines se configura como /var/lib/observability-pipelines-worker. Si estás utilizando la configuración de ejemplo, debes asegurarte de que tienes al menos 288 GB de espacio disponible para el almacenamiento en buffer.
Siempre que sea posible, se recomienda tener un SSD separado, montado en esa localización.
Por defecto, el directorio de datos del worker de Observability Pipelines está configurado como /var/lib/observability-pipelines-worker. Si estás utilizando la configuración de ejemplo, debes asegurarte de que tienes al menos 288 GB de espacio disponible para el almacenamiento en buffer.
Siempre que sea posible, se recomienda tener un SSD separado, montado en esa localización.
De forma predeterminada, se asigna una unidad EBS de 288 GB a cada instancia y el ejemplo de configuración anterior está configurado para utilizarlo para el almacenamiento en buffer.
Las unidades EBS creadas por esta plantilla de CloudFormation tienen su ciclo de vida ligado a la instancia con la que se crean. Esto conduce a la pérdida de datos si una instancia se cierra, por ejemplo por el grupo de escalado automático. Por este motivo, utiliza sólo instalaciones de CloudFormation para cargas de trabajo que no sean de nivel de producción.
Por defecto, se asigna una unidad EBS de 288 GB a cada instancia, que se monta y formatea automáticamente al arrancar la instancia.
Conectar el Datadog Agent al worker de Observability Pipelines
Para enviar logs del Datadog Agent al worker de Observability Pipelines, actualiza tu configuración del Agent con lo siguiente:
observability_pipelines_worker:
logs:
enabled: true
url: "http://<OPW_HOST>:8282"
OPW_HOST es la IP del balanceador de carga o de la máquina que configuraste anteriormente. Para instalaciones basadas Docker de host único, esta es la dirección IP del host subyacente. Para instalaciones basadas en Kubernetes, puedes recuperarla ejecutando el siguiente comando y copiando la dirección EXTERNAL-IP:
kubectl get svc opw-observability-pipelines-worker
Para instalaciones de Terraform, el resultado lb-dns proporciona el valor necesario. Para instalaciones de CloudFormation, el resultado LoadBalancerDNS de CloudFormation tiene la URL correcta que se debe utilizar.
En este punto, tus datos de observabilidad deberían ir al worker y están disponibles para el procesamiento de los datos.
Actualización de los modos de despliegue
After deploying a pipeline, you can also switch deployment methods, such as going from a manually managed pipeline to a remote configuration enabled pipeline or vice versa.
If you want to switch from a remote configuration deployment to a manually managed deployment:
- Navigate to Observability Pipelines and select the pipeline.
- Click the settings cog.
- In Deployment Mode, select manual to enable it.
- Set the
DD_OP_REMOTE_CONFIGURATION_ENABLED flag to false and restart the Worker. Workers that are not restarted with this flag continue to be remote configuration enabled, which means that the Workers are not updated manually through a local configuration file.
If you want to switch from manually managed deployment to a remote configuration deployment:
- Navigate to Observability Pipelines and select the pipeline.
- Click the settings cog.
- In Deployment Mode, select Remote Configuration to enable it.
- Set the
DD_OP_REMOTE_CONFIGURATION_ENABLED flag to true and restart the Worker. Workers that are not restarted with this flag are not polled for configurations deployed in the UI. - Deploy a version in your version history, so that the Workers receive the new version configuration. Click on a version. Click Edit as Draft and then click Deploy.
Trabajar con datos
El ejemplo de configuración proporcionado tiene pasos de procesamiento de ejemplo que muestran las herramientas de Observability Pipelines y aseguran que los datos enviados a Datadog están en el formato correcto.
Procesamiento de logs
La configuración de Observability Pipelines de ejemplo hace lo siguiente:
- Recopila logs enviados desde el Datadog Agent al worker de Observability Pipelines.
- Etiqueta logs que pasan por el worker de Observability Pipelines. Esto ayuda a determinar el tráfico que aún debe transferirse al worker a medida que actualizas tus clústeres. Estas etiquetas (tags) también muestran cómo los logs se enrutan a través del balanceador de carga, en caso de que haya desequilibrios.
- Corrige el estado de los logs que llegan a través del worker Debido a cómo el Datadog Agent recopila logs de los contenedores, el atributo
.status proporcionado no refleja correctamente el nivel real del mensaje. Se elimina para evitar problemas con las reglas de análisis en el backend, donde los logs se reciben del worker.
Los siguientes son dos componentes importantes del ejemplo de configuración:
logs_parse_ddtags: Analiza las etiquetas almacenadas en una cadena en datos estructurados.logs_finish_ddtags: Recodifica las etiquetas para que estén en el formato en el que las enviaría el Datadog Agent.
Internamente, el Datadog Agent representa las etiquetas de logs como un CSV en una sola cadena. Para manipular eficazmente estas etiquetas, deben ser analizadas, modificadas y luego recodificadas antes de ser enviadas al endpoint de ingesta. Estos pasos están escritos para realizar estas acciones automáticamente. Cualquier modificación que realices en el proceso, especialmente para la manipulación de las etiquetas, debe realizarse entre estos dos pasos.
En este punto, tu entorno está configurado para Observability Pipelines con datos que fluyen a través de él. Es probable que necesites una configuración adicional para tus casos de uso específicos, aunque las herramientas proporcionadas te ofrecen un punto de partida.
Lectura adicional
Más enlaces, artículos y documentación útiles:
