Share via

Installez l’agent d’ingestion Azure Operator Insights et configurez-le pour charger des données

  • Article

Lorsque vous suivez cet article, vous configurez un agent d’ingestion Azure Operator Insights sur une machine virtuelle de votre réseau et le configurez pour qu’il charge des données dans un produit de données. Cet agent d’ingestion prend en charge le chargement :

  • Fichiers stockés sur un serveur SFTP.
  • Flux de données Mobile Content Cloud (MCC) Event Data Record (EDR) d’Affirmed.

Pour obtenir une vue d’ensemble des agents d’ingestion, consultez la section Vue d’ensemble de l’agent d’ingestion.

Prérequis

À partir de la documentation de votre produit de données, obtenez :

  • Les spécifications de la machine virtuelle sur laquelle vous envisagez d’installer l’agent de machine virtuelle.
  • L’exemple de configuration pour l’agent d’ingestion.

Suggestions relatives à la sécurité de la machine virtuelle

La machine virtuelle utilisée pour l’agent d’ingestion doit être configurée en suivant les meilleures pratiques relatives à la sécurité. Nous vous recommandons les actions suivantes :

Mise en réseau

Lors de l’utilisation d’une machine virtuelle Azure :

  • Attribuez une adresse IP privée à la machine virtuelle.
  • Configurez un groupe de sécurité réseau (NSG) pour autoriser uniquement le trafic réseau sur les ports requis pour exécuter l’agent et assurer la maintenance de la machine virtuelle.
  • Au-delà de cela, la configuration réseau dépend de la configuration ou non d’un accès restreint au produit de données (l’utilisation ou non de points de terminaison de service pour accéder au compte de stockage d’entrée du produit de données). Certaines configurations réseau peuvent entraîner des coûts supplémentaires, tels qu’un réseau virtuel Azure entre la machine virtuelle et le compte de stockage d’entrée du produit de données.

Lors de l’utilisation d’une machine virtuelle locale :

  • Configurez un pare-feu pour autoriser uniquement le trafic réseau sur les ports requis pour exécuter l’agent et assurer la maintenance de la machine virtuelle.

Chiffrement de disque

Vérifiez que le chiffrement de disque Azure est activé (il s’agit de la valeur par défaut lorsque vous créez la machine virtuelle).

Version du système d’exploitation

  • Gardez la version du système d’exploitation à jour pour éviter les vulnérabilités connues.
  • Configurez la machine virtuelle pour qu’un contrôle périodique des mises à jour système manquantes soit effectué.

Access

Limitez l’accès à la machine virtuelle à un ensemble minimal d’utilisateurs. Configurez la journalisation d’audit sur la machine virtuelle (par exemple, à l’aide du package d’audit Linux) pour enregistrer les tentatives de connexion et les actions effectuées par les utilisateurs connectés.

Nous vous recommandons de restreindre les types d’accès suivants.

  • L’accès administrateur à la machine virtuelle (par exemple, pour arrêter/démarrer/installer l’agent d’ingestion).
  • L’accès au répertoire dans lequel les journaux sont stockés : /var/log/az-aoi-ingestion/.
  • L’accès à l’identité managée ou au certificat et à la clé privée pour le principal de service que vous créez pendant cette procédure.
  • L’accès au répertoire des secrets que vous créez sur la machine virtuelle pendant cette procédure

Microsoft Defender for Cloud

Lors de l’utilisation d’une machine virtuelle Azure, suivez également toutes les recommandations de Microsoft Defender pour le cloud. Vous trouverez ces recommandations dans le portail en accédant à la machine virtuelle, puis en sélectionnant Sécurité.

Configurer l’authentification auprès d’Azure

L’agent d’ingestion doit être en mesure de s’authentifier auprès du Azure Key Vault créé par le produit de données pour récupérer les informations d’identification de stockage. La méthode d’authentification peut être :

  • Principal de service avec les informations d’identification du certificat. Si l’agent d’ingestion s’exécute en dehors d’Azure, par exemple dans un réseau local, vous devez utiliser cette méthode.
  • Identité managée. Si l’agent d’ingestion s’exécute sur une machine virtuelle Azure, nous vous recommandons cette méthode. Elle ne nécessite pas de gestion des informations d’identification (contrairement à un principal de service).

Important

Il se peut que vous deviez demander à un administrateur client Microsoft Entra de votre organisation d’effectuer cette configuration.

Utiliser une identité managée pour l’authentification

Si l’agent d’ingestion s’exécute dans Azure, nous vous recommandons d’utiliser des identités managées. Pour plus d’informations, consultez la vue d’ensemble des identités managées.

Remarque

Les agents d’ingestion sur les machines virtuelles Azure prennent en charge les identités managées affectées par le système comme celles affectées par l’utilisateur. Pour plusieurs agents, une identité managée affectée par l’utilisateur est plus simple, car vous pouvez autoriser l’identité auprès du Key Vault de produit de données pour toutes les machines virtuelles exécutant l’agent.

  1. Créez ou obtenez une identité managée affectée par l’utilisateur en suivant les instructions fournies dans Gérer les identités managées affectées par l’utilisateur. Si vous avez l’intention d’utiliser une identité managée affectée par le système, ne créez pas d’identité managée affectée par l’utilisateur.
  2. Suivez les instructions de configuration des identités managées pour les ressources Azure sur une machine virtuelle à l’aide du Portail Azure en fonction du type d’identité managée utilisé.
  3. Notez l’ID d’objet de l’identité managée. L’ID d’objet est un UUID qui se présente sous la forme xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, où chaque caractère est un chiffre hexadécimal.

Vous pouvez maintenant accorder des autorisations pour le Key Vault de produit de données.

Créer un principal de service pour l’authentification

Si l’agent d’ingestion s’exécute en dehors d’Azure, tel qu’un réseau local, vous ne pouvez pas utiliser d’identités managées et devez plutôt vous authentifier auprès du Key Vault de produit de données à l’aide d’un principal de service avec des informations d’identification de certificat. Chaque agent doit également avoir une copie du certificat stocké sur la machine virtuelle.

Créer un principal du service

  1. Créez ou obtenez un principal de service Microsoft Entra ID. Suivez les instructions fournies dans l’article Créer une application et un principal de service Microsoft Entra dans le portail. Laissez le champ URI de redirection vide.
  2. Notez l’identifiant d’application (client) et votre identifiant d’annuaire Microsoft Entra (locataire) (ces identifiants sont des UUID au format xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, où chaque caractère est un chiffre hexadécimal).

Préparer des certificats pour le principal de service

L’agent d’ingestion prend uniquement en charge les informations d’identification de certificat pour les principaux de service. Vous décidez si vous souhaitez utiliser le même certificat et la même clé pour les machines virtuelles ou un certificat et une clé uniques pour chacune d’elles. L’utilisation d’un certificat par machine virtuelle offre une meilleure sécurité et a un impact plus faible en cas de divulgation d’une clé ou d’expiration du certificat. Toutefois, cette méthode est assortie d’une maintenabilité et d’une complexité opérationnelle plus élevées.

  1. Obtenez un ou plusieurs certificats. Nous vous recommandons vivement d’utiliser des certificats approuvés d’une autorité de certification. Les certificats peuvent être générés à partir de Azure Key Vault : consultez Définir et récupérer un certificat à partir de Key Vault à l’aide du Portail Azure. Vous pouvez ainsi configurer des alertes d’expiration et avoir le temps de régénérer de nouveaux certificats et de les appliquer à vos agents d’ingestion avant leur expiration. Une fois qu’un certificat expire, l’agent ne peut pas s’authentifier auprès d’Azure et ne charge plus de données. Pour plus d’informations sur cette approche, consultez l’article Renouveler des certificats Azure Key Vault. Si vous choisissez d’utiliser Azure Key Vault, procédez comme suit :
    • Ce Azure Key Vault doit être une instance différente du Key Vault de produit de données, soit un de ceux que vous contrôlez déjà, soit un nouveau.
    • Vous avez besoin du rôle « Agent des certificats Key Vault » sur cette instance Azure Key Vault pour pouvoir ajouter le certificat à Key Vault. Pour plus d’informations sur l’attribution de rôles dans Azure, consultez l’article Attribuer des rôles Azure à l’aide du Portail Microsoft Azure.
  2. Ajoutez le certificat ou les certificats en tant qu’informations d’identification à votre principal de service en suivant les instructions de la section Créer une application et un principal de service Microsoft Entra dans le portail.
  3. Vérifiez que les certificats sont disponibles au format PKCS#12 (P12), sans phrase secrète qui les protège.
    • Si le certificat est stocké dans un Azure Key Vault, téléchargez le certificat au format PFX. PFX est identique à P12.
    • Sur Linux, vous pouvez convertir un certificat et une clé privée à l’aide d’OpenSSL. Lorsque vous êtes invité à entrer un mot de passe d’exportation, appuyez sur Entrée pour fournir une phrase secrète vide. Vous pouvez ensuite la stocker dans un Azure Key Vault, comme indiqué à l’étape 1.
    openssl pkcs12 -nodes -export -in <certificate.pem> -inkey <key.pem> -out <certificate.p12>

Important

Le fichier P12 ne doit pas être protégé par une phrase secrète.

  1. Validez votre fichier P12. Cette opération affiche des informations sur le fichier P12, notamment le certificat et la clé privée.

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

  2. Vérifiez que le fichier P12 est codé en base64. Sur Linux, vous pouvez coder en base64 un certificat au format P12 à l’aide de la commande base64.

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

Accorder des autorisations pour le produit de données Key Vault

  1. Recherchez l’instance Azure Key Vault qui contient les informations d’identification de stockage pour le compte de stockage d’entrée. Azure Key Vault se trouve dans un groupe de ressources nommé <data-product-name>-HostedResources-<unique-id>.
  2. Accordez à votre principal de service le rôle « Utilisateur des secrets Key Vault » sur cette instance Key Vault. Vous avez besoin d’autorisations de niveau Propriétaire sur votre abonnement Azure. Pour plus d’informations sur l’attribution de rôles dans Azure, consultez l’article Attribuer des rôles Azure à l’aide du Portail Microsoft Azure.
  3. Prenez note du nom de l’instance Key Vault.

Préparer le serveur SFTP

Cette section n’est requise que pour la source d’extraction SFTP.

Sur le serveur SFTP :

  1. Vérifiez que le port 22/TCP vers la machine virtuelle est ouvert.
  2. Créez un utilisateur ou déterminez un utilisateur existant sur le serveur SFTP que l’agent d’ingestion devrait utiliser pour se connecter au serveur SFTP.
    • Par défaut, l’agent d’ingestion effectue une recherche dans chaque répertoire sous le chemin d’accès de base. Cet utilisateur doit donc être en mesure de lire tous ces répertoires. Vous devez exclure les répertoires auxquels l’utilisateur n’est pas autorisé à accéder à l’aide de la configuration exclude_pattern.

    Remarque

    Le fait d’exclure implicitement des répertoires en ne les spécifiant pas dans le modèle inclus ne suffit pas à empêcher l’agent de lancer une recherche dans ces répertoires. Pour plus d’informations sur l’exclusion de répertoires, consultez les informations de référence sur la configuration.

  3. Déterminez la méthode d’authentification que l’agent d’ingestion devrait utiliser pour se connecter au serveur SFTP. L’agent prend en charge :
    • Authentification par mot de passe
    • Authentification par clé SSH
  4. Configurez le serveur SFTP pour supprimer les fichiers après une période donnée (période de rétention). Assurez-vous que la période de rétention est suffisamment longue pour que l’agent puisse traiter les fichiers avant que le serveur SFTP ne les supprime. L’exemple de fichier de configuration contient une configuration pour vérifier la présence de nouveaux fichiers toutes les cinq minutes.

Important

Votre serveur SFTP doit supprimer les fichiers après une période de rétention appropriée afin d’éviter une insuffisance d’espace disque. L’agent d’ingestion ne supprime pas les fichiers automatiquement.

Une période de rétention plus courte diminue l’utilisation du disque, augmente la vitesse de l’agent et réduit le risque de chargements en double. Toutefois, elle augmente le risque de perte de données si celles-ci ne peuvent pas être récupérées par l’agent ou chargées dans Azure Operator Insights.

Préparer les machines virtuelles

Répétez les étapes ci-dessous pour chaque machine virtuelle sur laquelle vous souhaitez installer l’agent.

  1. Vérifiez qu’une session SSH est ouverte sur la machine virtuelle et que vous disposez des autorisations sudo.

  2. Installez systemd, logrotate et zip sur la machine virtuelle, s’ils ne sont pas encore présents. Par exemple :

    sudo dnf install systemd logrotate zip

  3. Si vous utilisez un principal de service, copiez le certificat P12 codé en base64 (créé à l’étape Préparer les certificats) sur la machine virtuelle, dans un emplacement accessible à l’agent d’ingestion.

  4. Configurez la machine virtuelle de l’agent en fonction du type de source d’ingestion.

    1. Vérifiez que les ports suivants sont ouverts sur la machine virtuelle. Ces ports doivent être ouverts dans les groupes de sécurité réseau cloud et dans le pare-feu s’exécutant sur la machine virtuelle elle-même (firewalld ou iptables, par exemple).
      • Port 443/TCP sortant vers Azure
      • Port 22/TCP sortant vers le serveur SFTP
    2. Créez un répertoire à utiliser pour stocker les secrets pour l’agent. Nous appelons ce répertoire le répertoire des secrets. Notez son chemin d’accès.
    3. Créez un fichier dans le répertoire des secrets contenant un mot de passe ou une clé SSH privée pour le serveur SFTP.
      • Le fichier ne doit pas avoir d’extension.
      • Choisissez un nom approprié pour ce fichier, puis prenez-en note pour plus tard. Ce nom est référencé dans la configuration de l’agent.
      • Le fichier doit contenir uniquement la valeur du secret (mot de passe ou clé SSH), sans espace blanc supplémentaire.
    4. Si vous utilisez une clé SSH qui a une phrase secrète pour l’authentification, utilisez la même méthode pour créer un fichier distinct qui contient la phrase secrète.
    5. Vérifiez que la clé SSH publique du serveur SFTP est répertoriée dans le fichier known_hosts global de la machine virtuelle situé à l’emplacement /etc/ssh/ssh_known_hosts.

    Conseil

    Utilisez la commande Linux ssh-keyscan pour ajouter manuellement la clé publique SSH d’un serveur au fichier known_hosts d’une machine virtuelle. Par exemple : ssh-keyscan -H <server-ip> | sudo tee -a /etc/ssh/ssh_known_hosts.

Vérifier que la machine virtuelle peut résoudre les noms d’hôte Microsoft

Vérifiez que la machine virtuelle peut résoudre les noms d’hôte publics en adresses IP. Par exemple, ouvrez une session SSH et utilisez dig login.microsoftonline.com pour vérifier que la machine virtuelle peut résoudre login.microsoftonline.com en adresse IP.

Si la machine virtuelle ne peut pas utiliser DNS pour résoudre les noms d’hôte Microsoft publics en adresses IP, mappez les noms d’hôte requis en adresses IP. Revenez à cette procédure lorsque vous avez terminé la configuration.

Installer le logiciel de l’agent

Le package logiciel de l’agent est hébergé sur le « référentiel de logiciels Linux pour les produits Microsoft » à l’adresse https://packages.microsoft.com.

Le nom du package de l’agent d’ingestion est az-aoi-ingestion.

Pour télécharger et installer un package à partir du référentiel de logiciels, effectuez les étapes appropriées pour la distribution Linux de votre machine virtuelle dans Comment installer des packages logiciels Microsoft à l’aide du référentiel Linux.

Par exemple, si vous effectuez l’installation sur une machine virtuelle exécutant Red Hat Enterprise Linux (RHEL) 8, suivez les instructions sous le titre Distributions Linux basées sur Red Hat, en remplaçant les paramètres suivants :

  • distribution : rhel
  • version : 8
  • package-name : az-aoi-ingestion

Configurer le logiciel de l’agent

