Вы просматриваете документацию по Apigee Edge.
Перейдите к документации по Apigee X. info
Edge API Analytics – это мощная встроенная функция, предоставляемая Apigee Edge. Она собирает и анализирует широкий спектр данных, передаваемых через API. Собранные аналитические данные могут дать очень полезную информацию. Например, как меняется объем трафика API за определенный период времени? Какой API используется чаще всего? Какие API имеют высокий уровень ошибок?
Регулярный анализ этих данных и статистики позволяет принимать обоснованные решения, например планировать будущую емкость API на основе текущего использования, а также принимать бизнес-решения и решения об инвестициях.
Данные Аналитики и их хранение
API Analytics собирает различные типы данных, например:
- Информация об API: URI запроса, IP-адрес клиента, коды статуса ответа и т. д.
- Эффективность прокси-сервера API – доля успешных и неудачных запросов, время обработки запросов и ответов и т. д.
- Производительность целевого сервера – доля успешных/неудачных запросов, время обработки
- Информация об ошибке – количество ошибок, код ошибки, невыполненное правило, количество ошибок, вызванных сервером Apigee и целевым сервером.
- Другая информация – количество запросов, сделанных разработчиками, приложениями разработчиков и т. д.
Все эти данные хранятся в analytics схеме, созданной и управляемой в базе данных Postgres с помощью Apigee Edge.
Обычно в стандартной установке Edge Postgres имеет следующие схемы:
Схема analytics используется Edge для хранения всех данных аналитики для каждой организации и среды. Если монетизация установлена, будет схема rkms. Другие схемы предназначены для внутренних компонентов Postgres.
Схема analytics будет постоянно меняться, поскольку Apigee Edge будет динамически добавлять в нее новые таблицы фактов во время выполнения. Компонент сервера Postgres будет агрегировать данные фактов в сводные таблицы, которые загружаются и отображаются в новом интерфейсе Edge.
Антипаттерн
Добавлять специальные столбцы, таблицы и/или представления в любые схемы, принадлежащие Apigee, в базе данных Postgres в средах Private Cloud напрямую с помощью SQL-запросов не рекомендуется, поскольку это может иметь неблагоприятные последствия.
Рассмотрим пример.
Предположим, что в схеме аналитики создана специальная таблица account, как показано ниже:
Через некоторое время, допустим, возникнет необходимость обновить Apigee Edge с более низкой версии до более высокой. При обновлении Apigee Edge Private Cloud, помимо прочих компонентов, обновляется Postgres. Если в базу данных Postgres добавлены специальные столбцы, таблицы или представления, то обновление Postgres завершится ошибкой со ссылкой на специальные объекты, поскольку они не созданы Apigee Edge. Поэтому обновление Apigee Edge также завершается сбоем и не может быть завершено.
Аналогичные ошибки могут возникать во время обслуживания Apigee Edge, когда выполняется резервное копирование и восстановление компонентов Edge, включая базу данных Postgres.
Результат
- Не удается завершить обновление Apigee Edge, поскольку обновление компонента Postgres завершается с ошибками, связанными с пользовательскими объектами, не созданными Apigee Edge.
- Несоответствия и сбои при обслуживании сервиса Apigee Analytics (резервное копирование и восстановление).
Рекомендации
- Не добавляйте в принадлежащие Apigee схемы, например
analytics, пользовательскую информацию в виде столбцов, таблиц, представлений, функций и процедур. - Если вам нужно поддерживать пользовательскую информацию, ее можно добавить в виде столбцов (полей), используя правило Statistics Collector для схемы
analytics.