Устранение неполадок с OpenTelemetry в Python
В этой статье описывается устранение неполадок с OpenTelemetry в Python.
Контрольный список для устранения неполадок
Шаг 1. Включение ведения журнала диагностики
Экспортер Microsoft Azure Monitor использует стандартную библиотеку ведения журналов Python для внутреннего ведения журнала. Журналам API OpenTelemetry и экспортера Azure Monitor назначается уровень WARNING
серьезности или ERROR
за нерегулярную активность. Уровень INFO
серьезности используется для регулярных или успешных действий.
По умолчанию библиотека ведения журналов Python задает уровень серьезности в WARNING
. Поэтому необходимо изменить уровень серьезности, чтобы просмотреть журналы в этом параметре серьезности. В следующем примере кода показано, как выводить журналы всех уровней серьезности в консоль и файл:
...
import logging
logging.basicConfig(format = "%(asctime)s:%(levelname)s:%(message)s", level = logging.DEBUG)
logger = logging.getLogger(__name__)
file = logging.FileHandler("example.log")
stream = logging.StreamHandler()
logger.addHandler(file)
logger.addHandler(stream)
...
Шаг 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 "Always On"
Если параметр Always On в Функции Azure имеет значение Включено, Функции Azure сохраняет некоторые процессы, выполняемые в фоновом режиме после завершения каждого запуска. Например, предположим, что у вас есть пятиминутная функция таймера, которая вызывает configure_azure_monitor
каждый раз. Через 20 минут может появиться четыре экспортера метрик, которые будут работать одновременно. Эта ситуация может быть источником телеметрии повторяющихся метрик.
В этом случае задайте для параметра Always On значение Выкл. или попробуйте вручную завершить работу поставщиков между каждым configure_azure_monitor
вызовом. Чтобы завершить работу каждого поставщика, выполните вызовы завершения работы для каждого текущего счетчика, трассировщика и поставщика средства ведения журнала, как показано в следующем коде:
get_meter_provider().shutdown()
get_tracer_provider().shutdown()
get_logger_provider().shutdown()
Книги Azure и записные книжки Jupyter Notebook
Книги Azure и записные книжки Jupyter Notebook могут поддерживать процессы экспорта в фоновом режиме. Чтобы предотвратить дублирование данных телеметрии, очистите кэш перед выполнением дополнительных вызовов к configure_azure_monitor
.
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по