Você está lendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. info
O Edge API Analytics é um recurso integrado muito poderoso 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 em um período? Qual é a API mais usada? Quais APIs têm altas taxas de erro?
A análise regular desses dados e insights pode ser usada para tomar ações adequadas, como o planejamento de capacidade futura de APIs com base no uso atual, decisões de negócios e investimentos futuros, e muito mais.
Dados de análise e armazenamento
O 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 da resposta e assim por diante.
- Desempenho do proxy de API: taxa de sucesso/falha, tempo de processamento de solicitação e resposta e assim por diante.
- Desempenho do servidor de destino: taxa de sucesso/falha, tempo de processamento.
- Informações de erro: número de erros, código de falha, política com falha, número de erros causados pelo servidor de destino e da Apigee.
- Outras informações: número de solicitações feitas por desenvolvedores, apps de desenvolvedores e assim por diante.
Todos esses dados são armazenados em um analytics esquema criado e gerenciado em um
banco de dados Postgres pelo Apigee Edge.
Normalmente, em uma instalação padrão do Edge, o Postgres tem 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 rkms
esquema. Outros esquemas são destinados a internos do Postgres.
O esquema analytics vai mudar à medida que o Apigee Edge adicionar dinamicamente novas tabelas de fatos
a ele no momento da execução. O componente do servidor Postgres vai agregar 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 nenhum dos esquemas de propriedade da Apigee no banco de dados Postgres em ambientes de nuvem privada diretamente 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 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 mais recente versão. O upgrade do Apigee Edge da nuvem privada envolve o upgrade do Postgres entre muitos outros componentes. Se houver colunas, tabelas ou visualizações personalizadas adicionadas ao banco de dados Postgres, o upgrade do Postgres falhará com erros que fazem referência aos objetos personalizados, já que eles não são criados por 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 dos 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 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 nenhum dos esquemas de propriedade da Apigee, como
analyticse assim por diante. - Se houver necessidade de 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.