Удалите все экземпляры пакета SDK OpenCensus и экспортера OpenCensus в Azure Monitor из кода.
Проверьте инструкции импорта, начиная с opencensus поиска всех интеграций, экспортеров и экземпляров API Или ПАКЕТА SDK OpenCensus, которые должны быть удалены.
Ниже приведены примеры инструкций импорта, которые необходимо удалить.
from opencensus.ext.azure import metrics_exporter
from opencensus.stats import aggregation as aggregation_module
from opencensus.stats import measure as measure_module
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.trace.samplers import ProbabilitySampler
from opencensus.trace.tracer import Tracer
from opencensus.ext.azure.log_exporter import AzureLogHandler
Шаг 3. Знакомство с API-интерфейсами и пакетами SDK для OpenTelemetry Python
В следующей документации содержатся необходимые знания о API-интерфейсах и пакетах SDK Для OpenTelemetry Python.
OpenTelemetry Python и OpenCensus Python имеют различные поверхности API, возможности автозаполнения и инструкции по подключению.
Шаг 4. Настройка дистрибутива OpenTelemetry в Azure Monitor
Следуйте инструкциям на странице начала работы , чтобы подключиться к дистрибутиву OpenTelemetry в Azure Monitor.
Изменения и ограничения
При переходе с OpenCensus на OpenTelemetry могут возникнуть следующие изменения и ограничения.
Поддержка Python < 3.7
Решения мониторинга на основе Python в OpenTelemetry поддерживают только Python 3.7 и больше, за исключением ранее поддерживаемых версий Python 2.7, 3.4, 3.5 и 3.6 из OpenCensus. Мы рекомендуем обновить пользователей, которые находятся на более старых версиях Python, так как по мере написания этого документа эти версии уже достигли конца жизни. Пользователи, непреклонные по поводу обновления, могут по-прежнему использовать решения OpenTelemetry, но могут найти непредвиденное или критическое поведение, которое не поддерживается. В любом случае последняя поддерживаемая версия opencensus-ext-azure всегда существует и по-прежнему работает для этих версий, но новые выпуски не создаются для этого проекта.
Конфигурации
OpenCensus Python предоставил некоторые параметры конфигурации , связанные с коллекцией и экспортом телеметрии. Вы достигаете одни и те же конфигурации и многое другое с помощью API и пакета SDK Для OpenTelemetry Python . Дистрибутив Python для OpenTelemetry в Azure Monitor является одним стоп-магазином для наиболее распространенных потребностей мониторинга для приложений Python. Так как дистрибутив инкапсулирует API OpenTelemetry/SDk, некоторые конфигурации для более редких вариантов использования в настоящее время не поддерживаются для дистрибутива. Вместо этого вы можете подключиться к экспортеру OpenTelemetry Azure Monitor, который с помощью API и ПАКЕТОВ SDK OpenTelemetry должен соответствовать вашим потребностям мониторинга. Некоторые из этих конфигураций включают:
Пользовательские распространители
Пользовательские примеры
Добавление дополнительных процессоров диапазонов и модулей чтения метрик
Согласованность с Функции Azure
Чтобы предоставить возможности распределенной трассировки для приложений Python, которые вызывают другие приложения Python в функции Azure, пакет opencensus-extension-azure-functions был предоставлен, чтобы разрешить подключенный распределенный граф.
В настоящее время решения OpenTelemetry для Azure Monitor не поддерживают этот сценарий. В качестве обходного решения можно вручную распространить контекст трассировки в приложении функций Azure, как показано в следующем примере.
from opentelemetry.context import attach, detach
from opentelemetry.trace.propagation.tracecontext import \
TraceContextTextMapPropagator
# Context parameter is provided for the body of the function
def main(req, context):
functions_current_context = {
"traceparent": context.trace_context.Traceparent,
"tracestate": context.trace_context.Tracestate
}
parent_context = TraceContextTextMapPropagator().extract(
carrier=functions_current_context
)
token = attach(parent_context)
...
# Function logic
...
detach(token)
Расширения и экспортеры
Пакет SDK OpenCensus предлагает способы сбора и экспорта данных телеметрии с помощью интеграции OpenCensus и экспортеров соответственно. В OpenTelemetry интеграция теперь называется инструментированием, в то время как экспортеры остались с той же терминологией. Инструментирование и экспортеры OpenTelemetry Python являются супермножеством того, что было предоставлено в OpenCensus, поэтому с точки зрения охвата библиотек и функций библиотек OpenTelemetry являются прямым обновлением. Что касается дистрибутива OpenTelemetry в Azure Monitor, он поставляется с некоторыми популярными инструментированиями Python OpenTelemetry из коробки, поэтому дополнительный код не требуется. Корпорация Майкрософт полностью поддерживает эти инструментирования.
Что касается других инструментирования Python OpenTelemetry, которые не включены в этот список, пользователи по-прежнему могут вручную инструментировать с ними. Однако важно отметить, что стабильность и поведение не гарантированы или поддерживаются в этих случаях. Поэтому используйте их по своему усмотрению.
Если вы хотите предложить библиотеку инструментирования сообщества, чтобы включить в наш дистрибутив, пост или up-голосов идею в нашем сообществе отзывов. Для экспортеров дистрибутив Azure Monitor OpenTelemetry поставляется вместе с экспортером OpenTelemetry Azure Monitor. Если вы также хотите использовать других экспортеров, их можно использовать с дистрибутивом, как показано в этом примере.
TelemetryProcessors
Процессоры телеметрии OpenCensus Python — это мощный механизм, в котором пользователи могут изменять данные телеметрии перед отправкой экспортеру. В мире OpenTelemetryProcessors нет концепции telemetryProcessors, но существуют API и классы, которые можно использовать для репликации того же поведения.
Настройка имени облачной роли и экземпляра облачной роли
Следуйте инструкциям здесь, чтобы задать имя облачной роли и экземпляр облачной роли для телеметрии. Дистрибутив Azure Monitor OpenTelemetry автоматически извлекает значения из переменных среды и заполняет соответствующие поля.
Изменение диапазонов с помощью SpanProcessors
Скоро появится.
Изменение метрик с помощью представлений
Скоро появится.
Счетчики производительности
Экспортер Azure Monitor OpenCensus Azure Monitor автоматически собирает системные и связанные с производительностью метрики, называемые счетчиками производительности. Эти метрики отображаются в performanceCounters экземпляре Application Insights. В OpenTelemetry мы больше не отправляем эти метрики явным образом performanceCounters. Метрики, связанные с входящими и исходящими запросами, можно найти в стандартных метриках. Если вы хотите, чтобы OpenTelemetry использовала системные метрики, связанные с системой, можно использовать инструментирование экспериментальных системных метрик, внесенных сообществом Python 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__)
Поддержка
Выберите вкладку для выбранного языка, чтобы узнать параметры поддержки.