Share via

Установите агент приема Аналитика оператора Azure и настройте его для отправки данных.

  • Статья

После выполнения этой статьи вы настроили агент приема Аналитика оператора Azure на виртуальной машине в сети и настройте его для отправки данных в продукт данных. Этот агент приема поддерживает отправку:

  • Файлы, хранящиеся на сервере SFTP.
  • Подтверждены потоки данных данных о событиях (EDR) в облаке мобильного содержимого (MCC).

Общие сведения об агентах приема см. в обзоре агента приема.

Необходимые компоненты

В документации по продукту данных получите следующие сведения:

  • Спецификации виртуальной машины, на которой планируется установить агент виртуальной машины.
  • Пример конфигурации агента приема.

Рекомендации по безопасности виртуальных машин

Виртуальная машина, используемая для агента приема, должна быть настроена в соответствии с рекомендациями по обеспечению безопасности. Рекомендуем сделать следующее:

Сеть

При использовании виртуальной машины Azure:

  • Присвойте виртуальной машине частный IP-адрес.
  • Настройте группу безопасности сети (NSG), чтобы разрешить только сетевой трафик на портах, необходимых для запуска агента и обслуживания виртуальной машины.
  • Помимо этого, конфигурация сети зависит от того, настроен ли ограниченный доступ к продукту данных (используете ли конечные точки службы для доступа к входной учетной записи хранения продукта данных). В некоторых конфигурациях сети может потребоваться дополнительная плата, например виртуальная сеть Azure между виртуальной машиной и входной учетной записью хранения продукта данных.

При использовании локальной виртуальной машины:

  • Настройте брандмауэр, чтобы разрешить только сетевой трафик на портах, необходимых для запуска агента и обслуживания виртуальной машины.

Шифрование дисков

Убедитесь, что шифрование дисков Azure включено (это значение по умолчанию при создании виртуальной машины).

Версия ОС

  • Не обновляйте версию ОС, чтобы избежать известных уязвимостей.
  • Настройте виртуальную машину периодически проверка для отсутствующих обновлений системы.

Открыть

Ограничение доступа к виртуальной машине минимальному набору пользователей. Настройте ведение журнала аудита на виртуальной машине( например, с помощью пакета аудита Linux для записи попыток входа и действий, выполняемых пользователями, вошедшего в систему.

Рекомендуется ограничить следующие типы доступа.

  • Администратор доступ к виртуальной машине (например, остановить или запустить или установить агент приема).
  • Доступ к каталогу, в котором хранятся журналы: /var/log/az-aoi-ingestion/.
  • Доступ к управляемому удостоверению или сертификату и закрытому ключу для субъекта-службы, создаваемого во время этой процедуры.
  • Доступ к каталогу секретов, создаваемых на виртуальной машине во время этой процедуры.

Microsoft Defender для облака

При использовании виртуальной машины Azure также следуйте всем рекомендациям из Microsoft Defender для облака. Эти рекомендации можно найти на портале, перейдя на виртуальную машину, а затем выбрав "Безопасность".

Настройка проверки подлинности в Azure

Агент приема должен иметь возможность пройти проверку подлинности с помощью Azure Key Vault, созданного продуктом данных для получения учетных данных хранения. Способ проверки подлинности может быть следующим:

  • Субъект-служба с учетными данными сертификата. Если агент приема работает за пределами Azure, например в локальной сети, необходимо использовать этот метод.
  • Управляемое удостоверение. Если агент приема выполняется на виртуальной машине Azure, рекомендуется использовать этот метод. Он не требует обработки учетных данных (в отличие от субъекта-службы).

Внимание

Чтобы выполнить эту настройку, может потребоваться администратор клиента Microsoft Entra в организации.

Использование управляемого удостоверения для проверки подлинности

Если агент приема работает в Azure, рекомендуется использовать управляемые удостоверения. Дополнительные сведения см. в обзоре управляемых удостоверений.

Примечание.

Агенты приема на виртуальных машинах Azure поддерживают управляемые удостоверения, назначенные системой и назначаемые пользователем. Для нескольких агентов управляемое удостоверение, назначаемое пользователем, проще, так как вы можете авторизовать удостоверение в Хранилище ключей данных для всех виртуальных машин под управлением агента.

  1. Создайте или получите управляемое удостоверение, назначаемое пользователем, следуя инструкциям в статье "Управление управляемыми удостоверениями, назначаемыми пользователем". Если вы планируете использовать управляемое удостоверение, назначаемое системой, не создавайте управляемое удостоверение, назначаемое пользователем.
  2. Следуйте инструкциям в статье "Настройка управляемых удостоверений для ресурсов Azure на виртуальной машине" с помощью портал Azure в соответствии с типом используемого управляемого удостоверения.
  3. Обратите внимание на идентификатор объекта управляемого удостоверения. Идентификатор объекта — это идентификатор UUID формы xxxx-xxxx-xxxx-xxxx-xxxx-xxxx, где каждый символ является шестнадцатеричной цифрой.

Теперь вы можете предоставить разрешения для Хранилища ключей продуктов данных.

Использование субъекта-службы для проверки подлинности

Если агент приема работает за пределами Azure, например локальная сеть, вы не можете использовать управляемые удостоверения и вместо этого должны пройти проверку подлинности в Data Product Key Vault с помощью субъекта-службы с учетными данными сертификата. Каждый агент также должен иметь копию сертификата, хранящегося на виртуальной машине.

Создание субъекта-службы

  1. Создайте или получите субъект-службу идентификатора Microsoft Entra. Следуйте инструкциям, описанным в статье "Создание приложения Microsoft Entra и субъекта-службы" на портале. Оставьте поле URI перенаправления пустым.
  2. Обратите внимание на идентификатор приложения (клиента) и идентификатор каталога Microsoft Entra Directory (клиент) (эти идентификаторы являются идентификаторами UUID формы xxxx-xxxxx-xxxx, где каждый символ является шестнадцатеричной цифрой).

Подготовка сертификатов для субъекта-службы

Агент приема поддерживает только учетные данные сертификата для субъектов-служб. Вы можете использовать один и тот же сертификат и ключ для каждой виртуальной машины или использовать уникальный сертификат и ключ для каждой виртуальной машины. Использование сертификата для каждой виртуальной машины обеспечивает более высокую безопасность и оказывает меньшее влияние на утечку ключа или срок действия сертификата. Однако этот метод добавляет более высокую удобство обслуживания и операционную сложность.

  1. Получите один или несколько сертификатов. Настоятельно рекомендуется использовать доверенные сертификаты из центра сертификации. Сертификаты можно создать из Azure Key Vault: см. раздел "Установка и получение сертификата из Key Vault" с помощью портал Azure. Это позволяет настроить оповещение об истечении срока действия и предоставить время для повторного создания новых сертификатов и применения их к агентам приема до истечения срока их действия. После истечения срока действия сертификата агент не может пройти проверку подлинности в Azure и больше не отправляет данные. Дополнительные сведения об этом подходе см. в статье "Продление сертификатов Azure Key Vault". Если вы решили использовать Azure Key Vault, выполните следующие действия.
    • Это Хранилище ключей Azure должно быть другим экземпляром Хранилища ключей данных, который вы уже управляете или новым.
    • Чтобы добавить сертификат в Key Vault в Key Vault, вам потребуется роль "Сотрудник по сертификатам Key Vault". Дополнительные сведения о назначении ролей в Azure см. в статье "Назначение ролей Azure с помощью портал Azure".
  2. Добавьте сертификат или сертификаты в качестве учетных данных в субъект-службу после создания приложения Microsoft Entra и субъекта-службы на портале.
  3. Убедитесь, что сертификаты доступны в формате PKCS#12 (P12) без парольной фразы.
    • Если сертификат хранится в Azure Key Vault, скачайте сертификат в формате PFX. PFX идентичен P12.
    • В Linux можно преобразовать сертификат и закрытый ключ с помощью OpenSSL. При появлении запроса на экспорт пароля нажмите клавишу ВВОД , чтобы указать пустую парольную фразу. Затем его можно сохранить в Azure Key Vault, как описано на шаге 1.
    openssl pkcs12 -nodes -export -in <certificate.pem> -inkey <key.pem> -out <certificate.p12>

Внимание

Файл P12 не должен быть защищен с помощью парольной фразы.

  1. Проверьте P12-файл. Здесь отображаются сведения о P12-файле, включая сертификат и закрытый ключ.

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

  2. Убедитесь, что P12-файл закодирован в кодировке Base64. В Linux можно закодировать сертификат P12 в base64 с помощью base64 команды.

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

Предоставление разрешений для хранилища ключей продукта данных

  1. Найдите Azure Key Vault, в котором хранятся учетные данные хранения для входной учетной записи хранения. Это хранилище ключей находится в группе ресурсов с именем <data-product-name>-HostedResources-<unique-id>.
  2. Предоставьте субъекту-службе роль "Пользователь секретов Key Vault" в этом Key Vault. Вам нужны разрешения уровня владельца в подписке Azure. Дополнительные сведения о назначении ролей в Azure см. в статье "Назначение ролей Azure с помощью портал Azure".
  3. Запишите имя Key Vault.

Подготовка сервера SFTP

Этот раздел необходим только для источника извлечения SFTP.

На сервере SFTP:

  1. Убедитесь, что на виртуальной машине открыт порт 22/TCP.
  2. Создайте нового пользователя или определите существующего пользователя на сервере SFTP, который агент приема должен использовать для подключения к серверу SFTP.
    • По умолчанию агент приема выполняет поиск каждого каталога по базовому пути, поэтому этот пользователь должен иметь возможность прочитать все из них. Все каталоги, у которых у пользователя нет разрешения на доступ, должны быть исключены с помощью конфигурации exclude_pattern .

    Примечание.

    Неявно исключив каталоги, не указывая их в включенном шаблоне, недостаточно, чтобы остановить поиск этих каталогов агентом. Дополнительные сведения об исключении каталогов см . в справочнике по конфигурации.

  3. Определите метод проверки подлинности, который агент приема должен использовать для подключения к серверу SFTP. Агент поддерживает следующее:
    • Проверка пароля
    • Проверка подлинности ключа SSH
  4. Настройте сервер SFTP для удаления файлов через период времени ( период хранения). Убедитесь, что срок хранения достаточно длинный, чтобы агент должен обрабатывать файлы до удаления сервера SFTP. Пример файла конфигурации содержит конфигурацию для проверка для новых файлов каждые пять минут.

Внимание

Сервер SFTP должен удалить файлы после подходящего периода хранения, чтобы не было свободного места на диске. Агент приема не удаляет файлы автоматически.

Более короткое время хранения сокращает использование диска, увеличивает скорость агента и снижает риск дублирования отправки. Однако более короткий период хранения увеличивает риск потери данных, если данные не могут быть извлечены агентом или отправлены в оператор Azure Аналитика.

Подготовка виртуальных машин

Повторите эти действия для каждой виртуальной машины, на которую нужно установить агент.

  1. Убедитесь, что у вас есть сеанс SSH, открытый для виртуальной машины, и у вас есть sudo разрешения.

  2. Установите системный, logrotate и ZIP-файл на виртуальной машине, если он еще не присутствует. Например:

    sudo dnf install systemd logrotate zip

  3. Если вы используете субъект-службу, скопируйте сертификат P12 в кодировке Base64 (созданный на этапе подготовки сертификатов ) на виртуальную машину в расположении, доступном агенту приема.

  4. Настройте виртуальную машину агента на основе типа источника приема.

    1. Убедитесь, что у виртуальной машины открыты следующие порты. Эти порты должны быть открыты как в группах безопасности облачной сети, так и в любом брандмауэре, работающем на самой виртуальной машине (например, брандмауэр или iptables).
      • Исходящий порт 443/TCP в Azure
      • Исходящий порт 22/TCP на сервер SFTP
    2. Создайте каталог для хранения секретов для агента. Мы называем этот каталог каталогом секретов. Обратите внимание на его путь.
    3. Создайте файл в каталоге секретов, содержашем пароль или закрытый ключ SSH для сервера SFTP.
      • Файл не должен иметь расширение.
      • Выберите подходящее имя для этого файла и запишите его позже. Это имя ссылается в конфигурации агента.
      • Файл должен содержать только значение секрета (пароль или ключ SSH), без дополнительного пробела.
    4. Если вы используете ключ SSH с парольной фразой для проверки подлинности, используйте тот же метод, чтобы создать отдельный файл, содержащий парольную фразу.
    5. Убедитесь, что открытый ключ SSH сервера SFTP указан в глобальном known_hosts файле виртуальной машины, расположенном по адресу /etc/ssh/ssh_known_hosts.

    Совет

    Используйте команду ssh-keyscan Linux, чтобы добавить открытый ключ SSH сервера в файл known_hosts виртуальной машины вручную. Например, ssh-keyscan -H <server-ip> | sudo tee -a /etc/ssh/ssh_known_hosts.

Убедитесь, что виртуальная машина может разрешать имена узлов Майкрософт

Убедитесь, что виртуальная машина может разрешать общедоступные имена узлов в IP-адреса. Например, откройте сеанс SSH и используйте dig login.microsoftonline.com для проверка, которую виртуальная машина может разрешить login.microsoftonline.com в IP-адрес.

Если виртуальная машина не может использовать DNS для разрешения общедоступных имен узлов Майкрософт с IP-адресами, сопоставляйте необходимые имена узлов с IP-адресами. Вернитесь к этой процедуре после завершения настройки.

Установка программного обеспечения агента

Пакет программного обеспечения агента размещен в репозитории программного обеспечения Linux для продуктов Майкрософт. https://packages.microsoft.com

Имя пакета агента приема.az-aoi-ingestion

Чтобы скачать и установить пакет из репозитория программного обеспечения, выполните соответствующие действия для дистрибутива Linux виртуальной машины в разделе "Установка пакетов программного обеспечения Майкрософт с помощью репозитория Linux".

Например, если вы устанавливаете на виртуальной машине под управлением Red Hat Enterprise Linux (RHEL) 8, следуйте инструкциям в заголовке дистрибутивов Linux на основе Red Hat, заменив следующие параметры:

  • Распространения: rhel
  • Версия: 8
  • имя пакета: az-aoi-ingestion

Настройка программного обеспечения агента

Необходимая конфигурация зависит от типа источника и продукта данных. Убедитесь, что у вас есть доступ к документации по продукту данных, чтобы просмотреть необходимые значения. Например:

  1. Подключение на виртуальную машину по протоколу SSH.

  2. Перейдите в каталог конфигурации.

    cd /etc/az-aoi-ingestion

  3. Создайте копию файла конфигурации по умолчанию.

    sudo cp example_config.yaml config.yaml

  4. agent_id Задайте для поля уникальный идентификатор для экземпляра агента, напримерlondon-sftp-1. Это имя становится доступными для поиска метаданными в операторе Аналитика для всех данных, принятых этим агентом. Зарезервированные символы URL-адреса должны быть закодированы в процентах.

  5. secret_providers Настройте раздел.

    Для источников SFTP требуется два типа поставщиков секретов.

    • Поставщик секретов типа key_vault, содержащий сведения, необходимые для подключения к Azure Key Vault продукта данных и разрешающего подключение к входной учетной записи хранения продукта данных.
    • Поставщик секретов типа file_system, указывающий каталог на виртуальной машине для хранения учетных данных для подключения к серверу SFTP.
    1. Для поставщика секретов с типом key_vault и именем data_product_keyvaultзадайте следующие поля.
    2. Для поставщика секретов с типом file_system и именем local_file_systemзадайте следующие поля.

    Вы можете добавить дополнительные поставщики секретов (например, если вы хотите отправить в несколько продуктов данных) или изменить имена поставщиков секретов по умолчанию.

  6. pipelines Настройте раздел с помощью примера конфигурации и документации по продукту данных. Каждый из них pipeline состоит из трех разделов конфигурации.

    • id. Идентификатор определяет конвейер и не должен совпадать с любым другим идентификатором конвейера для этого агента приема. Все зарезервированные URL-адреса должны быть закодированы в процентах. Сведения о любых рекомендациях см. в документации по продукту данных.

    • source. Элементы управления конфигурацией источника, которые обрабатываются файлами. Можно настроить несколько источников.

      Удалите все конвейеры в примере, кроме contoso-logs примера, содержащего sftp_pull исходную конфигурацию.

      Обновите пример, чтобы соответствовать вашим требованиям. Для каждого источника требуются следующие поля.

      • host: имя узла или IP-адрес сервера SFTP.
      • filtering.base_path: путь к папке на сервере SFTP, из Аналитика из него будут отправлены файлы.
      • known_hosts_file: путь на виртуальной машине к глобальному known_hosts-файлу, расположенному по адресу /etc/ssh/ssh_known_hosts. Этот файл должен содержать открытые ключи SSH сервера узла SFTP, как описано в разделе "Подготовка виртуальных машин".
      • user: имя пользователя на сервере SFTP, который агент должен использовать для подключения.
      • В зависимости от метода проверки подлинности, выбранного в разделе "Подготовка виртуальных машин", задайте либо passwordprivate_key.
        • Для проверки подлинности паролей задайте secret_name имя файла, содержащего пароль в папке secrets_directory .
        • Для проверки подлинности ключа SSH задайте key_secret_name имя файла, содержащего ключ SSH в папке secrets_directory . Если закрытый ключ защищен с помощью парольной фразы, задайте passphrase_secret_name имя файла, содержащего парольную фразу в папке secrets_directory .
        • Все секретные файлы должны иметь разрешения 600 (rw-------), и владелец az-aoi-ingestion так, чтобы только агент приема и привилегированные пользователи могли их читать.
        sudo chmod 600 <secrets_directory>/*
sudo chown az-aoi-ingestion <secrets_directory>/*

      Дополнительные или рекомендуемые значения для других полей см. в документации по продукту данных.

      Совет

      Агент поддерживает дополнительную необязательную конфигурацию для следующих компонентов:

      • Указание шаблона файлов в base_path папке, которая будет отправлена (по умолчанию отправляются все файлы в папке).
      • Указание шаблона файлов в папке base_path , которая не должна быть отправлена.
      • Время и дата, до которого файлы в папке base_path не будут отправлены.
      • Как часто агент приема отправляет файлы (значение, указанное в примере файла конфигурации, соответствует каждому часу).
      • Время урегулирования, которое является периодом времени после последнего изменения файла, которое агент будет ждать до отправки (значение, предоставленное в примере файла конфигурации составляет 5 минут).

      Дополнительные сведения об этих параметрах конфигурации см. в справочнике по конфигурации для оператора Azure Аналитика приема агента.

    • sink. Элементы управления конфигурацией приемника, отправляющие данные в входную учетную запись хранения продукта данных.

      • sas_token В разделе задайте secret_providerkey_vault соответствующий поставщик секретов для продукта данных или используйте значение по умолчанию, если вы использовали имя по умолчанию data_product_keyvault ранее. Оставьте secret_name без изменений.
      • Сведения о необходимых значениях для других параметров см. в документации по продукту данных.

        Внимание

        Поле container_name должно быть задано точно так же, как указано в документации продукта данных.

Запуск программного обеспечения агента

  1. Запустите агент. 
    sudo systemctl start az-aoi-ingestion
  2. Убедитесь, что агент запущен. 
    sudo systemctl status az-aoi-ingestion
    1. Если вы видите любое состояние, отличное active (running)от этого, просмотрите журналы, как описано в разделе "Мониторинг и устранение неполадок агентов приема для оператора Azure" Аналитика, чтобы понять ошибку. Скорее всего, какая-то конфигурация неправильная.
    2. После устранения проблемы повторите попытку запуска агента.
    3. Если проблемы сохраняются, создайте запрос в службу поддержки.
  3. После запуска агента убедитесь, что он запускается автоматически после перезагрузки. 
    sudo systemctl enable az-aoi-ingestion.service

[Необязательно] Настройка сбора журналов для доступа через Azure Monitor

Если вы используете агент приема на виртуальной машине Azure или локальной виртуальной машине, подключенной к Azure Arc, вы можете отправить журналы агента приема в Azure Monitor с помощью агента Azure Monitor. Использование Azure Monitor для доступа к журналам может быть проще, чем доступ к журналам непосредственно на виртуальной машине.

Чтобы собрать журналы агента приема, следуйте документации по Azure Monitor, чтобы установить агент Azure Monitor и настроить коллекцию журналов.

  • Эти документы используют модуль Az PowerShell для создания таблицы журналов. Сначала следуйте документации по установке модуля Az PowerShell.
    • Раздел YourOptionalColumn из примера $tableParams JSON не требуется для агента приема и может быть удален.
  • При добавлении источника данных в правило сбора данных добавьте тип источника с шаблоном Custom Text Logs/var/log/az-aoi-ingestion/stdout.logфайла.
  • Мы также рекомендуем следовать документации, чтобы добавить Linux Syslog источник данных в правило сбора данных, чтобы разрешить аудит всех процессов, выполняемых на виртуальной машине.
  • После добавления правила сбора данных можно запросить журналы агента приема через рабочую область Log Analytics. Используйте следующий запрос, чтобы упростить работу с ними: 
    <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

    Примечание.

    Этот запрос нельзя использовать в качестве преобразования источника данных, так как replace_regex он недоступен в преобразованиях источника данных.

Примеры журналов

[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

Связанный контент

Вы узнаете, как выполнять следующие задачи: