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