(LEGACY) Configurar Observability Pipelines para enviar logs en un formato rehidratable por Datadog a Amazon S3 y Datadog
Observability Pipelines no está disponible en el sitio US1-FED Datadog.
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.
El worker de Observability Pipelines puede recopilar, procesar y enrutar logs desde cualquier fuente a cualquier destino. Con Datadog, puedes crear y gestionar todos los despliegues de tu worker de Observability Pipelines en escala.
Esta guía te mostrará el despliegue del worker en tu clúster de herramientas comunes y su configuración para enviar logs en un formato rehidratable por Datadog a un almacenamiento en la nube para su archivado.
Modos de despliegue
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.
Supuestos
- Ya estás utilizando Datadog y quieres utilizar Observability Pipelines.
- Tienes acceso administrativo a clústeres donde se va a desplegar el worker de Observability Pipelines, así como a las cargas de trabajo que se van a agregar.
- Dispones de un clúster de herramientas comunes o de seguridad para tu entorno al que están conectados todos los demás clústeres.
Requisitos previos
Antes de la instalación, asegúrate de que tienes:
Puedes generar ambos en Observability Pipelines.
Requisitos específicos de los proveedores
Asegúrate de que tu máquina está configurada para ejecutar Docker.
Para ejecutar el worker en tus nodos Kubernetes, necesitas un mínimo de dos nodos con una CPU y 512 MB de RAM disponibles. Datadog recomienda crear un grupo de nodos separado para los workers, que es también la configuración recomendada para despliegues en producción.
Se necesita la unidad EBS CSI. Para comprobar si está instalada, ejecuta el siguiente comando y busca ebs-csi-controller en la lista:
kubectl get pods -n kube-system
Se necesita StorageClass para que los workers suministren las unidades EBS correctas. Para comprobar si ya está instalado, ejecuta el siguiente comando y busca io2 en la lista:
Si io2 no está presente, descarga el YAML de StorageClass y kubectl apply.
Se necesita el controlador del balanceador de carga AWS. Para comprobar si está instalado, ejecuta el siguiente comando y busca aws-load-balancer-controller en la lista:
Datadog recomienda utilizar Amazon EKS >= v1.16.
Para conocer los requisitos a nivel de producción, consulta Prácticas recomendadas para la arquitectura del agregador OPW.
No existen requisitos específicos del proveedor para Linux basado en APT.
No existen requisitos específicos del proveedor para Linux basado en APT.
Para ejecutar el worker en tu cuenta AWS, necesitas acceso administrativo a esa cuenta y la siguiente información:
- El ID de la VPC en la 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.
Configurar archivos de logs
Cuando instales el worker de Observability Pipelines más adelante, la configuración proporcionada como ejemplo incluye un sumidero para enviar logs a Amazon S3 en un formato rehidratable por Datadog. Para utilizar esta configuración, crea un bucket S3 para tus archivos y configura una política IAM que permita a los workers escribir en el bucket S3. A continuación, conecta el bucket S3 a los archivos de logs de Datadog.
Consulta Precios de AWS para conocer las tarifas de transferencia de datos entre regiones y cómo pueden verse afectados los costes de almacenamiento en la nube.
Crear un bucket S3 y configurar una política IAM
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- Crea un usuario IAM y adjúntale la política anterior. Crea credenciales de acceso para el usuario IAM. Guarda estas credenciales como
AWS_ACCESS_KEY y AWS_SECRET_ACCESS_KEY.
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- Crea una cuenta de servicio para utilizar la política creada anteriormente.
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- Crea un usuario IAM y adjúntale la política anterior. Crea credenciales de acceso para el usuario IAM. Guarda estas credenciales como
AWS_ACCESS_KEY y AWS_SECRET_ACCESS_KEY.
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- Crea un usuario IAM y adjúntale la política anterior. Crea credenciales de acceso para el usuario IAM. Guarda estas credenciales como
AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY.
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- Adjunta la política al perfil de la instancia IAM creado con Terraform, que encontrarás en el resultado
iam-role-name.
Conectar el bucket S3 a archivos de logs de Datadog
Debes conectar el bucket S3 que creaste anteriormente a archivos de logs de Datadog para poder rehidratar los archivos más adelante.
- Ve a Reenvío de logs de Datadog.
- Haz clic en + New Archive (+ Nuevo archivo).
- Introduce un nombre de archivo descriptivo.
- Añade una consulta que filtre todos los logs que pasan por los pipelines de logs para que esos logs no vayan a este archivo. Por ejemplo, añade la consulta
observability_pipelines_read_only_archive, suponiendo que ninguno de los logs que pasan por el pipeline tiene esa etiqueta (tag) añadida. - Selecciona AWS S3.
- Selecciona la cuenta AWS en la que se encuentra tu bucket.
- Introduce el nombre del bucket S3.
- También puedes introducir una ruta.
- Comprueba la sentencia de confirmación.
- También puedes añadir etiquetas y definir el tamaño máximo de análisis para la rehidratación. Para obtener más información, consulta Configuración avanzada.
- Haz clic en Guardar.
Para obtener más información, consulta la documentación de los archivos de logs.
Instalar el 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> \
-e AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID> \
-e AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY> \
-e DD_ARCHIVES_BUCKET=<AWS_BUCKET_NAME> \
-e DD_ARCHIVES_SERVICE_ACCOUNT=<BUCKET_AWS_REGION> \
-p 8282:8282 \
-v ./pipeline.yaml:/etc/observability-pipelines-worker/pipeline.yaml:ro \
datadog/observability-pipelines-worker run
Sustituye estos parámetros por la siguiente información:
<API_KEY> por tu clave de API Datadog.<PIPELINES_ID> por tu ID de configuración de Observability Pipelines.<SITE> with AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY por las credenciales AWS que creaste anteriormente.<AWS_BUCKET_NAME> por el nombre del bucket S3 que almacena los logs.<BUCKET_AWS_REGION> por la región AWS del servicio de destino../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, sustituye estos parámetros por la siguiente información:
datadog.apiKey por tu clave de API Datadog.datadog.pipelineId por tu ID de configuración de Observability Pipelines.site with ${DD_ARCHIVES_SERVICE_ACCOUNT} en serviceAccount.name por el nombre de la cuenta de servicio.${DD_ARCHIVES_BUCKET} en pipelineConfig.sinks.datadog_archives por el nombre del bucket S3 que almacena los logs.${DD_ARCHIVES_SERVICE_ACCOUNT} en pipelineConfig.sinks.datadog_archives por la región AWS del servicio de destino.
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
Ejecute los siguientes comandos para 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 (<AWS_BUCKET_NAME> por el nombre del bucket S3 que almacena los logs y <BUCKET_AWS_REGION> por la región AWS del servicio de destino.
sudo cat <<-EOF > /etc/default/observability-pipelines-worker
AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID>
AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY>
DD_ARCHIVES_BUCKET=<AWS_BUCKET_NAME>
DD_ARCHIVES_SERVICE_ACCOUNT=<BUCKET_AWS_REGION>
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 (<AWS_BUCKET_NAME> por el nombre del bucket S3 que almacena los logs y <BUCKET_AWS_REGION> por la región AWS del servicio de destino.
sudo cat <<-EOF > /etc/default/observability-pipelines-worker
AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID>
AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY>
DD_ARCHIVES_BUCKET=<AWS_BUCKET_NAME>
DD_ARCHIVES_SERVICE_ACCOUNT=<BUCKET_AWS_REGION>
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.
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, la configuración de un balanceador de carga es innecesaria.
Utiliza los balanceadores de carga proporcionados por tu proveedor de nube.
Los balanceadores de carga se ajustan basándose en eventos de autoescalado para los que Helm está configurado 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.
Dada la naturaleza de máquina única de la instalación, no hay una compatibilidad integrada para el balanceo de carga. Necesitas suministrar tus propios balanceadores de carga utilizando el estándar de tu empresa.
Dada la naturaleza de máquina única de la instalación, no hay una compatibilidad integrada para el balanceo de carga. Necesitas suministrar tus propios balanceadores de carga utilizando el estándar de tu empresa
El módulo Terraform suministra un NLB para apuntar a las instancias. La dirección DNS se devuelve en el resultado lb-dns en Terraform.
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 como /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. Como alternativa, también se pueden utilizar las unidades gp3.
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 éste tiene 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.
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 Terraform, el resultado lb-dns proporciona el valor necesario.
En este punto, tus datos de observabilidad deberían ir al worker y luego ser enviados a tu archivo S3.
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.
Rehidratación de tus archivos
Consulta Rehidratación de archivos para obtener instrucciones sobre cómo rehidratar tus archivos en Datadog para poder empezar a analizar e investigar esos logs.
Lectura adicional
Más enlaces, artículos y documentación útiles:
