Condividi tramite

Installare l'agente di inserimento di Azure Operator Insights e configurarlo per caricare i dati

  • Articolo

Quando si segue questo articolo, si configura un agente di inserimento di Azure Operator Insights in una macchina virtuale (VM) nella rete e si configura per caricare i dati in un prodotto dati. Questo agente di inserimento supporta il caricamento:

  • File archiviati in un server SFTP.
  • Flussi di dati EDR (Mobile Content Cloud, Event Data Record) (EDR) affermati.

Per una panoramica degli agenti di inserimento, vedere Panoramica dell'agente di inserimento.

Prerequisiti

Dalla documentazione relativa al prodotto dati ottenere:

  • Specifiche per la macchina virtuale in cui si prevede di installare l'agente di macchine virtuali.
  • Configurazione di esempio per l'agente di inserimento.

Raccomandazioni sulla sicurezza delle macchine virtuali

La macchina virtuale usata per l'agente di inserimento deve essere configurata seguendo le procedure consigliate per la sicurezza. È consigliabile eseguire le azioni seguenti:

Rete

Quando si usa una macchina virtuale di Azure:

  • Assegnare alla macchina virtuale un indirizzo IP privato.
  • Configurare un gruppo di sicurezza di rete (NSG) per consentire solo il traffico di rete sulle porte necessarie per eseguire l'agente e gestire la macchina virtuale.
  • Oltre a questo, la configurazione di rete dipende dal fatto che l'accesso limitato sia configurato nel prodotto dati (se si usano gli endpoint di servizio per accedere all'account di archiviazione di input del prodotto dati). Alcune configurazioni di rete potrebbero comportare costi aggiuntivi, ad esempio una rete virtuale di Azure tra la macchina virtuale e l'account di archiviazione di input del prodotto dati.

Quando si usa una macchina virtuale locale:

  • Configurare un firewall per consentire il traffico di rete solo sulle porte necessarie per eseguire l'agente e gestire la macchina virtuale.

Crittografia del disco

Assicurarsi che la crittografia dischi di Azure sia abilitata (impostazione predefinita quando si crea la macchina virtuale).

Versione sistema operativo

  • Mantenere aggiornata la versione del sistema operativo per evitare vulnerabilità note.
  • Configurare la macchina virtuale per verificare periodicamente la presenza di aggiornamenti di sistema mancanti.

Accesso

Limitare l'accesso alla macchina virtuale a un set minimo di utenti. Configurare la registrazione di controllo nella macchina virtuale, ad esempio usando il pacchetto di controllo Linux, per registrare i tentativi di accesso e le azioni eseguite dagli utenti connessi.

È consigliabile limitare i tipi di accesso seguenti.

  • Amministrazione l'accesso alla macchina virtuale, ad esempio per arrestare/avviare/installare l'agente di inserimento.
  • Accesso alla directory in cui sono archiviati i log: /var/log/az-aoi-ingestion/.
  • Accesso all'identità gestita o al certificato e alla chiave privata per l'entità servizio creata durante questa procedura.
  • Accedere alla directory per i segreti creati nella macchina virtuale durante questa procedura.

Microsoft Defender for Cloud

Quando si usa una macchina virtuale di Azure, seguire anche tutti i consigli di Microsoft Defender per il cloud. È possibile trovare queste raccomandazioni nel portale passando alla macchina virtuale e quindi selezionando Sicurezza.

Configurare l'autenticazione in Azure

L'agente di inserimento deve essere in grado di eseguire l'autenticazione con Azure Key Vault creato dal prodotto dati per recuperare le credenziali di archiviazione. Il metodo di autenticazione può essere:

  • Entità servizio con credenziali del certificato. Se l'agente di inserimento è in esecuzione all'esterno di Azure, ad esempio in una rete locale, è necessario usare questo metodo.
  • Identità gestita. Se l'agente di inserimento è in esecuzione in una macchina virtuale di Azure, è consigliabile usare questo metodo. Non richiede la gestione delle credenziali (a differenza di un'entità servizio).

Importante

Potrebbe essere necessario un amministratore tenant di Microsoft Entra nell'organizzazione per eseguire questa configurazione.

Usare un'identità gestita per l'autenticazione

Se l'agente di inserimento è in esecuzione in Azure, è consigliabile usare le identità gestite. Per informazioni più dettagliate, vedere la panoramica delle identità gestite.

Nota

Gli agenti di inserimento nelle macchine virtuali di Azure supportano identità gestite assegnate dal sistema e assegnate dall'utente. Per più agenti, un'identità gestita assegnata dall'utente è più semplice perché è possibile autorizzare l'identità all'insieme di credenziali dei codici Product Key per tutte le macchine virtuali che eseguono l'agente.

  1. Creare o ottenere un'identità gestita assegnata dall'utente seguendo le istruzioni riportate in Gestire le identità gestite assegnate dall'utente. Se si prevede di usare un'identità gestita assegnata dal sistema, non creare un'identità gestita assegnata dall'utente.
  2. Seguire le istruzioni in Configurare le identità gestite per le risorse di Azure in una macchina virtuale usando il portale di Azure in base al tipo di identità gestita in uso.
  3. Prendere nota dell'ID oggetto dell'identità gestita. L'ID oggetto è un UUID del formato xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, dove ogni carattere è una cifra esadecimale.

È ora possibile concedere le autorizzazioni per Data Product Key Vault.

Usare un'entità servizio per l'autenticazione

Se l'agente di inserimento è in esecuzione all'esterno di Azure, ad esempio una rete locale, non è possibile usare le identità gestite e deve invece eseguire l'autenticazione all'insieme di credenziali product key dei dati usando un'entità servizio con credenziali del certificato. Ogni agente deve avere anche una copia del certificato archiviato nella macchina virtuale.

Creare un'entità servizio

  1. Creare o ottenere un'entità servizio Microsoft Entra ID. Seguire le istruzioni descritte in Creare un'app Microsoft Entra e un'entità servizio nel portale. Lasciare vuoto il campo URI di reindirizzamento.
  2. Prendere nota dell'ID applicazione (client) e dell'ID di Microsoft Entra Directory (tenant) (questi ID sono UUID del formato xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, dove ogni carattere è una cifra esadecimale).

Preparare i certificati per l'entità servizio

L'agente di inserimento supporta solo le credenziali del certificato per le entità servizio. È possibile usare lo stesso certificato e la stessa chiave per ogni macchina virtuale oppure usare un certificato e una chiave univoci per ognuno di essi. L'uso di un certificato per macchina virtuale offre una maggiore sicurezza e ha un impatto minore se una chiave viene persa o il certificato scade. Tuttavia, questo metodo aggiunge una maggiore gestibilità e complessità operativa.

  1. Ottenere uno o più certificati. È consigliabile usare certificati attendibili di un'autorità di certificazione. I certificati possono essere generati da Azure Key Vault: vedere Impostare e recuperare un certificato da Key Vault usando portale di Azure. In questo modo è possibile configurare gli avvisi di scadenza e consente di rigenerare nuovi certificati e applicarli agli agenti di inserimento prima della scadenza. Una volta scaduto un certificato, l'agente non è in grado di eseguire l'autenticazione in Azure e non carica più i dati. Per informazioni dettagliate su questo approccio, vedere Rinnovare i certificati di Azure Key Vault. Se si sceglie di usare Azure Key Vault, procedere come:
    • Questo insieme di credenziali delle chiavi di Azure deve essere un'istanza diversa dell'insieme di credenziali dei dati Product Key, uno già controllato o uno nuovo.
    • Per aggiungere il certificato all'insieme di credenziali delle chiavi, è necessario il ruolo "Key Vault Certificates Officer" in questo insieme di credenziali delle chiavi di Azure. Per informazioni dettagliate su come assegnare ruoli in Azure, vedere Assegnare ruoli di Azure usando il portale di Azure.
  2. Aggiungere il certificato o i certificati come credenziali all'entità servizio, seguendo creare un'app Microsoft Entra e un'entità servizio nel portale.
  3. Verificare che i certificati siano disponibili in formato PKCS#12 (P12), senza alcuna passphrase che li protegge.
    • Se il certificato viene archiviato in un insieme di credenziali delle chiavi di Azure, scaricare il certificato nel formato PFX. PFX è identico a P12.
    • In Linux è possibile convertire un certificato e una chiave privata usando OpenSSL. Quando viene richiesta una password di esportazione, premere INVIO per specificare una passphrase vuota. Questa operazione può quindi essere archiviata in un insieme di credenziali delle chiavi di Azure, come descritto nel passaggio 1.
    openssl pkcs12 -nodes -export -in <certificate.pem> -inkey <key.pem> -out <certificate.p12>

Importante

Il file P12 non deve essere protetto con una passphrase.

  1. Convalidare il file P12. Vengono visualizzate informazioni sul file P12, inclusi il certificato e la chiave privata.

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

  2. Verificare che il file P12 sia codificato in base64. In Linux è possibile codificare in base64 un certificato P12 usando il base64 comando .

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

Concedere le autorizzazioni per Data Product Key Vault

  1. Trovare Azure Key Vault che contiene le credenziali di archiviazione per l'account di archiviazione di input. Questo insieme di credenziali delle chiavi si trova in un gruppo di risorse denominato <data-product-name>-HostedResources-<unique-id>.
  2. Concedere all'entità servizio il ruolo "Utente segreti dell'insieme di credenziali delle chiavi" in questo insieme di credenziali delle chiavi. Sono necessarie autorizzazioni a livello di proprietario per la sottoscrizione di Azure. Per informazioni dettagliate su come assegnare ruoli in Azure, vedere Assegnare ruoli di Azure usando il portale di Azure.
  3. Prendere nota del nome dell'insieme di credenziali delle chiavi.

Preparare il server SFTP

Questa sezione è necessaria solo per l'origine pull SFTP.

Nel server SFTP:

  1. Verificare che la porta 22/TCP per la macchina virtuale sia aperta.
  2. Creare un nuovo utente o determinare un utente esistente nel server SFTP che l'agente di inserimento deve usare per connettersi al server SFTP.
    • Per impostazione predefinita, l'agente di inserimento esegue la ricerca in ogni directory nel percorso di base, quindi l'utente deve essere in grado di leggerli tutti. Tutte le directory a cui l'utente non dispone dell'autorizzazione per l'accesso devono essere escluse tramite la exclude_pattern configurazione.

    Nota

    L'esclusione implicita delle directory non specificandole nel modello incluso non è sufficiente per interrompere la ricerca dell'agente in tali directory. Per altri dettagli sull'esclusione delle directory, vedere le informazioni di riferimento sulla configurazione.

  3. Determinare il metodo di autenticazione che l'agente di inserimento deve usare per connettersi al server SFTP. L'agente supporta:
    • Autenticazione della password
    • Autenticazione della chiave SSH
  4. Configurare il server SFTP per rimuovere i file dopo un periodo di tempo (periodo di conservazione). Assicurarsi che il periodo di conservazione sia sufficientemente lungo da consentire all'agente di elaborare i file prima che il server SFTP li elimini. Il file di configurazione di esempio contiene la configurazione per verificare la presenza di nuovi file ogni cinque minuti.

Importante

Il server SFTP deve rimuovere i file dopo un periodo di conservazione appropriato in modo che non esaurisca lo spazio su disco. L'agente di inserimento non rimuove automaticamente i file.

Un tempo di conservazione più breve riduce l'utilizzo del disco, aumenta la velocità dell'agente e riduce il rischio di caricamenti duplicati. Tuttavia, un periodo di conservazione più breve aumenta il rischio di perdita dei dati se i dati non possono essere recuperati dall'agente o caricati in Azure Operator Insights.

Preparare le macchine virtuali

Ripetere questi passaggi per ogni macchina virtuale in cui si vuole installare l'agente.

  1. Assicurarsi di avere una sessione SSH aperta alla macchina virtuale e di disporre sudo delle autorizzazioni.

  2. Installare systemd, logrotate e zip nella macchina virtuale, se non è già presente. Ad esempio:

    sudo dnf install systemd logrotate zip

  3. Se si usa un'entità servizio, copiare il certificato P12 con codifica Base64 (creato nel passaggio Preparare i certificati ) nella macchina virtuale, in una posizione accessibile all'agente di inserimento.

  4. Configurare la macchina virtuale dell'agente in base al tipo di origine di inserimento.

    1. Verificare che la macchina virtuale abbia le porte seguenti aperte. Queste porte devono essere aperte sia nei gruppi di sicurezza di rete cloud che in qualsiasi firewall in esecuzione nella macchina virtuale stessa ,ad esempio firewalld o iptables.
      • Porta 443/TCP in uscita in Azure
      • Porta 22/TCP in uscita nel server SFTP
    2. Creare una directory da usare per archiviare i segreti per l'agente. Questa directory è denominata directory dei segreti. Prendere nota del percorso.
    3. Creare un file nella directory dei segreti contenente la password o la chiave SSH privata per il server SFTP.
      • Il file non deve avere un'estensione di file.
      • Scegliere un nome appropriato per questo file e annotarlo per un secondo momento. Questo nome viene fatto riferimento nella configurazione dell'agente.
      • Il file deve contenere solo il valore del segreto (password o chiave SSH), senza spazi vuoti aggiuntivi.
    4. Se si usa una chiave SSH con una passphrase per l'autenticazione, usare lo stesso metodo per creare un file separato contenente la passphrase.
    5. Verificare che la chiave SSH pubblica del server SFTP sia elencata nel file globale known_hosts della macchina virtuale che si trova in /etc/ssh/ssh_known_hosts.

    Suggerimento

    Usare il comando ssh-keyscan Linux per aggiungere manualmente la chiave pubblica SSH di un server al file known_hosts di una macchina virtuale. Ad esempio: ssh-keyscan -H <server-ip> | sudo tee -a /etc/ssh/ssh_known_hosts.

Assicurarsi che la macchina virtuale possa risolvere i nomi host Microsoft

Verificare che la macchina virtuale sia in grado di risolvere i nomi host pubblici negli indirizzi IP. Ad esempio, aprire una sessione SSH e usare dig login.microsoftonline.com per verificare che la macchina virtuale possa risolversi login.microsoftonline.com in un indirizzo IP.

Se la macchina virtuale non può usare DNS per risolvere i nomi host Microsoft pubblici negli indirizzi IP, eseguire il mapping dei nomi host necessari agli indirizzi IP. Tornare a questa procedura al termine della configurazione.

Installare il software dell'agente

Il pacchetto software dell'agente è ospitato nel "repository software Linux per i prodotti Microsoft" all'indirizzo https://packages.microsoft.com

Il nome del pacchetto dell'agente di inserimento è az-aoi-ingestion.

Per scaricare e installare un pacchetto dal repository software, seguire i passaggi pertinenti per la distribuzione Linux della macchina virtuale in Come installare i pacchetti software Microsoft usando il repository Linux.

Ad esempio, se si esegue l'installazione in una macchina virtuale che esegue Red Hat Enterprise Linux (RHEL) 8, seguire le istruzioni nell'intestazione Distribuzioni Linux basate su Red Hat sostituendo i parametri seguenti:

  • Distribuzione: rhel
  • Versione: 8
  • package-name: az-aoi-ingestion

Configurare il software dell'agente

La configurazione necessaria è specifica del tipo di origine e del prodotto dati. Assicurarsi di avere accesso alla documentazione del prodotto dati per visualizzare i valori necessari. Ad esempio:

  1. Connessione alla macchina virtuale tramite SSH.

  2. Passare alla directory di configurazione.

    cd /etc/az-aoi-ingestion

  3. Creare una copia del file di configurazione predefinito.

    sudo cp example_config.yaml config.yaml

  4. Impostare il agent_id campo su un identificatore univoco per l'istanza dell'agente, ad esempio london-sftp-1. Questo nome diventa metadati ricercabili in Informazioni dettagliate operatori per tutti i dati inseriti da questo agente. I caratteri URL riservati devono essere codificati in percentuale.

  5. Configurare la secret_providers sezione .

    Le origini SFTP richiedono due tipi di provider segreti.

    • Provider segreto di tipo key_vault, che contiene i dettagli necessari per connettersi all'insieme di credenziali delle chiavi di Azure del prodotto dati e consentire la connessione all'account di archiviazione di input del prodotto dati.
    • Provider segreto di tipo file_system, che specifica una directory nella macchina virtuale per l'archiviazione delle credenziali per la connessione a un server SFTP.
    1. Per il provider di segreti con tipo key_vault e nome data_product_keyvault, impostare i campi seguenti.
      • vault_name deve essere il nome dell'insieme di credenziali delle chiavi per il prodotto dati. Questo nome è stato identificato in Concedere le autorizzazioni per l'insieme di credenziali dei dati Product Key Vault.
      • A seconda del tipo di autenticazione scelto in Configurare l'autenticazione in Azure, impostare managed_identity o service_principal.
        • Per un'identità gestita: impostare sull'ID object_id oggetto dell'identità gestita creata in Usare un'identità gestita per l'autenticazione.
        • Per un'entità servizio: impostare sul tenant_id tenant microsoft Entra ID, client_id sull'ID applicazione (client) dell'entità servizio creata in Creare un'entità servizio e cert_path sul percorso file del certificato P12 con codifica base64 nella macchina virtuale.
    2. Per il provider di segreti con tipo file_system e nome local_file_system, impostare i campi seguenti.

    È possibile aggiungere altri provider segreti( ad esempio, se si desidera caricare in più prodotti dati) o modificare i nomi dei provider di segreti predefiniti.

  6. Configurare la pipelines sezione usando la configurazione di esempio e la documentazione del prodotto dati. Ognuno pipeline ha tre sezioni di configurazione.

    • id. L'ID identifica la pipeline e non deve essere uguale a qualsiasi altro ID della pipeline per questo agente di inserimento. Tutti i caratteri riservati url devono essere codificati in percentuale. Per eventuali consigli, vedere la documentazione del prodotto dati.

    • source. La configurazione del codice sorgente controlla quali file vengono inseriti. È possibile configurare più origini.

      Eliminare tutte le pipeline nell'esempio, ad eccezione dell'esempio, che contiene sftp_pull la contoso-logs configurazione di origine.

      Aggiornare l'esempio per soddisfare i requisiti. Per ogni origine sono necessari i campi seguenti.

      • host: nome host o indirizzo IP del server SFTP.
      • filtering.base_path: percorso di una cartella nel server SFTP da cui verranno caricati i file in Azure Operator Insights.
      • known_hosts_file: percorso della macchina virtuale al file known_hosts globale, che si trova in /etc/ssh/ssh_known_hosts. Questo file deve contenere le chiavi SSH pubbliche del server host SFTP, come descritto in Preparare le macchine virtuali.
      • user: nome dell'utente nel server SFTP che l'agente deve usare per connettersi.
      • A seconda del metodo di autenticazione scelto in Preparare le macchine virtuali, impostare password o private_key.
        • Per l'autenticazione della password, impostare secret_name sul nome del file contenente la password nella secrets_directory cartella .
        • Per l'autenticazione della chiave SSH, impostare key_secret_name sul nome del file contenente la chiave SSH nella secrets_directory cartella. Se la chiave privata è protetta con una passphrase, impostare passphrase_secret_name sul nome del file contenente la passphrase nella secrets_directory cartella.
        • Tutti i file segreti devono avere le autorizzazioni (600rw-------) e un proprietario di in modo che solo l'agente di az-aoi-ingestion inserimento e gli utenti con privilegi possano leggerli.
        sudo chmod 600 <secrets_directory>/*
sudo chown az-aoi-ingestion <secrets_directory>/*

      Per i valori obbligatori o consigliati per altri campi, vedere la documentazione relativa al prodotto dati.

      Suggerimento

      L'agente supporta una configurazione facoltativa aggiuntiva per quanto segue:

      • Specificando un modello di file nella base_path cartella che verrà caricata (per impostazione predefinita vengono caricati tutti i file nella cartella).
      • Specifica di un modello di file nella base_path cartella che non deve essere caricata.
      • Ora e data prima delle quali i file nella base_path cartella non verranno caricati.
      • Con quale frequenza l'agente di inserimento carica i file (il valore fornito nel file di configurazione di esempio corrisponde a ogni ora).
      • Tempo di tolleranza, che è un periodo di tempo dopo l'ultima modifica di un file che l'agente attenderà prima del caricamento (il valore fornito nel file di configurazione di esempio è 5 minuti).

      Per altre informazioni su queste opzioni di configurazione, vedere Informazioni di riferimento sulla configurazione per l'agente di inserimento di Azure Operator Insights.

    • sink. Controlli di configurazione sink che caricano i dati nell'account di archiviazione di input del prodotto dati.

      • sas_token Nella sezione impostare l'oggetto secret_provider sul provider di segreti appropriato key_vault per il prodotto dati oppure usare il valore predefinito se è stato usato il nome predefinito in precedenzadata_product_keyvault. Lasciare secret_name invariati.
      • Per informazioni sui valori obbligatori per altri parametri, vedere la documentazione del prodotto dati.

        Importante

        Il container_name campo deve essere impostato esattamente come specificato dalla documentazione del prodotto dati.

Avviare il software dell'agente

  1. Avviare l'agente. 
    sudo systemctl start az-aoi-ingestion
  2. Verificare che l'agente sia in esecuzione. 
    sudo systemctl status az-aoi-ingestion
    1. Se viene visualizzato uno stato diverso da active (running), esaminare i log come descritto in Monitorare e risolvere i problemi degli agenti di inserimento per Informazioni dettagliate sugli operatori di Azure per comprendere l'errore. È probabile che alcune configurazioni non siano corrette.
    2. Dopo aver risolto il problema, tentare di riavviare l'agente.
    3. Se i problemi vengono mantenuti, generare un ticket di supporto.
  3. Quando l'agente è in esecuzione, assicurarsi che venga avviato automaticamente dopo il riavvio. 
    sudo systemctl enable az-aoi-ingestion.service

[Facoltativo] Configurare la raccolta di log per l'accesso tramite Monitoraggio di Azure

Se si esegue l'agente di inserimento in una macchina virtuale di Azure o in una macchina virtuale locale connessa da Azure Arc, è possibile inviare i log dell'agente di inserimento a Monitoraggio di Azure usando l'agente di Monitoraggio di Azure. L'uso di Monitoraggio di Azure per accedere ai log può essere più semplice rispetto all'accesso ai log direttamente nella macchina virtuale.

Per raccogliere i log dell'agente di inserimento, seguire la documentazione di Monitoraggio di Azure per installare l'agente di Monitoraggio di Azure e configurare la raccolta dei log.

  • Questi documenti usano il modulo Az PowerShell per creare una tabella dei log. Seguire prima la documentazione relativa all'installazione del modulo Az PowerShell.
    • La YourOptionalColumn sezione del codice JSON di esempio $tableParams non è necessaria per l'agente di inserimento e può essere rimossa.
  • Quando si aggiunge un'origine dati alla regola di raccolta dati, aggiungere un Custom Text Logs tipo di origine con il modello /var/log/az-aoi-ingestion/stdout.logdi file .
  • È anche consigliabile seguire la documentazione per aggiungere un'origine Linux Syslog dati alla regola di raccolta dati per consentire il controllo di tutti i processi in esecuzione nella macchina virtuale.
  • Dopo aver aggiunto la regola di raccolta dati, è possibile eseguire query sui log dell'agente di inserimento tramite l'area di lavoro Log Analytics. Usare la query seguente per semplificarne l'uso: 
    <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

    Questa query non può essere usata come trasformazione dell'origine dati, perché replace_regex non è disponibile nelle trasformazioni dell'origine dati.

Esempi di log

[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

Contenuto correlato

Scopri come: