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 ein breites Spektrum an Daten, die über APIs übertragen werden. Die erfassten Analysedaten können sehr nützliche Informationen liefern. Zum Beispiel: Wie entwickelt sich das API-Trafficvolumen im Laufe der Zeit? Welche API wird am häufigsten verwendet? Welche APIs haben hohe Fehlerraten?
Durch die regelmäßige Analyse dieser Daten und Informationen können geeignete Maßnahmen ergriffen werden, z. B. die zukünftige Kapazitätsplanung von APIs basierend auf 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, Antwortstatuscodes usw.
- API-Proxy-Leistung: Erfolgs-/Fehlerrate, Verarbeitungszeit für Anfragen und Antworten usw.
- Leistung des Zielservers: Erfolgs-/Fehlerrate, Verarbeitungszeit
- Fehlerinformationen: Anzahl der Fehler, Fehlercode, fehlerhafte Richtlinie, Anzahl der Fehler, die durch Apigee- und Ziel Server verursacht wurden.
- Sonstige Informationen: Anzahl der Anfragen von Entwicklern, Entwickler-Apps usw.
Alle diese Daten werden in einem analytics Schema gespeichert, das von Apigee Edge in einer
Postgres-Datenbank 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 Aggregat
Tabellen, die in die Edge-Benutzeroberfläche geladen und dort angezeigt werden.
Anti-Pattern
Es ist nicht ratsam, den von Apigee verwalteten Schemas in der Postgres Datenbank in Private Cloud-Umgebungen direkt benutzerdefinierte Spalten, Tabellen und/oder Ansichten mit SQL-Abfragen hinzuzufügen, da dies negative Auswirkungen haben kann.
Sehen wir uns ein Beispiel an, um dies im Detail zu erläutern.
Angenommen, eine benutzerdefinierte Tabelle mit dem Namen account wurde unter dem Schema „analytics“ erstellt, wie
unten dargestellt:
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 den von Apigee verwalteten Schemas wie
analyticskeine benutzerdefinierten Informationen in Form von Spalten, Tabellen, Ansichten, Funktionen und Prozeduren direkt hinzu. - Wenn benutzerdefinierte Informationen unterstützt werden müssen, können sie als Spalten (Felder) mit
einer Statistics Collector-Richtlinie zum
analyticsSchema hinzugefügt werden.