Compartir a través de

Instalación del agente de ingesta de Azure Operator Insights y configuración para cargar datos

  • Artículo

Al seguir este artículo, configurará un agente de ingesta de Azure Operator Insights en una máquina virtual (VM) de la red y lo configurará para cargar datos en un producto de datos. Este agente de ingesta admite la carga:

  • Archivos almacenados en un servidor SFTP.
  • Se han confirmado flujos de datos de registro de datos de eventos (EDR) de Mobile Content Cloud (MCC).

Para obtener información general sobre los agentes de ingesta, consulte Introducción al agente de ingesta.

Requisitos previos

En la documentación del producto de datos, obtenga:

  • Especificaciones de la máquina virtual en la que planea instalar el agente de máquina virtual.
  • Configuración de ejemplo para el agente de ingesta.

Recomendaciones de seguridad para máquinas virtuales

La máquina virtual utilizada para el agente de ingestión debe configurarse siguiendo las mejores prácticas de seguridad. Se recomiendan las siguientes acciones:

Redes

Al usar una máquina virtual de Azure:

  • Asigne a la máquina virtual una dirección IP privada.
  • Configure un grupo de seguridad de red (NSG) para permitir solo el tráfico de red en los puertos necesarios para ejecutar el agente y mantener la máquina virtual.
  • Además de esto, la configuración de red depende de si el acceso restringido está configurado en el producto de datos (si usa puntos de conexión de servicio para acceder a la cuenta de almacenamiento de entrada del producto de datos). Algunas configuraciones de red pueden suponer un coste adicional, como una red virtual de Azure entre la máquina virtual y la cuenta de almacenamiento de entrada del producto de datos.

Al usar una máquina virtual local:

  • Configure un firewall para permitir solo el tráfico de red en los puertos necesarios para ejecutar el agente y mantener la máquina virtual.

Cifrado de discos

Asegúrese de que Azure Disk Encryption está habilitado (este es el valor predeterminado al crear la máquina virtual).

Versión del SO

  • Mantenga actualizada la versión del sistema operativo para evitar vulnerabilidades conocidas.
  • Configure la máquina virtual para comprobar periódicamente si faltan actualizaciones del sistema.

Access

Limite el acceso a la máquina virtual a un conjunto mínimo de usuarios. Configure el registro de auditoría en la máquina virtual (por ejemplo, mediante el paquete de auditoría de Linux) para registrar los intentos de inicio de sesión y las acciones realizadas por los usuarios que han iniciado sesión.

Se recomienda restringir los siguientes tipos de acceso.

  • Acceso de administrador a la máquina virtual (por ejemplo, para detener/iniciar/instalar el agente de ingestión).
  • Acceso al directorio donde se almacenan los registros: /var/log/az-aoi-ingestion/.
  • Acceso a la identidad administrada o al certificado y a la clave privada de la entidad de servicio que se crea durante este procedimiento.
  • Acceso al directorio para los secretos que cree en la máquina virtual durante este procedimiento.

Microsoft Defender for Cloud

Al usar una máquina virtual de Azure, siga también todas las recomendaciones de Microsoft Defender for Cloud. Para encontrar estas recomendaciones en el portal, vaya a la máquina virtual y, después, seleccione Seguridad.

Configuración de la autenticación en Azure

El agente de ingesta debe poder autenticarse con la instancia de Azure Key Vault creada por el producto de datos para recuperar las credenciales de almacenamiento. El método de autenticación puede ser:

  • Entidad de servicio con credencial de certificado. Si el agente de ingesta se ejecuta fuera de Azure, como en una red local, debe usar este método.
  • Identidad administrada. Si el agente de ingesta se ejecuta en una máquina virtual de Azure, se recomienda este método. No requiere controlar ninguna credencial (a diferencia de las entidades de servicio).

Importante

Es posible que necesite un administrador de inquilinos de Microsoft Entra en su organización para realizar esta configuración.

Uso de una identidad administrada para la autenticación

Si el agente de ingesta se ejecuta en Azure, se recomiendan las identidades administradas. Para obtener información más detallada, consulte la información general sobre las identidades administradas.

Nota:

Los agentes de ingesta en máquinas virtuales de Azure admiten identidades administradas asignadas por el sistema y asignadas por el usuario. Para varios agentes, una identidad administrada asignada por el usuario es más sencilla porque puede autorizar la identidad al almacén de claves de producto de datos para todas las máquinas virtuales que ejecutan el agente.

  1. Cree o obtenga una identidad administrada asignada por el usuario siguiendo las instrucciones de Administrar identidades administradas asignadas por el usuario. Si tiene previsto usar una identidad administrada asignada por el sistema, no cree ninguna identidad administrada asignada por el usuario.
  2. Siga las instrucciones de Configuración de identidades administradas para recursos de Azure en una máquina virtual mediante Azure Portal según el tipo de identidad administrada que se usa.
  3. Anote el identificador de objeto de la identidad administrada. El id. de objeto es un UUID del formato xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, donde cada carácter es un dígito hexadecimal.

Ahora puede conceder permisos para Data Product Key Vault.

Uso de una entidad de servicio para la autenticación

Si el agente de ingesta se ejecuta fuera de Azure, como una red local, no puede usar identidades administradas y debe autenticarse en Data Product Key Vault mediante una entidad de servicio con una credencial de certificado. Cada agente también debe tener una copia del certificado almacenado en la máquina virtual.

Creación de una entidad de servicio

  1. Cree u obtenga una entidad de servicio de Microsoft Entra ID. Siga las instrucciones que se detallan en Creación de una aplicación de Microsoft Entra y una entidad de servicio en el portal. Deje el campo URI de redirección vacío.
  2. Anote el identificador de aplicación (cliente) y el identificador de Microsoft Entra Directory (inquilino) (estos identificadores son UUID del formato xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, donde cada carácter es un dígito hexadecimal).

Preparación de certificados para la entidad de servicio

El agente de ingesta solo admite credenciales de certificado para las entidades de servicio. Es importante saber si usa el mismo certificado y clave para cada máquina virtual, o si usa un certificado y una clave únicos para cada una. El uso de un certificado por máquina virtual proporciona una mayor seguridad y tiene un impacto menor si se filtra una clave o expira el certificado. Sin embargo, este método agrega una mayor capacidad de mantenimiento y complejidad operativa.

  1. Obtenga uno o varios certificados. Se recomienda encarecidamente usar certificados de confianza de una entidad de certificación. Los certificados se pueden generar desde Azure Key Vault: consulte Establecimiento y recuperación de un certificado de Key Vault mediante Azure Portal. Al hacerlo, podrá configurar las alertas de expiración y le dará tiempo para volver a generar nuevos certificados y aplicarlos a los agentes de ingesta antes de que expiren. Una vez que expira un certificado, el agente no puede autenticarse en Azure y ya no carga datos. Para más información sobre este enfoque, consulte Renovación de los certificadosde Azure Key Vault. Si decide usar Azure Key Vault, haga lo siguiente:
    • Esta instancia de Azure Key Vault debe ser una instancia diferente de Data Product Key Vault, ya sea una que ya controle o una nueva.
    • Necesita el rol "Oficial de certificados de Key Vault" en Azure Key Vault para agregar el certificado a Key Vault. Para más información sobre la asignación de roles en Azure, consulte Asignación de roles de Azure mediante Azure Portal.
  2. Agregue los certificados como credenciales a la entidad de servicio, con base en Crear una aplicación y una entidad de servicio de Microsoft Entra en el portal.
  3. Asegúrese de que los certificados están disponibles en formato PKCS#12 (P12), sin frase de contraseña que las proteja.
    • Si el certificado se almacena en una instancia de Azure Key Vault, descargue el certificado en formato PFX. PFX es idéntico a P12.
    • En Linux, puede convertir un certificado y una clave privada mediante OpenSSL. Cuando se le solicite una contraseña de exportación, presione Entrar para proporcionar una frase de contraseña vacía. Después, se puede almacenar en una instancia de Azure Key Vault, como se describe en el paso 1.
    openssl pkcs12 -nodes -export -in <certificate.pem> -inkey <key.pem> -out <certificate.p12>

