Você está visualizando a documentação do Apigee Edge.
Acesse a
documentação da
Apigee X. info
A análise de APIs do Edge é um recurso integrado muito eficiente fornecido pelo Apigee Edge. Ele coleta e analisa um amplo espectro de dados que fluem entre APIs. Os dados de análise coletados podem fornecer insights muito úteis. Por exemplo, qual é a tendência do volume de tráfego da API ao longo de um período? Qual é a API mais usada? Quais APIs estão com taxas de erro altas?
A análise regular desses dados e insights pode ser usada para tomar medidas adequadas, como o planejamento de capacidade de APIs com base no uso atual, nas decisões de investimento de negócios e futuras, e muito mais.
Dados do Google Analytics e armazenamento
O API Analytics captura muitos tipos diferentes de dados, como:
- Informações sobre uma API: URI da solicitação, endereço IP do cliente, códigos de status da resposta e assim por diante
- Desempenho do proxy de API: taxa de sucesso/falha, tempo de processamento de solicitações e respostas etc.
- Desempenho do servidor de destino: taxa de sucesso/falha e tempo de processamento
- Informações de erro: número de erros, código de falha, política de falha, número de erros causados pelo Apigee e pelo servidor de destino.
- Outras informações: número de solicitações feitas por desenvolvedores, apps para desenvolvedores etc.
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 simples do Edge, o Postgres terá os seguintes esquemas:
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 esquemas são destinados a elementos internos do Postgres.
O esquema analytics vai continuar mudando, já que o Apigee Edge vai adicionar dinamicamente novas tabelas de fatos a ele no momento da execução. O componente do servidor Postgres agrega os dados de fatos em tabelas agregadas, que são carregadas e exibidas na interface do Edge.
Antipadrão
Não é recomendável adicionar colunas, tabelas e/ou visualizações personalizadas a qualquer um dos esquemas pertencentes à Apigee no banco de dados do Postgres em ambientes de nuvem particular usando consultas SQL, porque isso pode ter implicações adversas.
Vamos usar um exemplo para explicar isso em detalhes.
Considere uma tabela personalizada chamada account que 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 mais antiga para uma versão mais recente. Fazer upgrade do 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 vai falhar com erros que fazem referência aos objetos personalizados, já que 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, erros podem ocorrer durante as atividades de manutenção do Apigee Edge, em que o backup e a restauração de componentes do Edge, incluindo o banco de dados Postgres, são realizados.
Impacto
- O upgrade do Apigee Edge não pode ser concluído porque o upgrade do componente do Postgres falha com erros que fazem referência a objetos personalizados não criados pelo Apigee Edge.
- Inconsistências (e falhas) ao realizar a manutenção do serviço do 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 um dos esquemas de propriedade da Apigee, como
analyticse 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.