Antipadrão: adicionar informações personalizadas ao esquema da Apigee no banco de dados do Postgres

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

O recurso de análise da API Edge é um recurso integrado fornecido pelo Apigee Edge. Ele coleta e analisa um amplo espectro de dados que fluem pelas APIs. Os dados de análise capturados podem fornecer insights muito úteis. Por exemplo, qual é a tendência do volume de tráfego da API durante um período? Qual é a API mais usada? Quais APIs estão tendo altas taxas de erro?

A análise regular desses dados e insights pode ser usada para tomar as medidas adequadas, como o planejamento da capacidade futura de APIs com base no uso atual, decisões de negócios e investimentos futuros, e muito mais.

Dados analíticos e seu armazenamento

A API Analytics captura muitos tipos diferentes de dados, como:

  • Informações sobre uma API: URI de solicitação, endereço IP do cliente, códigos de status de resposta etc.
  • Desempenho do proxy de API: taxa de sucesso/falha, tempo de processamento de solicitações e respostas etc.
  • Meta de desempenho do servidor: taxa de sucesso/falha, tempo de processamento
  • Informações de erros: número de erros, código de falha, política com falha, número de Apigee e servidor de destino causados por erros.
  • Outras informações: número de solicitações feitas por desenvolvedores, apps de desenvolvedores, entre outros

Todos esses dados são armazenados em um esquema analytics criado e gerenciado em um banco de dados do Postgres pelo Apigee Edge.

Normalmente, em uma instalação vanilla Edge, o Postgres tem os seguintes schemata:

O esquema chamado analytics é usado pelo Edge para armazenar todos os dados de análise de cada organização e ambiente. Se a monetização estiver instalada, haverá um esquema rkms. Outros schemata são destinados a componentes internos do Postgres.

O esquema analytics continuará mudando, já que o Apigee Edge adicionará dinamicamente novas tabelas de fatos a ele no ambiente de execução. O componente de servidor Postgres agrega os dados de fatos em tabelas de agregação, que são carregadas e exibidas na interface do Edge.

Antipadrão

Não é aconselhável adicionar colunas, tabelas e/ou visualizações personalizadas a qualquer um dos schemata de propriedade da Apigee no banco de dados Postgres em ambientes de nuvem privada usando diretamente consultas SQL, porque isso pode ter implicações adversas.

Vejamos um exemplo para explicar isso em detalhes.

Imagine que uma tabela personalizada chamada account foi criada no esquema de análise, conforme mostrado abaixo:

Depois de um tempo, digamos que seja necessário fazer upgrade do Apigee Edge de uma versão anterior para uma mais recente. O upgrade da Apigee Edge para a nuvem privada envolve o upgrade do Postgres, entre muitos outros componentes. Se houver colunas, tabelas ou visualizações personalizadas adicionadas ao banco de dados do Postgres, o upgrade do Postgres falhará com erros ao referenciar os objetos personalizados porque eles não são criados pelo Apigee Edge. Assim, o upgrade do Apigee Edge também falha e não pode ser concluído.

Da mesma forma, podem ocorrer erros durante as atividades de manutenção do Apigee Edge, em que são executados o backup e a restauração de componentes do Edge, incluindo o banco de dados do Postgres.

Impacto

  • Não foi possível concluir o upgrade do Apigee Edge porque o upgrade do componente Postgres falha com erros referentes a objetos personalizados não criados pelo Apigee Edge.
  • Inconsistências (e falhas) durante a manutenção do serviço da Apigee Analytics (backup/restauração).

Prática recomendada

  • Não adicione informações personalizadas na forma de colunas, tabelas, visualizações, funções e procedimentos diretamente a qualquer esquema de propriedade da Apigee, como analytics e assim por diante
  • Se for necessário oferecer suporte a informações personalizadas, elas poderão ser adicionadas como colunas (campos) usando uma política do coletor de estatísticas ao esquema analytics.

Leia mais