Антипаттерн: добавление пользовательской информации в схему, принадлежащую Apigee, в базе данных Postgres.

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

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 в средах частного облака непосредственно с помощью SQL-запросов не рекомендуется, поскольку это может иметь неблагоприятные последствия.

Давайте рассмотрим пример, чтобы объяснить это подробно.

Предположим, что пользовательская таблица с именем account была создана в соответствии со схемой аналитики, как показано ниже:

Допустим, через некоторое время возникла необходимость обновить Apigee Edge с более низкой версии на более высокую. Обновление частного облака Apigee Edge включает обновление Postgres среди многих других компонентов. Если в базу данных Postgres добавлены какие-либо настраиваемые столбцы, таблицы или представления, обновление Postgres завершится неудачей с ошибками, ссылающимися на настраиваемые объекты, поскольку они не созданы Apigee Edge. Таким образом, обновление Apigee Edge также завершается сбоем и не может быть завершено.

Аналогичным образом ошибки могут возникать во время операций по обслуживанию Apigee Edge, когда выполняются резервное копирование и восстановление компонентов Edge, включая базу данных Postgres.

Влияние

  • Обновление Apigee Edge не может быть завершено, поскольку обновление компонента Postgres завершается сбоем с ошибками, ссылающимися на пользовательские объекты, не созданные Apigee Edge.
  • Несоответствия (и сбои) при выполнении обслуживания службы Apigee Analytics (резервное копирование/восстановление).

Лучшая практика

  • Не добавляйте какую-либо пользовательскую информацию в виде столбцов, таблиц, представлений, функций и процедур непосредственно в любую схему, принадлежащую Apigee, такую ​​как analytics и т. д.
  • Если необходимо поддерживать пользовательскую информацию, ее можно добавить в виде столбцов (полей) с помощью политики сборщика статистики в схему analytics .

Дальнейшее чтение

,

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

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 в средах частного облака непосредственно с помощью SQL-запросов не рекомендуется, поскольку это может иметь неблагоприятные последствия.

Давайте рассмотрим пример, чтобы объяснить это подробно.

Предположим, что пользовательская таблица с именем account была создана в соответствии со схемой аналитики, как показано ниже:

Допустим, через некоторое время возникла необходимость обновить Apigee Edge с более низкой версии на более высокую. Обновление частного облака Apigee Edge включает обновление Postgres среди многих других компонентов. Если в базу данных Postgres добавлены какие-либо настраиваемые столбцы, таблицы или представления, обновление Postgres завершится неудачей с ошибками, ссылающимися на настраиваемые объекты, поскольку они не созданы Apigee Edge. Таким образом, обновление Apigee Edge также завершается сбоем и не может быть завершено.

Аналогичным образом ошибки могут возникать во время операций по обслуживанию Apigee Edge, когда выполняются резервное копирование и восстановление компонентов Edge, включая базу данных Postgres.

Влияние

  • Обновление Apigee Edge не может быть завершено, поскольку обновление компонента Postgres завершается неудачно с ошибками, ссылающимися на пользовательские объекты, не созданные Apigee Edge.
  • Несоответствия (и сбои) при выполнении обслуживания службы Apigee Analytics (резервное копирование/восстановление).

Лучшая практика

  • Не добавляйте какую-либо пользовательскую информацию в виде столбцов, таблиц, представлений, функций и процедур непосредственно в любую схему, принадлежащую Apigee, например analytics и т. д.
  • Если необходимо поддерживать пользовательскую информацию, ее можно добавить в виде столбцов (полей) с помощью политики сборщика статистики в схему analytics .

Дальнейшее чтение