Importante

El archivo P12 no debe protegerse con una frase de contraseña.

  1. Valide el archivo P12. Esto muestra información sobre el archivo P12, incluido el certificado y la clave privada.

    openssl pkcs12 -nodes -in <certificate.p12> -info

  2. Asegúrese de que el archivo P12 está codificado en base64. En Linux, puede codificar en base64 un certificado P12 mediante el comando base64.

    base64 -w 0 <certificate.p12> > <base64-encoded-certificate.p12>

Concesión de permisos para Data Product Key Vault

  1. Busque la instancia de Azure Key Vault que contiene las credenciales de almacenamiento de la cuenta de almacenamiento de entrada. Este almacén de claves se encuentra en un grupo de recursos denominado <data-product-name>-HostedResources-<unique-id>.
  2. Conceda a la entidad de servicio el rol "Usuario de secretos de Key Vault" en este almacén de claves. Necesita permisos de nivel de propietario en la suscripción de Azure. Para más información sobre la asignación de roles en Azure, consulte Asignación de roles de Azure mediante Azure Portal.
  3. Establece el nombre del almacén de claves.

Preparar el servidor SFTP

Esta sección solo es necesaria para el origen de extracción de SFTP.

En el servidor SFTP:

  1. Asegúrese de que el puerto 22/TCP a la máquina virtual esté abierto.
  2. Cree un nuevo usuario o determine un usuario existente en el servidor SFTP, que usará el agente de ingesta para conectarse al servidor SFTP.
    • De forma predeterminada, el agente de ingesta busca en todos los directorios de la ruta de acceso base, por lo que este usuario debe poder leer todos ellos. Los directorios a los que el usuario no tiene permiso de acceso deben excluirse mediante la configuración exclude_pattern.

    Nota:

    Excluir implícitamente los directorios sin especificarlos en el patrón incluido no es suficiente para detener la búsqueda del agente en esos directorios. Vea la referencia de configuración para obtener más información sobre la exclusión de directorios.

  3. Determine el método de autenticación que usará el agente de ingesta para conectarse al servidor SFTP. El agente admite:
    • Autenticación de contraseña
    • Autenticación de clave SSH
  4. Configure el servidor SFTP para quitar archivos después de un período de tiempo (un período de retención). Asegúrese de que el periodo de retención es lo suficientemente largo como para que el agente procese los archivos antes de que el servidor SFTP los elimine. El archivo de configuración de ejemplo contiene la configuración para comprobar si hay nuevos archivos cada cinco minutos.

Importante

El servidor SFTP debe quitar archivos después de un período de retención adecuado para que no se quede sin espacio en disco. El agente de ingestión no elimina los archivos automáticamente.

Un tiempo de retención más corto reduce el uso del disco, aumenta la velocidad del agente y reduce el riesgo de cargas duplicadas. Sin embargo, un período de retención más corto aumenta el riesgo de que los datos se pierdan si el agente no puede recuperarlos o cargarlos en Azure Operator Insights.

Preparación de las máquinas virtuales

