Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
L'analisi delle API Edge è 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 insight molto utili. Ad esempio, qual è l'andamento del volume di traffico delle API in un determinato periodo di tempo? Qual è l'API più utilizzata? Quali API presentano tassi di errore elevati?
L'analisi regolare di questi dati e insight può essere utilizzata per intraprendere le azioni appropriate, come la pianificazione futura della capacità delle API in base all'utilizzo attuale, alle decisioni di investimento aziendali e future e molto altro.
Dati di Analytics e relativa archiviazione
L'analisi delle API acquisisce molti tipi diversi di dati, ad esempio:
- Informazioni su un'API: URI della richiesta, indirizzo IP del client, codici di stato della risposta e così via
- Prestazioni del proxy API - Percentuale di successo/errore, tempo di elaborazione richieste e risposte e così via
- Prestazioni del server target - Percentuale di successo/errore, tempo di elaborazione
- Informazioni sull'errore: numero di errori, codice di errore, criterio di errore, numero di Apigee e server di destinazione causati da errori.
- Altre informazioni: numero di richieste effettuate da sviluppatori, app degli sviluppatori e così via
Tutti questi dati sono archiviati in uno schema analytics creato e gestito all'interno di un database Postgres da Apigee Edge.
In genere, in un'installazione Vanilla Edge, Postgres avrà i seguenti schemi:
Lo schema denominato analytics viene utilizzato da Edge per archiviare tutti i dati di analisi per
ogni organizzazione e ambiente. Se la monetizzazione è installata, sarà presente uno schema rkms. Gli altri schemi sono destinati a elementi interni Postgres.
Lo schema analytics continuerà a cambiare poiché Apigee Edge aggiungerà dinamicamente nuove tabelle dei dati in fase di runtime. Il componente server Postgres aggregherà i dati dei fatti in tabelle aggregate che vengono caricate e visualizzate nell'interfaccia utente Edge.
Antipattern
Non è consigliabile aggiungere colonne, tabelle e/o viste personalizzate a uno degli schemi di proprietà di Apigee in Postgres Database in ambienti Cloud privato direttamente utilizzando query SQL, poiché può avere implicazioni negative.
Facciamo un esempio per spiegare questo aspetto in dettaglio.
Considera che nello schema di analisi è stata creata una tabella personalizzata denominata account, come
mostrato di seguito:
Dopo un po', supponiamo che sia necessario eseguire l'upgrade di Apigee Edge da una versione precedente a una versione superiore. L'upgrade di Apigee Edge nel cloud privato comporta l'upgrade di Postgres tra molti altri componenti. Se al database Postgres vengono aggiunte colonne, tabelle o viste personalizzate, l'upgrade di Postgres non riesce e restituisce errori che fanno riferimento agli oggetti personalizzati poiché non sono stati creati da Apigee Edge. Di conseguenza, anche l'upgrade di Apigee Edge non andrà a buon fine e non può essere completato.
Analogamente, possono verificarsi errori durante le attività di manutenzione di Apigee Edge durante le operazioni di backup e ripristino dei componenti Edge, incluso il database Postgres.
Impatto
- Impossibile completare l'upgrade di Apigee Edge perché l'upgrade dei componenti Postgres non va a buon fine e generano errori che fanno riferimento a oggetti personalizzati non creati da Apigee Edge.
- Incoerenze (e errori) durante l'esecuzione della manutenzione del servizio Apigee Analytics (backup/ripristino).
Best practice
- Non aggiungere informazioni personalizzate sotto forma di colonne, tabelle, viste, funzioni e procedure direttamente a nessuno schema di proprietà di Apigee come
analyticse così via - Se è necessario supportare informazioni personalizzate, puoi aggiungerle come colonne (campi) utilizzando un criterio del raccoglitore di statistiche allo schema
analytics.