Anti-pattern: aggiungi informazioni personalizzate allo schema di proprietà di Apigee nel database Postgres

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info

Edge API Analytics è una funzionalità integrata molto potente fornita da Apigee Edge. Raccoglie e analizza un ampio spettro di dati che passano attraverso le API. I dati di analisi acquisiti possono fornire informazioni molto utili. Ad esempio, qual è la tendenza del volume di traffico API in un determinato periodo di tempo? Qual è l'API più utilizzata? Quali API hanno tassi di errore elevati?

L'analisi regolare di questi dati e approfondimenti può essere utilizzata per intraprendere azioni appropriate, come la pianificazione della capacità futura delle API in base all'utilizzo corrente, alle decisioni di investimento aziendali e future e a molti altri aspetti.

Dati di Analytics e relativa archiviazione

L'API Analytics acquisisce molti tipi diversi di dati, ad esempio:

  • Informazioni su un'API: URI richiesta, indirizzo IP client, codici di stato della risposta e così via
  • Prestazioni del proxy API: percentuale di successo/errore, tempo di elaborazione di richieste e risposte e così via
  • Prestazioni del server di destinazione: percentuale di successo/errore, tempo di elaborazione
  • Informazioni sugli errori: numero di errori, codice di errore, norma di errore, numero di errori causati da Apigee e dal server di destinazione.
  • Altre informazioni: numero di richieste effettuate da sviluppatori, app per sviluppatori e così via

Tutti questi dati vengono archiviati in uno analytics schema creato e gestito all'interno di un database Postgres da Apigee Edge.

In genere, in un'installazione Edge standard, Postgres avrà lo schema seguente:

Lo schema denominato analytics viene utilizzato da Edge per memorizzare tutti i dati di analisi per ogni organizzazione e ambiente. Se la monetizzazione è installata, sarà presente uno schema rkms. Gli altri schemi sono destinati agli elementi interni di Postgres.

Lo schema analytics continuerà a cambiare man mano che Apigee Edge aggiunge dinamicamente nuove tabelle di fatti al momento dell'esecuzione. Il componente del server Postgres aggrega i dati di fatto in tabelle aggregate che vengono caricate e visualizzate nell'interfaccia utente di Edge.

Antipattern

L'aggiunta di colonne, tabelle e/o viste personalizzate a uno degli schemi di proprietà di Apigee nel database Postgres su ambienti Private Cloud utilizzando direttamente le query SQL non è consigliabile, in quanto può avere implicazioni negative.

Facciamo un esempio per spiegare meglio.

Supponiamo che sia stata creata una tabella personalizzata denominata account nello schema di analisi come mostrato di seguito:

Dopo un po' di tempo, supponiamo che sia necessario eseguire l'upgrade di Apigee Edge da una versione precedente a una successiva. L'upgrade di Apigee Edge per il cloud privato prevede l'upgrade di Postgres, tra molti altri componenti. Se al database Postgres sono state aggiunte colonne, tabelle o viste personalizzate, l'upgrade di Postgres non va a buon fine con errori che fanno riferimento agli oggetti personalizzati poiché non sono creati da Apigee Edge. Di conseguenza, anche l'upgrade di Apigee Edge non riesce e non può essere completato.

Analogamente, possono verificarsi errori durante le attività di manutenzione di Apigee Edge in cui vengono eseguiti il backup e il ripristino dei componenti di Edge, incluso il database Postgres.

Impatto

  • L'upgrade di Apigee Edge non può essere completato perché l'upgrade del componente Postgres non va a buon fine con errori che fanno riferimento a oggetti personalizzati non creati da Apigee Edge.
  • Incongruenze (e errori) durante l'esecuzione della manutenzione del servizio Apigee Analytics (backup/ripristino).

Best practice

  • Non aggiungere informazioni personalizzate sotto forma di colonne, tabelle, visualizzazioni, funzioni e procedure direttamente a uno degli schemi di proprietà di Apigee, ad esempio analytics e così via
  • Se è necessario supportare informazioni personalizzate, queste possono essere aggiunte come colonne (campi) utilizzando un criterio di Collector di statistiche per lo schema analytics.

Per approfondire