Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info
Пользовательские отчеты позволяют детально изучать конкретные метрики API и просматривать именно те данные, которые вам нужны. На панелях мониторинга API вы можете создать пользовательский отчет с предварительно заданными фильтрами и метриками на основе условий, указанных при создании. Кроме того, в отчете уже настроен набор параметров и метрик по умолчанию .
Создайте пользовательский отчет, учитывающий ваш контекст.
Быстро создавайте пользовательские отчеты в соответствии с вашим контекстом, как показано в следующей таблице. На странице «Пользовательские отчеты» пользовательские отчеты, созданные с помощью мониторинга API, получают уникальные имена (по умолчанию), как указано в таблице; вы можете изменить имя при редактировании пользовательского отчета.
| Пользовательский контекст отчета | Стандартное соглашение об именовании пользовательских отчетов |
|---|---|
| Последние обновления панели мониторинга | API Monitoring Recent Generated |
| Панель мониторинга временной шкалы | API Monitoring Timeline Generated |
| Изучите панель управления | API Monitoring Investigate Generated |
| Состояние тревоги | API Monitoring Generated: alert-name |
Размеры и метрики по умолчанию
По умолчанию пользовательский отчет будет включать параметры и метрики, перечисленные в следующей таблице, для всех отчетов, генерируемых API Monitoring.
| Компонент | По умолчанию |
|---|---|
| Размеры | URI запроса |
| Метрики |
|
Отредактируйте пользовательский отчет
Как упоминалось в предыдущем разделе, в пользовательских отчетах предварительно настроен предопределенный набор параметров и метрик мониторинга API по умолчанию . После создания отчета вы можете редактировать его, добавляя или удаляя метрики и параметры по мере необходимости. Например, вы можете захотеть сузить область исследования до определенного токена доступа, приложения разработчика, API-прокси или идентификатора запроса.
В следующем пользовательском отчете вы добавляете предопределенное измерение Gateway Flow ID , где Gateway Flow ID содержит уникальный UUID каждого запроса API, отправленного в Edge. Обратите внимание, что в отчете уже используется измерение Request URI :
В следующем примере в пользовательский отчет добавляется измерение « Client ID . Измерение Client ID содержит ключ потребителя (ключ API) разработчика, выполняющего вызов API, независимо от того, передан ли он в запросе как ключ API или включен в токен OAuth:
Пользовательский отчет содержит информацию по всем значениям Client ID . В следующем примере добавлен фильтр, позволяющий создать пользовательский отчет для конкретного Client ID :
Для получения более подробной информации обо всех предопределенных измерениях и показателях, которые можно добавить в отчет, см. справочник по показателям, измерениям и фильтрам аналитики .
В следующем примере вы добавляете фильтр в пользовательский отчет, который фиксирует метрики и параметры по умолчанию для кода ошибки policies.ratelimit.QuotaViolation и кодов состояния 5xx:
Подробную информацию о редактировании пользовательского отчета см. в разделе «Управление пользовательскими отчетами» .
Пример: Используйте пользовательские отчеты для диагностики проблем развертывания.
Прикрепите политику StatisticsCollector к вашим API-прокси, чтобы собирать пользовательские аналитические данные, такие как идентификатор пользователя или продукта, цена, REST-действие, целевая версия, целевой URL и длина сообщения. Данные могут поступать из переменных потока, предопределенных Apigee, заголовков запроса, параметров запроса или пользовательских переменных, которые вы определяете.
Например, запросы к вашему API-прокси включают заголовки с идентификатором продукта, идентификатором пользователя и версией целевого сервера. Этот запрос может иметь следующий вид:
curl -H "prodid:123456" -H "userid:98765" -H "targetversion:beta" http://myapi.com/myapi
Затем вы можете использовать информацию из заголовков для диагностики проблем, возникающих во время выполнения вашего API-прокси.
Чтобы создать пользовательский отчет с этими заголовками:
Добавьте политику StatisticsCollector к вашему API, чтобы получать значения пользовательских заголовков:
<StatisticsCollector name="publishPurchaseDetails"> <Statistics> <Statistic name="prodid" ref="request.header.prodid" type="integer">0</Statistic> <Statistic name="userid" ref="request.header.userid" type="integer">0</Statistic> <Statistic name="targetversion" ref="request.header.targetversion" type="string">alpha</Statistic> </Statistics> </StatisticsCollector>
Разверните свой прокси-сервер и дайте время для его доступа.
Чтобы просмотреть проблемы с вашим API, нажмите «Анализировать» > «Мониторинг API» > «Недавние» в пользовательском интерфейсе Edge. Обратите внимание, что вы получаете ошибки 4xx и 5xx для прокси-сервера myapi :
Выберите строку myapi proxy, чтобы просмотреть более подробную информацию в правой панели панели мониторинга «Недавние».
В правой панели панели «Недавние» выберите
> Чтобы получить доступ к панели мониторинга Investigate, перейдите в раздел «Просмотр» :
Отфильтруйте панель мониторинга Investigate по прокси-серверу myapi , а затем просмотрите коды состояния на верхнем графике. Обратите внимание, что вы получаете ошибки 403 и 501:
В пользовательском интерфейсе Edge выберите «Аналитика» > «Пользовательские отчеты» > «Отчеты» , чтобы создать пользовательский отчет, который будет включать значения этих пользовательских метрик в качестве измерения.
Выберите + Пользовательский отчет , чтобы создать пользовательский отчет с именем myapi_errors .
В качестве метрики выберите «Ошибки прокси» и установите функцию агрегирования на «Сумма» . При желании можно добавить и другие метрики.
Выберите предопределенное измерение «Код состояния ответа» , а затем добавьте три пользовательских статистических параметра: prodid , targetersion и userid в раздел «Измерения»:
Установите фильтр таким образом, чтобы он включал только данные для прокси-сервера API myapi
(apiproxy eq 'myapi'):
Сохраните отчёт.
Запустите отчет за предыдущие 24 часа. При первом открытии отчета вы увидите диаграмму ошибок HTTP 403 и 501:
В разделе «Сводка» нажмите на код ошибки 403 или 510 , чтобы узнать, какой продукт вызывает ошибки. Например, выберите 403 :
Щелкните идентификатор продукта в разделе «Сводка» , чтобы просмотреть ошибки по целевой версии (альфа или бета):
Чтобы просмотреть ошибки по пользователям, щелкните целевую версию в разделе «Сводка» :
