Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu
Apigee X. info
Edge API Analytics ist eine sehr leistungsstarke integrierte Funktion von Apigee Edge. Sie erfasst und analysiert eine breite Palette von Daten, die über APIs fließen. Die erfassten Analysedaten können sehr nützliche Einblicke liefern. Zum Beispiel: Wie entwickelt sich das API-Trafficvolumen im Laufe der Zeit? Welche API wird am häufigsten verwendet? Bei welchen APIs gibt es hohe Fehlerraten?
Durch die regelmäßige Analyse dieser Daten und Erkenntnisse können geeignete Maßnahmen ergriffen werden, z. B. die zukünftige Kapazitätsplanung von APIs auf Grundlage der aktuellen Nutzung, Geschäfts- und zukünftige Investitionsentscheidungen, und vieles mehr.
Analysedaten und ihre Speicherung
API Analytics erfasst viele verschiedene Arten von Daten, z. B.:
- Informationen zu einer API: Anfrage-URI, Client-IP-Adresse, Statuscodes usw.
- API-Proxy-Leistung: Erfolgs-/Fehlerrate, Anfrage- und Antwortverarbeitungszeit usw.
- Leistung des Zielservers: Erfolgs-/Fehlerrate, Verarbeitungszeit
- Fehlerinformationen: Anzahl der Fehler, Fehlercode, fehlerhafte Richtlinie, Anzahl der Fehler, die durch Apigee und den Ziel Server verursacht wurden.
- Andere Informationen: Anzahl der Anfragen von Entwicklern, Entwickler-Apps usw.
Alle diese Daten werden in einem analytics Schema gespeichert, das in einer
Postgres-Datenbank von Apigee Edge erstellt und verwaltet wird.
In einer Standardinstallation von Edge hat Postgres in der Regel die folgenden Schemas:
Das Schema analytics wird von Edge verwendet, um alle Analysedaten für
jede Organisation und Umgebung zu speichern. Wenn die Monetarisierung installiert ist, gibt es ein rkms
Schema. Andere Schemas sind für interne Postgres-Vorgänge vorgesehen.
Das analytics Schema ändert sich ständig, da Apigee Edge zur Laufzeit dynamisch neue Fakt
tabellen hinzufügt. Die Postgres-Serverkomponente aggregiert die Faktendaten in zusammengefasste Tabellen, die in der neuen Edge-Benutzeroberfläche geladen und angezeigt werden.
Anti-Pattern
Es ist nicht ratsam, benutzerdefinierte Spalten, Tabellen und/oder Ansichten direkt über SQL-Abfragen zu den von Apigee verwalteten Schemas in der Postgres Datenbank in Private Cloud-Umgebungen hinzuzufügen, da dies negative Auswirkungen haben kann.
Wir erläutern dies anhand eines Beispiels.
Angenommen, eine benutzerdefinierte Tabelle mit dem Namen account wurde wie unten gezeigt unter dem Schema „analytics“ erstellt:
Nach einiger Zeit muss Apigee Edge möglicherweise von einer niedrigeren auf eine höhere Version aktualisiert werden. Das Upgrade von Apigee Edge in der Private Cloud umfasst unter anderem das Upgrade von Postgres. Wenn der Postgres-Datenbank benutzerdefinierte Spalten, Tabellen oder Ansichten hinzugefügt wurden, schlägt das Postgres-Upgrade mit Fehlern fehl, die auf die benutzerdefinierten Objekte verweisen, da sie nicht von Apigee Edge erstellt wurden. Daher schlägt auch das Apigee Edge-Upgrade fehl und kann nicht abgeschlossen werden.
Ähnliche Fehler können bei Apigee Edge-Wartungsaktivitäten auftreten, bei denen Sicherungen und Wiederherstellungen von Edge-Komponenten, einschließlich der Postgres-Datenbank, durchgeführt werden.
Auswirkungen
- Das Apigee Edge-Upgrade kann nicht abgeschlossen werden, da das Upgrade der Postgres-Komponente mit Fehlern fehlschlägt, die auf benutzerdefinierte Objekte verweisen, die nicht von Apigee Edge erstellt wurden.
- Inkonsistenzen (und Fehler) bei der Wartung des Apigee Analytics-Dienstes (Sicherung/Wiederherstellung).
Best Practice
- Fügen Sie keine benutzerdefinierten Informationen in Form von Spalten, Tabellen, Ansichten, Funktionen und
Prozeduren direkt zu einem der von Apigee verwalteten Schemas wie
analyticshinzu. - Wenn benutzerdefinierte Informationen unterstützt werden müssen, können sie als Spalten (Felder) mit
einer Statistics Collector-Richtlinie zum
analyticsSchema hinzugefügt werden.