Edge for Private Cloud でのみ利用可能
Edge API Analytics は、Apigee Edge に備わっている極めて強力な組み込み機能です。これは、API プロキシを通過するさまざまなデータを収集して分析します。キャプチャされた分析データは、特に有用な情報を含んでいることがあります。たとえば、API トラフィックの量は一定期間にわたってどのように傾向を示しているか。 最も使用されている API はどれか。エラー率が高い API はどれか、などです。
このデータと情報を定期的に分析して、現在の使用状況、ビジネス上の決定、将来の投資決定などに基づき API の将来のキャパシティプ ランニングなどの適切なアクションを実行できます。
分析データとその保存
API Analytics は、次のようなさまざまなタイプのデータを収集します。
- API に関する情報 - リクエスト URI、クライアント IP アドレス、レスポンス ステータス コードなど
- API プロキシのパフォーマンス - 成功 / 失敗率、リクエストとレスポンスの処理時間など
- ターゲット サーバーのパフォーマンス - 成功 / 失敗率、処理時間
- エラー情報 - エラーの数、障害コード、失敗したポリシー、エラーを起こした Apigee およびターゲット サーバーの数
- その他の情報 - デベロッパー、デベロッパー アプリなどが行ったリクエストの数
これらのデータはすべて、Apigee Edge によって Postgres データベース内で作成および管理される analytics スキーマに保存されます。
通常、標準的な Edge インストール環境では、Postgres に次のスキーマがあります。
analytics という名前のスキーマは、各組織および環境のすべての分析データを保存するために Edge によって使用されます。Monetization がインストールされている場合、rkms スキーマがあります。他のスキーマは、Postgres 内部用です。
Apigee Edge はランタイム時に新しいファクト テーブルを動的に追加していくので、analytics スキーマは常に変化します。Postgres サーバー コンポーネントは、ファクトデータをサマリー表に集約し、Edge UI にロードして表示します。
アンチパターン
Private Cloud 環境の Postgres データベースにある Apigee 所有のスキーマに、SQL クエリを使ってカスタムの列、テーブル、ビューを直接追加すると、好ましくない影響が生じる可能性があり、おすすめできません。
これを詳細に説明する例を見てみましょう。
以下に示すように、account という名前のカスタム テーブルが分析スキーマの下に作成されているとします。
しばらくして、Apigee Edge を下位バージョンから上位バージョンにアップグレードする必要が生じたとします。Private Cloud Apigee Edge のアップグレードでは、他の多くのコンポーネントとともに Postgres がアップグレードされます。カスタムの列、テーブル、またはビューが Postgres データベースに追加されている場合、Postgres のアップグレード操作は、Apigee Edge で作成されたものではないカスタム オブジェクトを参照するエラーが原因で失敗します。したがって、Apigee Edge のアップグレードも失敗し、完了できません。
同様に、Apigee Edge のメンテナンス作業中にエラーが発生する可能性があります。その際には、Postgres データベースを含む Edge コンポーネントのバックアップと復元が実行されます。
影響
- Apigee Edge が作成したものではないカスタム オブジェクトを参照するエラーが原因で Postgres コンポーネントのアップグレードが失敗し、Apigee Edge のアップグレードを完了できません。
- Apigee Analytics サービス メンテナンス（バックアップ / 復元）の実行中の不整合（および障害）。
ベスト プラクティス
- 列、テーブル、ビュー、関数、およびプロシージャの形式のカスタム情報を、
analyticsなどの Apigee 所有のスキーマに直接追加しないでください。 - カスタム情報をサポートする必要がある場合、Statistics Collector ポリシーを使用してそれを列（フィールド）として
analyticsスキーマに追加できます。