Repita estos pasos para cada máquina virtual en la que desee instalar el agente.

  1. Asegúrese de que tiene una sesión SSH abierta a la máquina virtual y de que tiene sudo permisos.

  2. Instale systemd, logrotate y zip en la máquina virtual, si no están ya presentes. Por ejemplo:

    sudo dnf install systemd logrotate zip

  3. Si usa una entidad de servicio, copie el certificado P12 codificado en base64 (creado en el paso Preparar certificados) en la máquina virtual, en una ubicación accesible para el agente de ingesta.

  4. Configure la máquina virtual del agente en función del tipo de origen de ingesta.

    1. Compruebe que la máquina virtual tenga abiertos los puertos siguientes. Estos puertos deben estar abiertos en grupos de seguridad de red en la nube y en cualquier firewall que se ejecute en la propia máquina virtual (como firewalld o iptables).
      • Puerto 443/TCP saliente a Azure
      • Puerto 22/TCP saliente al servidor SFTP
    2. Cree un directorio que se usará para almacenar secretos para el agente. Llamamos a este directorio el directoriosecretos. Anote su ruta de acceso.
    3. Cree un archivo en el directorio de secretos que contenga la contraseña o la clave SSH privada para el servidor SFTP.
      • El archivo no debe tener una extensión de archivo.
      • Elija un nombre apropiado para este archivo y anótelo para más adelante. Se hace referencia a este nombre en la configuración del agente.
      • El archivo debe contener únicamente el valor secreto (contraseña o clave SSH), sin espacios en blanco adicionales.
    4. Si está utilizando una clave SSH que tiene una frase de contraseña para autenticarse, utilice el mismo método para crear un archivo separado que contenga la frase de contraseña.
    5. Asegúrese de que la clave SSH pública del servidor SFTP aparece en el archivo global known_hosts de la máquina virtual, ubicado en /etc/ssh/ssh_known_hosts.

    Sugerencia

    Utilice el comando Linux ssh-keyscan para añadir manualmente la clave pública SSH de un servidor al archivo known_hosts de una máquina virtual. Por ejemplo, ssh-keyscan -H <server-ip> | sudo tee -a /etc/ssh/ssh_known_hosts.

Asegúrese de que la máquina virtual puede resolver los nombres de host de Microsoft

Compruebe que la máquina virtual puede resolver nombres de host públicos en direcciones IP. Por ejemplo, abra una sesión SSH y use dig login.microsoftonline.com para comprobar que la máquina virtual puede resolverse login.microsoftonline.com en una dirección IP.

Si la máquina virtual no puede usar DNS para resolver nombres de host públicos de Microsoft en direcciones IP, asigne los nombres de host necesarios a direccionesIP. Vuelva a este procedimiento cuando haya terminado la configuración.

Instalación del software del agente

El paquete de software de agente se hospeda en el "repositorio de software de Linux para productos de Microsoft" en https://packages.microsoft.com

El nombre del paquete de agente de ingesta es az-aoi-ingestion.

Para descargar e instalar un paquete desde el repositorio de software, siga los pasos pertinentes para la distribución de Linux de la máquina virtual en Procedimiento para instalar paquetes de software de Microsoft mediante el repositorio de Linux.

Por ejemplo, si va a instalar en una máquina virtual que ejecuta Red Hat Enterprise Linux (RHEL) 8, siga las instrucciones que se indican en el encabezado distribuciones de Linux basadas en Red Hat, sustituyendo los parámetros siguientes:

  • distribución: rhel
  • versión: 8
  • nombre-paquete: az-aoi-ingestion

Configuración del software del agente