La configuration dont vous avez besoin est spécifique au type de source et à votre produit de données. Vérifiez que vous avez accès à la documentation de votre produit de données pour afficher les valeurs requises. Par exemple :

  1. Connectez-vous à la machine virtuelle via SSH.

  2. Accédez au répertoire de configuration.

    cd /etc/az-aoi-ingestion

  3. Effectuez une copie du fichier de configuration par défaut.

    sudo cp example_config.yaml config.yaml

  4. Définissez le champ agent_id sur un identificateur unique pour l’instance de l’agent, par exemple london-sftp-1. Ce nom devient une métadonnée pouvant faire l’objet d’une recherche dans Operator Insights pour toutes les données ingérées par cet agent. Les caractères d’URL réservés doivent être codés avec des signes de pourcentage.

  5. Configurez la section secret_providers.

    Les sources SFTP nécessitent deux types de fournisseurs de secrets.

    • Un fournisseur de secrets de type key_vault, qui contient les détails nécessaires pour se connecter à Azure Key Vault du produit de données et autoriser la connexion au compte de stockage d’entrée du produit de données.
    • Un fournisseur secret de type file_system, qui indique un répertoire sur la machine virtuelle pour stocker les informations d’identification pour la connexion à un serveur SFTP.
    1. Pour le fournisseur de secrets avec le type key_vault et le nom data_product_keyvault, définissez les champs suivants.
    2. Pour le fournisseur de secrets avec le type file_system et le nom local_file_system, définissez les champs suivants.
      • secrets_directory sur le chemin d'accès complet au répertoire des secrets sur la machine virtuelle de l’agent, qui a été créé à l’étape Préparer les machines virtuelles.

    Vous pouvez ajouter d’autres fournisseurs de secrets (par exemple, si vous souhaitez charger sur plusieurs produits de données) ou modifier les noms des fournisseurs de secrets par défaut.

  6. Configurez la section pipelines à l’aide de l’exemple de configuration et de la documentation de votre produit de données. Chaque pipeline comporte trois sections de configuration.

    • id. L’ID identifie le pipeline et ne doit pas être identique à tout autre ID de pipeline pour cet agent d’ingestion. Tous les caractères réservés d’URL doivent être codés avec des signes de pourcentage. Consultez la documentation de votre produit de données pour obtenir des recommandations.

    • source. La configuration source contrôle les fichiers ingérés. Vous pouvez configurer plusieurs sources.

      Supprimez tous les pipelines de l’exemple, à l’exception de l’exemple contoso-logs, qui contient la configuration source sftp_pull.

      Mettez à jour l’exemple pour répondre à vos besoins. Les champs suivants sont obligatoires pour chaque source.

      • host : le nom d’hôte ou l’adresse IP du serveur SFTP.
      • filtering.base_path : le chemin d’accès à un dossier sur le serveur SFTP à partir duquel les fichiers sont chargés vers Azure Operator Insights.
      • known_hosts_file : chemin d’accès de la machine virtuelle au fichier known_hosts global, situé à l’emplacement /etc/ssh/ssh_known_hosts. Ce fichier doit contenir les clés SSH publiques du serveur hôte SFTP, comme indiqué à la section Préparer les machines virtuelles.
      • user : le nom de l’utilisateur sur le serveur SFTP que l’agent doit utiliser pour se connecter.
      • Selon la méthode d’authentification que vous avez choisie dans Préparer les machines virtuelles, définissez soit password, soit private_key.
        • Pour l’authentification par mot de passe, définissez secret_name sur le nom du fichier contenant le mot de passe dans le dossier secrets_directory.
        • Pour l’authentification par clé SSH, définissez key_secret_name sur le nom du fichier contenant la clé SSH dans le dossier secrets_directory. Si la clé privée est protégée par une phrase secrète, définissez passphrase_secret_name sur le nom du fichier contenant la phrase secrète dans le dossier secrets_directory.
        • Tous les fichiers secrets doivent disposer d’autorisations 600 (rw-------) et d’un propriétaire az-aoi-ingestion afin que seuls l’agent d’ingestion et les utilisateurs privilégiés puissent les lire.
        sudo chmod 600 <secrets_directory>/*
sudo chown az-aoi-ingestion <secrets_directory>/*

      Pour connaître les valeurs requises ou recommandées pour d’autres champs, consultez la documentation de votre produit de données.

      Conseil

      L’agent prend en charge une configuration facultative supplémentaire pour les points suivants :

      • Spécification d’un modèle de fichiers dans le dossier base_path qui seront chargés (par défaut, tous les fichiers du dossier sont chargés).
      • Spécification d’un modèle de fichiers dans le dossier base_path qui ne doivent pas être chargés.
      • Heure et date avant lesquelles les fichiers du dossier base_path ne sont pas chargés.
      • Fréquence à laquelle l’agent d’ingestion charge les fichiers (la valeur fournie dans l’exemple de fichier de configuration correspond à toutes les heures).
      • Temps de stabilisation, qui correspond à une période après la dernière modification d’un fichier pendant laquelle l’agent attend avant son chargement (la valeur fournie dans l’exemple de fichier de configuration est de 5 minutes).

      Pour plus d’informations sur ces options de configuration, consultez la section Référence de configuration pour l’agent d’ingestion Azure Operator Insights.

    • sink. La configuration du récepteur contrôle le chargement des données dans le compte de stockage d’entrée du produit de données.

      • Dans la section sas_token, définissez secret_provider sur le fournisseur de secrets key_vault approprié pour le produit de données, ou utilisez data_product_keyvault par défaut si vous avez utilisé le nom par défaut précédemment. Laissez secret_name inchangé.
      • Consultez la documentation de votre produit de données pour plus d’informations sur les valeurs requises pour d’autres paramètres.

        Important

        Le champ container_name doit être défini exactement comme indiqué par la documentation de votre produit de données.

Démarrer le logiciel de l’agent

  1. Démarrez l’agent. 
    sudo systemctl start az-aoi-ingestion
  2. Vérifiez que l’agent est en cours d’exécution. 
    sudo systemctl status az-aoi-ingestion
    1. Si l’état affiché n’est pas active (running), consultez les journaux comme décrit dans la section Surveiller et dépanner les agents d’ingestion pour Azure Operator Insights pour comprendre l’erreur. Il est probable que certaines options de configuration sont incorrectes.
    2. Une fois le problème résolu, essayez de redémarrer l’agent.
    3. Si le problème persiste, créez un ticket de support.
  3. Une fois l’agent en cours d’exécution, vérifiez qu’il démarre automatiquement après les redémarrages. 
    sudo systemctl enable az-aoi-ingestion.service

[Facultatif] Configurer la collecte de journaux pour l’accès via Azure Monitor

Si vous exécutez l’agent d’ingestion sur une machine virtuelle Azure ou sur une machine virtuelle locale connectée par Azure Arc, vous pouvez envoyer les journaux d’activité de l’agent d’ingestion à Azure Monitor à l’aide de l’agent Azure Monitor. L’utilisation d’Azure Monitor pour accéder aux journaux peut être plus simple que d’accéder directement aux journaux d’activité sur la machine virtuelle.

Pour collecter les journaux d’activité de l’agent d’ingestion, suivez la documentation Azure Monitor pour installer l’Agent Azure Monitor et configurer la collecte des journaux d’activité.

  • Ces documents utilisent le module Az PowerShell pour créer une table de journaux d’activité. Suivez d’abord la documentation d’installation du module Az PowerShell.
    • La section YourOptionalColumn de l’exemple JSON $tableParams n’est pas nécessaire pour l’agent d’ingestion et peut être supprimée.
  • Lors de l’ajout d’une source de données à votre règle de collecte de données, ajoutez un type de source Custom Text Logs, avec le modèle de fichier /var/log/az-aoi-ingestion/stdout.log.
  • Nous vous recommandons également de suivre la documentation pour ajouter une source de données Linux Syslog à votre règle de collecte de données afin d’autoriser l’audit de tous les processus s’exécutant sur la machine virtuelle.
  • Après avoir ajouté la règle de collecte de données, vous pouvez interroger les journaux de l’agent d’ingestion via l’espace de travail Log Analytics. Utilisez la requête suivante pour faciliter leur utilisation avec : 
    <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

    Remarque

    Cette requête ne peut pas être utilisée comme transformation de source de données, car replace_regex n’est pas disponible dans les transformations de source de données.

Exemples de journaux d’activité

[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

Contenu connexe

Découvrez comment :