Автоинструментация позволяет собирать данные телеметрии с помощью конфигурации, не касаясь кода приложения. Хотя это удобнее, он, как правило, менее настраивается. Он также недоступен во всех языках. См. сведения о поддерживаемых средах и языках автоинструментации. Когда автоинструментация доступна, это самый простой способ включить Azure Monitor Application Insights.
Инструментирование вручную предназначено для API Application Insights или OpenTelemetry. В контексте пользователя обычно это относится к установке пакета SDK для конкретного языка в приложении. Это означает, что вам нужно самостоятельно управлять обновлениями последней версии пакета. Этот параметр можно использовать, если требуется выполнять пользовательские вызовы зависимостей или вызовы API, которые не записываются по умолчанию с автоинструментацией. Существует два варианта ручного инструментирования:
Хотя мы видим OpenTelemetry в качестве нашего будущего направления, у нас нет планов прекратить сбор данных из старых пакетов SDK. У нас по-прежнему есть способ достичь паритета функций с пакетами SDK Application Insights для Azure OpenTelemetry. Во многих случаях клиенты продолжают использовать пакеты SDK Application Insights в течение некоторого времени.
Телеметрия — данные, собираемые для наблюдения за приложением, можно разделить на три типа или основных элемента:
Распределенная трассировка
Метрики
Журналы
Полная история наблюдаемости включает в себя все три основных аспекта, а Application Insights дополнительно разбивает эти основы на таблицы на основе нашей модели данных. Наши пакеты SDK Application Insights или дистрибутивы OpenTelemetry Azure Monitor включают все, что необходимо для работы с приложением Монитор производительности в Azure. Сам пакет является бесплатным для установки, и вы платите только за данные, которые вы используете в Azure Monitor.
Следующие источники объясняют три основных принципа:
Наблюдаемость распределенных систем с помощью Синди Сридхарана
Маршрутизация телеметрии
Существует два способа отправки данных в Azure Monitor (или любой поставщик):
Через прямой экспортер
Через агент
Прямой экспортер отправляет данные телеметрии (из кода приложения) непосредственно в конечную точку приема Azure Monitor. Основное преимущество такого подхода заключается в простоте адаптации.
Доступные в настоящее время пакеты SDK Application Insights и дистрибутивы OpenTelemetry Azure Monitor зависят от прямого экспортера.
Примечание.
Сведения о позиции Azure Monitor в Сборщике OpenTelemetry см. в разделе "Вопросы и ответы о OpenTelemetry".
Совет
Если вы планируете использовать OpenTelemetry-Collector для выборки или дополнительной обработки данных, вы можете получить эти же возможности, встроенные в Azure Monitor. Клиенты, перенесенные в Application Insights на основе рабочей области, могут воспользоваться преобразованиями во время приема. Чтобы включить, следуйте инструкциям в руководстве, пропустив шаг, показывающий, как настроить параметр диагностики, так как с помощью Application Insights, ориентированного на рабочую область, это уже настроено. Если вы фильтруете менее 50% общего объема, это не требует дополнительных затрат. После 50 %, есть стоимость, но гораздо меньше, чем стандартная плата за ГБ.
OpenTelemetry
Корпорация Майкрософт рада использовать OpenTelemetry для современного инструментирования телеметрии. Вы, наши клиенты, попросили поставщиков инструментирования, и мы рады сотрудничать с сообществом OpenTelemetry для создания согласованных API и пакетов SDK на разных языках.
Корпорация Майкрософт работала с заинтересованными лицами проекта из двух ранее популярных проектов телеметрии с открытым кодом, OpenCensus и OpenTracing. Вместе мы помогли создать один проект OpenTelemetry. OpenTelemetry включает в себя вклад всех основных поставщиков облачных и управления производительностью приложений (APM) и живет в Cloud Native Computing Foundation (CNCF). Корпорация Майкрософт является платиновым членом CNCF.
Терминология см . в глоссарии в спецификациях OpenTelemetry.
Некоторые устаревшие термины в Application Insights запутаны из-за конвергенции отрасли в OpenTelemetry. В следующей таблице рассматриваются эти различия. Термины OpenTelemetry заменяют термины Application Insights.
Application Insights
OpenTelemetry
Автоколекторы
Библиотеки инструментирования
Канал
Экспортер
Без агента и на основе агента
Автоинструментация
Трассировки
Журналы
Запросы
Диапазоны серверов
Зависимости
Другие типы диапазонов (клиент, внутренний и т. д.)
Идентификатор операции
Идентификатор трассировки
Идентификатор или родительский идентификатор операции
Экспортер Azure Monitor использует EventSource для внутреннего ведения журнала. Журналы экспортера доступны любому EventListener, выбрав источник, который называется OpenTelemetry-AzureMonitor-Exporter. Инструкции по устранению неполадок см. в разделе "Устранение неполадок OpenTelemetry" на сайте GitHub.
Шаг 2. Тестирование подключения между узлом приложения и службой приема
Пакеты SDK и агенты Application Insights отправляют данные телеметрии для приема в качестве вызовов REST в конечных точках приема. Чтобы проверить подключение с веб-сервера или хост-компьютера приложения к конечным точкам службы приема, используйте команды cURL или необработанные запросы REST из PowerShell. Дополнительные сведения см. в статье "Устранение неполадок с отсутствующими данными телеметрии приложения" в Azure Monitor Application Insights.
Известные проблемы
Ниже перечислены известные проблемы для экспортеров OpenTelemetry в Azure Monitor:
Имя операции отсутствует в телеметрии зависимостей. Отсутствует имя операции приводит к сбоям и негативно влияет на работу вкладки производительности.
Модель устройства отсутствует в телеметрии запросов и зависимостей. Недостающая модель устройства негативно влияет на анализ когорты устройств.
Шаг 1. Включение ведения журнала диагностики
Экспортер Azure Monitor использует EventSource для внутреннего ведения журнала. Журналы экспортера доступны любому EventListener, выбрав источник, который называется OpenTelemetry-AzureMonitor-Exporter. Инструкции по устранению неполадок см. в разделе "Устранение неполадок OpenTelemetry" на сайте GitHub.
Шаг 2. Тестирование подключения между узлом приложения и службой приема
Пакеты SDK и агенты Application Insights отправляют данные телеметрии для приема в качестве вызовов REST в конечных точках приема. Чтобы проверить подключение с веб-сервера или хост-компьютера приложения к конечным точкам службы приема, используйте команды cURL или необработанные запросы REST из PowerShell. Дополнительные сведения см. в статье "Устранение неполадок с отсутствующими данными телеметрии приложения" в Azure Monitor Application Insights.
Известные проблемы
Ниже перечислены известные проблемы для экспортеров OpenTelemetry в Azure Monitor:
Имя операции отсутствует в телеметрии зависимостей. Отсутствует имя операции приводит к сбоям и негативно влияет на работу вкладки производительности.
Модель устройства отсутствует в телеметрии запросов и зависимостей. Недостающая модель устройства негативно влияет на анализ когорты устройств.
Шаг 2. Тестирование подключения между узлом приложения и службой приема
Пакеты SDK и агенты Application Insights отправляют данные телеметрии для приема в качестве вызовов REST в конечных точках приема. Чтобы проверить подключение с веб-сервера или хост-компьютера приложения к конечным точкам службы приема, используйте команды cURL или необработанные запросы REST из PowerShell. Дополнительные сведения см. в статье "Устранение неполадок с отсутствующими данными телеметрии приложения" в Azure Monitor Application Insights.
Примеры вызовов команд применяются к Application Insights для Java версии 3.4.11. Сведения о том, как найти номер версии и URL-адрес текущего выпуска Application Insights для Java, см. в статье https://github.com/microsoft/ApplicationInsights-Java/releases.
Следующие шаги применимы к собственным приложениям Spring Boot.
Шаг 1. Проверка версии OpenTelemetry
Во время запуска приложения может появиться следующее сообщение:
WARN c.a.m.a.s.OpenTelemetryVersionCheckRunner - The OpenTelemetry version is not compatible with the spring-cloud-azure-starter-monitor dependency.
The OpenTelemetry version should be <version>
В этом случае необходимо импортировать счета за материалы OpenTelemetry, следуя документации По OpenTelemetry в начальном средстве Spring Boot.
Шаг 2. Включение самостоятельного диагностика
Если что-то не работает должным образом, вы можете включить самостоятельное диагностика на уровне, чтобы получить некоторые DEBUG аналитические сведения. Для этого задайте для самостоятельного диагностика уровень ERROR, WARNили TRACEINFODEBUGс помощью переменной APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL среды.
Чтобы включить самостоятельную диагностика на DEBUG уровне при запуске контейнера Docker, выполните следующую команду:
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
Примечание.
Замените <image-name> соответствующим образом имя образа Docker.
Заявление об отказе от ответственности за сведения о продуктах сторонних производителей
В этой статье упомянуты программные продукты независимых производителей. Корпорация Microsoft не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.
Шаг 1. Включение ведения журнала диагностики
Экспортер Azure Monitor использует средство ведения журнала API OpenTelemetry для внутренних журналов. Чтобы включить средство ведения журнала, выполните следующий фрагмент кода:
Шаг 2. Тестирование подключения между узлом приложения и службой приема
Пакеты SDK и агенты Application Insights отправляют данные телеметрии для приема в качестве вызовов REST в конечных точках приема. Чтобы проверить подключение с веб-сервера или хост-компьютера приложения к конечным точкам службы приема, используйте команды cURL или необработанные запросы REST из PowerShell. Дополнительные сведения см. в статье "Устранение неполадок с отсутствующими данными телеметрии приложения" в Azure Monitor Application Insights.
Известные проблемы
Ниже перечислены известные проблемы для экспортеров OpenTelemetry в Azure Monitor:
Имя операции отсутствует в телеметрии зависимостей. Отсутствует имя операции приводит к сбоям и негативно влияет на работу вкладки производительности.
Модель устройства отсутствует в телеметрии запросов и зависимостей. Недостающая модель устройства негативно влияет на анализ когорты устройств.
Имя сервера базы данных отсутствует в имени зависимости. Так как имя сервера базы данных не включено, Средства экспорта OpenTelemetry неправильно агрегируют таблицы с одинаковыми именами на разных серверах.
Шаг 1. Включение ведения журнала диагностики
Экспортер Microsoft Azure Monitor использует стандартную библиотеку ведения журналов Python для внутреннего ведения журнала. API OpenTelemetry и журналы экспортера Azure Monitor назначают уровень WARNING серьезности или ERROR для нерегулярных действий. Уровень INFO серьезности используется для регулярного или успешного действия.
По умолчанию библиотека ведения журнала Python задает уровень WARNINGсерьезности. Поэтому необходимо изменить уровень серьезности, чтобы просмотреть журналы в этом параметре серьезности. В следующем примере кода показано, как выводить журналы всех уровней серьезности в консоль и файл:
Шаг 2. Тестирование подключения между узлом приложения и службой приема
Пакеты SDK и агенты Application Insights отправляют данные телеметрии для приема в качестве вызовов REST в конечных точках приема. Чтобы проверить подключение с веб-сервера или хост-компьютера приложения к конечным точкам службы приема, используйте команды cURL или необработанные запросы REST из PowerShell. Дополнительные сведения см. в статье "Устранение неполадок с отсутствующими данными телеметрии приложения" в Azure Monitor Application Insights.
Шаг 3. Избегайте дублирования телеметрии
Повторяющиеся данные телеметрии часто вызываются при создании нескольких экземпляров процессоров или экспортеров. Убедитесь, что вы запускаете только один экспортер и процессор за раз для каждого компонента телеметрии (журналы, метрики и распределенная трассировка).
В следующих разделах описаны сценарии, которые могут привести к дублированию данных телеметрии.
Повторяющиеся журналы трассировки в Функции Azure
Если вы видите пару записей для каждого журнала трассировки в Application Insights, вероятно, вы включили следующие типы инструментирования ведения журнала:
Встроенная инструментирование ведения журнала в Функции Azure
Инструментирование azure-monitor-opentelemetry ведения журнала в дистрибутиве
Чтобы предотвратить дублирование, можно отключить ведение журнала дистрибутива, но оставить собственный инструмент ведения журнала в Функции Azure включен. Для этого задайте для переменной OTEL_LOGS_EXPORTER среды значение None.
Повторяющиеся данные телеметрии в Функции Azure AlwaysOn
Если параметр AlwaysOn в Функции Azure имеет значение On, Функции Azure сохраняет некоторые процессы, выполняемые в фоновом режиме после завершения каждого запуска. Например, предположим, что у вас есть пятиминутная функция таймера, которая вызывается configure_azure_monitor каждый раз. Через 20 минут у вас могут быть четыре экспортера метрик, которые работают одновременно. Эта ситуация может быть источником данных телеметрии повторяющихся метрик.
В этой ситуации задайте для параметра AlwaysOn значение Off или попробуйте вручную завершить работу поставщиков между каждым configure_azure_monitor вызовом. Чтобы завершить работу каждого поставщика, выполните вызовы завершения работы для каждого текущего счетчика, трассировщика и поставщика средства ведения журнала, как показано в следующем коде:
Книги Azure и Jupyter Notebook могут поддерживать процессы экспорта в фоновом режиме. Чтобы предотвратить дублирование данных телеметрии, очистите кэш перед выполнением дополнительных вызовов configure_azure_monitor.
Шаг 4. Убедитесь, что данные запроса Flask собираются
Если вы реализуете приложение Flask, вы можете обнаружить, что вы не можете собирать данные таблицы запросов из Application Insights при использовании клиентской библиотеки Azure Monitor OpenTelemetry Distro для Python. Эта проблема может возникнуть, если вы неправильно структурируете import объявления. Вы можете импортировать платформу flask.Flask веб-приложения перед вызовом configure_azure_monitor функции для инструментирования библиотеки Flask. Например, следующий код не успешно инструментирование приложения Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
Вместо этого рекомендуется импортировать flask модуль в целом, а затем вызвать configure_azure_monitor настройку OpenTelemetry для использования Azure Monitor перед доступом flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
Кроме того, можно вызвать configure_azure_monitor перед импортом flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)
Поддержка
Выберите вкладку для выбранного языка, чтобы узнать параметры поддержки.