Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen
Edge API Analytics ist eine sehr leistungsstarke integrierte Funktion, die von Apigee Edge bereitgestellt wird. Dabei wird ein breites Spektrum an Daten über APIs erfasst und analysiert. Die erfassten Analysedaten können sehr nützliche Erkenntnisse liefern. Beispiel: Wie entwickelt sich das API-Traffic-Volumen in einem bestimmten Zeitraum? Welche API wird am häufigsten verwendet? Welche APIs haben hohe Fehlerraten?
Eine regelmäßige Analyse dieser Daten und Statistiken kann verwendet werden, um geeignete Maßnahmen zu ergreifen, z. B. zukünftige Kapazitätsplanung von APIs auf der Grundlage der aktuellen Nutzung, Geschäfts- und zukünftige Investitionsentscheidungen und vieles mehr.
Analytics-Daten und deren Speicherung
API Analytics erfasst viele verschiedene Datentypen, z. B.:
- Informationen zu einer API - Anforderungs-URI, Client-IP-Adresse, Antwortstatuscodes usw.
- API-Proxy-Leistung - Erfolgs-/Fehlerrate, Bearbeitungszeit der Anforderung und Antwort usw.
- Leistung des Zielservers – Erfolgs-/Fehlerquote, Verarbeitungszeit
- Fehlerinformationen – Anzahl der Fehler, Fehlercode, fehlgeschlagene Richtlinie, Anzahl der von Apigee und des Zielservers verursachten Fehler.
- Weitere 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 Vanilla Edge-Installation hat Postgres normalerweise das folgende Schema:
Das Schema analytics wird von Edge zum Speichern aller Analysedaten für jede Organisation und Umgebung verwendet. Wenn die Monetarisierung installiert ist, gibt es ein rkms-Schema. Andere Schemas sind für das Innere von Postgres vorgesehen.
Das Schema analytics ändert sich ständig, da Apigee Edge zur Laufzeit dynamisch neue Faktentabellen hinzufügt. Die Postgres-Serverkomponente aggregiert die Faktendaten in aggregierten Tabellen, die in der Edge-Benutzeroberfläche geladen und angezeigt werden.
Anti-Pattern
Es ist nicht empfehlenswert, benutzerdefinierte Spalten, Tabellen und/oder Ansichten zu einem Apigee-Schema in Postgres Database in Private Cloud-Umgebungen direkt mithilfe von SQL-Abfragen hinzuzufügen, da dies nachteilige 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 Analyseschema erstellt, wie unten dargestellt:
Nehmen wir an, nach einiger Zeit muss Apigee Edge von einer niedrigeren Version auf eine höhere Version aktualisiert werden. Für das Upgrade von Private Cloud Apigee Edge wird neben vielen anderen Komponenten ein Upgrade von Postgres durchgeführt. Wenn der Postgres-Datenbank benutzerdefinierte Spalten, Tabellen oder Ansichten hinzugefügt werden, schlägt das Postgres-Upgrade mit Fehlern fehl, die auf die benutzerdefinierten Objekte verweisen, da sie nicht von Apigee Edge erstellt werden. Daher schlägt auch das Apigee Edge-Upgrade fehl und kann nicht abgeschlossen werden.
Ähnlich können Fehler während Apigee Edge-Wartungsaktivitäten auftreten, bei denen bei der Sicherung und Wiederherstellung von Edge-Komponenten, einschließlich der Postgres-Datenbank, ausgefü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) beim Durchführen einer Wartung des Apigee Analytics-Dienstes (Sicherung/Wiederherstellung).
Best Practices
- Fügen Sie keine benutzerdefinierten Informationen in Form von Spalten, Tabellen, Ansichten, Funktionen und Verfahren direkt einem Apigee-Schema wie
analyticsusw. hinzu - Wenn benutzerdefinierte Informationen unterstützt werden müssen, können diese mithilfe einer Statistik-Collector-Richtlinie als Spalten (Felder) zum
analytics-Schema hinzugefügt werden.