La configuración que necesita es específica del tipo de origen y del producto de datos. Asegúrese de que tiene acceso a la documentación del producto de datos para ver los valores necesarios. Por ejemplo:

  1. Conéctese a la máquina virtual a través de SSH.

  2. Cambie al directorio de configuración.

    cd /etc/az-aoi-ingestion

  3. Realice una copia del archivo de configuración predeterminado.

    sudo cp example_config.yaml config.yaml

  4. Establezca el agent_id campo en un identificador único para la instancia del agente; por ejemplo london-sftp-1. Este nombre se convierte en metadatos que se pueden buscar en Operator Insights para todos los datos ingeridos por este agente. Los caracteres reservados de direcciones URL deben estar codificados por porcentaje.

  5. Configure la secret_providers sección.

    Los orígenes SFTP requieren dos tipos de proveedores de secretos.

    • Proveedor de secretos de tipo key_vault, que contiene los detalles necesarios para conectarse a Azure Key Vault del producto de datos y permitir la conexión a la cuenta de almacenamiento de entrada del producto de datos.
    • Proveedor secreto de tipo file_system, que especifica un directorio en la máquina virtual para almacenar credenciales para conectarse a un servidor SFTP.
    1. Para el proveedor secreto con tipo key_vault y con nombre data_product_keyvault, establezca los siguientes campos.
    2. Para el proveedor secreto con tipo file_system y con nombre local_file_system, establezca los siguientes campos.

    Puede agregar más proveedores de secretos (por ejemplo, si desea cargar en varios productos de datos) o cambiar los nombres de los proveedores de secretos predeterminados.

  6. Configure la pipelines sección con la configuración de ejemplo y la documentación del producto de datos. Cada pipeline una tiene tres secciones de configuración.

    • id. El identificador identifica la canalización y no debe ser el mismo que cualquier otro identificador de canalización para este agente de ingesta. Cualquier carácter reservado de la URL debe estar codificado en porcentaje. Consulte la documentación del producto de datos para ver las recomendaciones.

    • source. La configuración de la fuente controla qué archivos se ingieren. Puede configurar varios orígenes.

      Elimine todas las canalizaciones del ejemplo, excepto el contoso-logs ejemplo, que contiene sftp_pull la configuración de origen.

      Actualice el ejemplo para cumplir sus requisitos. Los campos siguientes son obligatorios para cada origen.

      • host: el nombre de host o la dirección IP del servidor SFTP.
      • filtering.base_path: la ruta a una carpeta del servidor SFTP desde la que se cargarán los archivos a Azure Operator Insights.
      • known_hosts_file: la ruta en la máquina virtual al archivo global known_hosts, situado en /etc/ssh/ssh_known_hosts. Este archivo debe contener las claves SSH públicas del servidor host SFTP como se describe en Preparar las máquinas virtuales.
      • user: el nombre del usuario en el servidor SFTP que el agente debe utilizar para conectarse.
      • En función del método de autenticación elegido en Preparar las máquinas virtuales, establezca password o private_key.
        • Para la autenticación de contraseñas, establezca secret_name en el nombre del archivo que contiene la contraseña en la secrets_directory carpeta.
        • Para la autenticación de clave SSH, establezca key_secret_name en el nombre del archivo que contiene la clave SSH en la secrets_directory carpeta. Si la clave privada está protegida con una frase de contraseña, establezca passphrase_secret_name en el nombre del archivo que contiene la frase de contraseña en la carpeta secrets_directory.
        • Todos los archivos secretos deben tener permisos de 600 (rw-------) y un propietario de az-aoi-ingestion para que solo el agente de ingesta y los usuarios con privilegios puedan leerlos.
        sudo chmod 600 <secrets_directory>/*
sudo chown az-aoi-ingestion <secrets_directory>/*

      Para conocer los valores obligatorios o recomendados para otros campos, consulte la documentación del producto de datos.

      Sugerencia

      El agente admite una configuración opcional adicional para lo siguiente:

      • Especificar un patrón de archivos en la carpeta base_path que se cargará más adelante (de forma predeterminada, se cargan todos los archivos de la carpeta).
      • Especificar un patrón de archivos en la carpeta base_path, que no se debe cargar.
      • Una fecha y hora antes de la que no se cargarán los archivos de la carpeta base_path.
      • Frecuencia con la que el agente de SFTP carga archivos (el valor proporcionado en el archivo de configuración de ejemplo corresponde a cada hora).
      • Un tiempo de liquidación, que es un período de tiempo después de que se modifica por última vez un archivo, que el agente esperará antes de cargarlo (el valor proporcionado en el archivo de configuración de ejemplo es de 5 minutos).

      Para más información sobre estas opciones de configuración, consulte Referencia de configuración para el agente de ingestión Azure Operator Insights.

    • sink. La configuración del receptor controla la carga de datos en la cuenta de almacenamiento de entrada del producto de datos.

      • En la sas_token sección, establezca en secret_provider el proveedor de secretos adecuado key_vault para el producto de datos o use el valor predeterminado data_product_keyvault si usó el nombre predeterminado anteriormente. No modifique secret_name.
      • Consulte la documentación del producto de datos para obtener información sobre los valores necesarios para otros parámetros.

        Importante

        El container_name campo debe establecerse exactamente como se especifica en la documentación del producto de datos.

Iniciar el agente de software

  1. Inicie el agente. 
    sudo systemctl start az-aoi-ingestion
  2. Compruebe que el agente está en funcionamiento. 
    sudo systemctl status az-aoi-ingestion
    1. Si ve algún estado distinto de active (running), consulte los registros como se describe en Supervisión y solución de problemas de los agentes de ingestión para Azure Operator Insights para comprender el error. Es probable que alguna configuración sea incorrecta.
    2. Una vez resuelto el problema, intente iniciar el agente de nuevo.
    3. Si los problemas persisten, genere una incidencia de soporte técnico.
  3. Una vez que el agente esté en marcha, asegúrese de que se inicia automáticamente tras el reinicio. 
    sudo systemctl enable az-aoi-ingestion.service

[Opcional] Configuración de la recopilación de registros para el acceso a través de Azure Monitor

Si ejecuta el agente de ingesta en una máquina virtual de Azure o en una máquina virtual local conectada por Azure Arc, puede enviar registros del agente de ingesta a Azure Monitor mediante el agente de Azure Monitor. El uso de Azure Monitor para acceder a los registros puede ser más sencillo que acceder a los registros directamente en la máquina virtual.

Para recopilar registros del agente de ingesta, siga Documentación de Azure Monitor para instalar el agente de Azure Monitor y configurar la recopilación de registros.

  • Estos documentos usan el módulo Az de PowerShell para crear una tabla de registros. Siga la Documentación de instalación del módulo Az PowerShell primero.
    • La sección YourOptionalColumn del ejemplo JSON $tableParams no es necesaria para el agente de ingesta y se puede quitar.
  • Al agregar un origen de datos a la regla de recopilación de datos, agregue un tipo de origen Custom Text Logs, con el patrón de archivo /var/log/az-aoi-ingestion/stdout.log.
  • También se recomienda seguir la documentación para agregar un Linux Syslog Origen de datos a la regla de recopilación de datos, para permitir la auditoría de todos los procesos que se ejecutan en la máquina virtual.
  • Después de agregar la regla de recopilación de datos, puede consultar los registros del agente de ingesta a través del área de trabajo de Log Analytics. Use la consulta siguiente para facilitar su trabajo: 
    <CustomTableName>
| extend RawData = replace_regex(RawData, '\\x1b\\[\\d{1,4}m', '')  // Remove any color tags
| parse RawData with TimeGenerated: datetime '  ' Level ' ' Message  // Parse the log lines into the TimeGenerated, Level and Message columns for easy filtering
| order by TimeGenerated desc

    Nota:

    Esta consulta no se puede usar como una transformación de origen de datos, ya que replace_regex no está disponible en las transformaciones del origen de datos.

Registros de ejemplo

[2m2024-04-30T17:16:00.000544Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Starting run with 'last checkpoint' timestamp: None
[2m2024-04-30T17:16:00.000689Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Starting Completion Handler task
[2m2024-04-30T17:16:00.073495Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::sftp_file_tree_explorer[0m[2m:[0m Start traversing files with base path "/"
[2m2024-04-30T17:16:00.086427Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::sftp_file_tree_explorer[0m[2m:[0m Finished traversing files
[2m2024-04-30T17:16:00.086698Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m File explorer task is complete, with result Ok(())
[2m2024-04-30T17:16:00.086874Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Send files to sink task is complete
[2m2024-04-30T17:16:00.087041Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Processed all completion notifications for run
[2m2024-04-30T17:16:00.087221Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Run complete with no retryable errors - updating last checkpoint timestamp
[2m2024-04-30T17:16:00.087351Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Run lasted 0 minutes and 0 seconds with result: RunStats { successful_uploads: 0, retryable_errors: 0, non_retryable_errors: 0, blob_already_exists: 0 }
[2m2024-04-30T17:16:00.087421Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::file[0m[2m:[0m Closing 1 active SFTP connections
[2m2024-04-30T17:16:00.087966Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_common::scheduler[0m[2m:[0m Run completed successfully. Update the 'last checkpoint' time to 2024-04-30T17:15:30.000543200Z
[2m2024-04-30T17:16:00.088122Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m [2maz_ingestion_common::scheduler[0m[2m:[0m Schedule next run at 2024-04-30T17:17:00Z

Contenido relacionado

Obtenga información sobre cómo: