Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается устранение неполадок с OpenTelemetry в Python.
Контрольный список по устранению неполадок
Включить ведение журнала диагностики
Экспортер 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)
...
Тестирование подключения между узлом приложения и службой приема
Пакеты SDK и агенты Application Insights отправляют данные телеметрии для приема в качестве вызовов REST в конечных точках приема. Чтобы проверить подключение с веб-сервера или хост-компьютера приложения к конечным точкам службы приема, используйте команды cURL или необработанные запросы REST из PowerShell. Дополнительные сведения см. в статье "Устранение неполадок с отсутствующими данными телеметрии приложения" в Azure Monitor Application Insights.
Избегайте повторяющихся данных телеметрии
Повторяющиеся данные телеметрии часто вызываются при создании нескольких экземпляров процессоров или экспортеров. Убедитесь, что вы запускаете только один экспортер и процессор за раз для каждого компонента телеметрии (журналы, метрики и распределенная трассировка).
В следующих разделах описаны сценарии, которые могут привести к дублированию данных телеметрии.
Повторяющиеся журналы трассировки в Функции 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 вызовом. Чтобы завершить работу каждого поставщика, выполните вызовы завершения работы для каждого текущего счетчика, трассировщика и поставщика средства ведения журнала, как показано в следующем коде:
get_meter_provider().shutdown()
get_tracer_provider().shutdown()
get_logger_provider().shutdown()
Книги Azure и Записные книжки Jupyter
Книги Azure и Jupyter Notebook могут поддерживать процессы экспорта в фоновом режиме. Чтобы предотвратить дублирование данных телеметрии, очистите кэш перед выполнением дополнительных вызовов configure_azure_monitor.
Отсутствующие данные телеметрии запросов из приложений FastAPI или Flask
Если отсутствуют данные таблицы запросов, но не другие категории данных, платформа HTTP может быть неправильно инструментирована. Эта проблема может возникать в приложениях FastAPI и Flask с помощью клиентской библиотеки Дистрибутива Azure Monitor для Python , если вы неправильно структурируете import объявления. Возможно, вы импортируете fastapi.FastAPI функцию или flask.Flask соответственно перед вызовом configure_azure_monitor функции для инструментирования библиотек FastAPI и Flask. Например, следующий код не успешно инструментирование приложений FastAPI и Flask:
# FastAPI
from azure.monitor.opentelemetry import configure_azure_monitor
from fastapi import FastAPI
configure_azure_monitor()
app = FastAPI()
# Flask
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
Вместо этого рекомендуется импортировать fastapi или flask модули в целом, а затем вызвать configure_azure_monitor настройку OpenTelemetry для использования Azure Monitor перед доступом fastapi.FastAPI или flask.Flask:
# FastAPI
from azure.monitor.opentelemetry import configure_azure_monitor
import fastapi
configure_azure_monitor()
app = fastapi.FastAPI(__name__)
# Flask
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
Кроме того, можно вызвать configure_azure_monitor перед импортом fastapi.FastAPI или flask.Flask:
# FastAPI
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from fastapi import FastAPI
app = FastAPI(__name__)
# Flask
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)