Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info
Edge API Analytics ist eine leistungsstarke integrierte Funktion von Apigee Edge. Dabei werden Daten aus APIs erfasst und analysiert. Die erfassten Analysedaten können sehr nützliche Informationen liefern. Beispielsweise: Wie entwickelt sich das API-Traffic-Volumen im Laufe der Zeit? Welche API wird am häufigsten verwendet? Bei welchen APIs treten viele Fehler auf?
Durch die regelmäßige Analyse dieser Daten und Statistiken können Sie entsprechende Maßnahmen ergreifen, z. B. die zukünftige Kapazitätsplanung von APIs basierend auf der aktuellen Nutzung, Geschäfts- und Investitionsentscheidungen für die Zukunft und vieles mehr.
Analytics-Daten und deren Speicherung
API Analytics erfasst viele verschiedene Datentypen, darunter:
- Informationen zu einer API, z. B. Anfrage-URI, Client-IP-Adresse und Antwortstatuscodes
- API-Proxy-Leistung – Erfolgs-/Fehlschlagsrate, Verarbeitungszeit für Anfragen und Antworten usw.
- Leistung des Zielservers – Erfolgs-/Fehlerquote, Verarbeitungszeit
- Fehlerinformationen: Anzahl der Fehler, Fehlercode, fehlgeschlagene Richtlinie, Anzahl der von Apigee und dem Zielserver verursachten Fehler.
- 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 Standard-Edge-Installation hat Postgres in der Regel die folgenden Schemata:
Das Schema mit dem Namen analytics wird von Edge zum Speichern aller Analysedaten für jede Organisation und Umgebung verwendet. Wenn die Monetarisierung installiert ist, wird ein rkms-Schema verwendet. Andere Schemata sind für interne Postgres-Objekte gedacht.
Das analytics-Schema ändert sich ständig, da Apigee Edge ihm während der Laufzeit dynamisch neue Faktentabellen hinzufügt. Die Postgres-Serverkomponente aggregiert die Faktendaten in Aggregationstabellen, die in die Edge-Benutzeroberfläche geladen und angezeigt werden.
Anti-Pattern
Es wird nicht empfohlen, den Schemata von Apigee in der Postgres-Datenbank in privaten Cloud-Umgebungen direkt über SQL-Abfragen benutzerdefinierte Spalten, Tabellen und/oder Ansichten hinzuzufügen, da dies negative Auswirkungen haben kann.
Anhand eines Beispiels wird dies genauer erläutert.
Angenommen, Sie haben eine benutzerdefinierte Tabelle namens account im Analyseschema erstellt, wie unten dargestellt:
Angenommen, nach einiger Zeit müssen Sie Apigee Edge von einer niedrigeren Version auf eine höhere Version aktualisieren. Das Upgrade von Private Cloud Apigee Edge umfasst unter anderem ein 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 die Sicherung und Wiederherstellung von Edge-Komponenten einschließlich der Postgres-Datenbank durchgeführt wird.
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 in eines der Apigee-Schemas wie
analyticsein. - Wenn benutzerdefinierte Informationen unterstützt werden müssen, können sie dem
analytics-Schema mithilfe einer Statistics Collector-Richtlinie als Spalten (Felder) hinzugefügt werden.