Мониторинг и устранение неполадок агентов приема Аналитика оператора Azure

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

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

Агент приема — это программный пакет, поэтому диагностика ограничены работой приложения. Мы не предоставляем мониторинг ОС или ресурсов. Рекомендуется использовать стандартные средства, такие как snmpd, экспортер узлов Prometheus или другие средства для отправки данных, журналов и метрик на собственные системы мониторинга. Мониторинг виртуальных машин с помощью Azure Monitor описывает средства, которые можно использовать, если агенты приема работают на виртуальных машинах Azure.

Агент записывает журналы и метрики в файлы в разделе /var/log/az-aoi-ingestion/. Если агент не удается запустить по какой-либо причине, например неправильной настройки, файл stdout.log содержит журналы, доступные для чтения пользователем, объясняющие проблему.

Метрики передаются в простой понятной для человека форме.

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

• Для большинства этих методов устранения неполадок требуется подключение SSH к виртуальной машине, на котором запущен агент.

Агент приема диагностика

Чтобы собрать пакет диагностика, SSH на виртуальную машину и выполните команду/usr/bin/microsoft/az-aoi-ingestion-gather-diags. Эта команда создает zip-файл с меткой даты в текущем каталоге, который можно скопировать из системы.

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

Примечание.

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

Проблемы, общие для всех источников

Проблемы в целом делятся на четыре категории.

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

Не удается запустить агент

Симптомы: sudo systemctl status az-aoi-ingestion показывает, что служба находится в состоянии сбоя.

• Убедитесь, что служба запущена.

  sudo systemctl start az-aoi-ingestion
  

• Просмотрите файл /var/log/az-aoi-ingestion/stdout.log и проверка для любых обнаруженных ошибок. Исправьте все проблемы с файлом конфигурации и снова запустите агент.

Данные в операторе Azure не отображаются Аналитика

Симптомы: данные не отображаются в Обозреватель данных Azure.

• Проверьте конфигурацию сетевого подключения и брандмауэра между виртуальной машиной агента приема и входной учетной записью хранения продукта данных.
• Проверьте журналы из агента приема ошибок, отправленных в Azure. Если журналы указывают на проблемы с проверкой подлинности, проверка, что конфигурация агента имеет правильные параметры приемника и проверку подлинности для продукта данных. Затем перезапустите агент.
• Убедитесь, что агент приема получает данные из источника. Проверьте конфигурацию сетевого подключения и брандмауэра между сетью и агентом приема.

Проблемы с источником MCC EDR

В этом разделе рассматриваются проблемы, относящиеся к источнику MCC EDR.

Кроме того, вы можете использовать диагностика, предоставляемые MCCs или оператором Azure, Аналитика себя в Azure Monitor, для выявления и отладки проблем приема.

MCC не удается подключиться

Симптомы: MCC сообщает тревоги о недоступности MSFs.

• Убедитесь, что агент запущен.
• Убедитесь, что MCC настроен с правильным IP-адресом и портом.
• Проверьте журналы агента и проверьте, сообщает ли он подключения. В противном случае проверка сетевое подключение к виртуальной машине агента и убедитесь, что брандмауэры не блокируют трафик через порт 36001.
• Соберите запись пакетов, чтобы узнать, где происходит сбой подключения.

Нет EDR, отображаемых в операторе Azure Аналитика

Симптомы: данные не отображаются в Обозреватель данных Azure.

• Убедитесь, что MCC работоспособны и агенты приема выполняются.
• Проверьте журналы агента приема в пакете диагностика для отправки ошибок в Azure. Если журналы указывают на недопустимые строка подключения или проблемы с подключением, исправьте конфигурацию, строка подключения или маркер SAS и перезапустите агент.
• Проверьте конфигурацию сетевого подключения и брандмауэра в учетной записи хранения.

Отсутствующие или неполные данные

Симптомы: Azure Monitor показывает более низкую скорость EDR в ADX, чем ожидалось.

• Убедитесь, что агент работает на всех виртуальных машинах и не сообщает об ошибках в журналах пакетов диагностика.
• Убедитесь, что виртуальные машины агента не отправляются больше, чем оценка нагрузки.
• Проверьте метрики агента в пакете диагностика для удаленных байтов и удаленных EDR. Если метрики не отображают удаленные данные, MCC не отправляет данные агенту. Проверьте метрики "полученные байты", чтобы узнать, сколько данных получено от MCC.
• Убедитесь, что виртуальная машина агента не перегружена, отслеживайте использование ЦП и памяти. В частности, убедитесь, что другой процесс не принимает ресурсы из виртуальной машины.

Проблемы с источником извлечения SFTP

В этом разделе рассматриваются проблемы, связанные с источником извлечения SFTP.

Вы также можете использовать диагностика, предоставляемые оператором Azure, Аналитика себя в Azure Monitor для выявления и отладки проблем приема.

Агент не может подключиться к серверу SFTP

Симптомы: файлы не отправляются в оператор Azure Аналитика. Файл журнала агента / var/log/az-aoi-ingestion/stdout.log содержит ошибки при подключении сервера SFTP.

• Убедитесь, что пользователь SFTP и учетные данные, используемые агентом, действительны для сервера SFTP.
• Проверьте конфигурацию сетевого подключения и брандмауэра между агентом и сервером SFTP. По умолчанию сервер SFTP должен иметь порт 22, открытый для приема подключений SFTP.
• Убедитесь, что known_hosts файл на виртуальной машине агента содержит допустимый открытый ключ SSH для сервера SFTP:
  • На виртуальной машине агента выполните команду ssh-keygen -l -F *<sftp-server-IP-or-hostname>*.
  • Если выходных данных нет, known_hosts то не содержит соответствующую запись. Следуйте инструкциям в разделе "Настройка оператора Azure" Аналитика агента приема, чтобы добавить known_hosts запись для сервера SFTP.

Файлы не отправляются в оператор Azure Аналитика

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

• Убедитесь, что агент работает на всех виртуальных машинах и не сообщает об ошибках в журналах.
• Убедитесь, что файлы существуют в правильном расположении на сервере SFTP и что они не исключаются из-за конфигурации источника файла (см. раздел "Файлы отсутствуют").
• Убедитесь, что настроенный пользователь SFTP может считывать все каталоги под base_pathконфигурацией источника файла.
• Проверьте конфигурацию сетевого подключения и брандмауэра между виртуальной машиной агента приема и входной учетной записью хранения продукта данных.

Отсутствуют файлы

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

• Убедитесь, что агент работает на всех виртуальных машинах и не сообщает об ошибках в журналах. Найдите в журналах пакетов диагностика имя отсутствующих файлов, чтобы найти ошибки, связанные с этим файлом.
• Убедитесь, что файлы существуют на сервере SFTP и что они не исключаются из-за конфигурации источника файла. Проверьте конфигурацию источника файла и убедитесь, что:
  • Файлы существуют на сервере SFTP в пути, заданном в base_path. Убедитесь, что в пути к файлам для отправки нет символьных ссылок: агент приема игнорирует символьные ссылки.
  • Время последнего изменения файлов составляет по крайней мере settling_time секунды раньше, чем время последнего выполнения отправки для этого источника файла.
  • Время последнего изменения файлов будет позже exclude_before_time (если указано).
  • Путь к файлу относительно base_path совпадений регулярного выражения, заданного include_pattern (если указано).
  • Путь к файлу относительно base_pathне соответствует регулярному выражению, заданному exclude_pattern (если указано).
• Если последние файлы отсутствуют, проверка журнал агента в пакете диагностика, чтобы убедиться, что агент приема выполнил отправку для источника в ожидаемое время. Параметр cron в исходной конфигурации предоставляет ожидаемое расписание.
• Убедитесь, что виртуальная машина агента не перегружена, отслеживайте использование ЦП и памяти. В частности, убедитесь, что другой процесс не принимает ресурсы из виртуальной машины.

Файлы отправляются более одного раза

Симптомы: повторяющиеся данные отображаются в Аналитика оператора Azure.

• Проверьте, обнаружена ли повторная ошибка агента приема в журнале пакетов диагностика при предыдущей отправке, а затем повторная отправка более 24 часов после последней успешной отправки. В этом случае агент может отправлять повторяющиеся данные во время попытки повтора. Дублирование данных должно влиять только на попытку повтора.
• Убедитесь, что источники файлов, определенные в файле конфигурации, ссылаются на наборы файлов без переключения. Если несколько источников файлов настроены для извлечения файлов из одного расположения на сервере SFTP, используйте include_pattern поля конфигурации, exclude_pattern чтобы указать различные наборы файлов, которые следует учитывать каждому источнику.
• Если выполняется несколько экземпляров агента приема SFTP, проверка, что источники файлов, настроенные для каждого агента, не перекрываются с источниками файлов на любом другом агенте. В частности, ищите конфигурацию источника файла, которая была случайно скопирована из конфигурации другого агента.
• Если вы недавно изменили конвейер id для настроенного источника файла, используйте exclude_before_time поле, чтобы избежать повторной загрузки файлов с помощью нового конвейера id. Инструкции см. в разделе "Изменение конфигурации для агентов приема" для оператора Azure Аналитика.

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

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

• Изменение конфигурации для агентов приема.
• Обновление агентов приема.
• Смена секретов для агентов приема.