このページの内容は Apigee と Apigee ハイブリッドに該当します。
Apigee Edge のドキュメントを表示する。
このトピックは、分析の指標、ディメンション、フィルタのリファレンスです。これらの使用方法については、API Analytics の概要をご覧ください。
このトピックでは、指標およびディメンションが UI に表示されるときの名前と、API 呼び出しで使用されるときの名前を示します。
- UI 名は、カスタム レポートを作成、管理するときに表示されます。
- API 固有名は、指標を取得するとき、レポート定義を作成するとき、レポート定義を更新するときに使用されます。
指標
以下は、カスタム レポートと Apigee API 呼び出しで取得できる API 指標です。
指標 | Apigee API で使用される名前 | 関数 | 説明 |
---|---|---|---|
1 秒あたりの平均トランザクション数。 | tps |
なし |
1 秒あたりの平均トランザクション数(つまり API プロキシ リクエスト数)。期間中のトランザクション数が比較的少ない場合、1 秒あたりの平均トランザクション数が小数第 2 位より小さいと、UI カスタム レポートでゼロと表示されることがあります。 API 構文: |
キャッシュ ヒット | cache_hit |
sum |
ターゲット サービスからのレスポンスの代わりに API 構文: |
L1 キャッシュ要素数 | ax_cache_l1_count |
avg、min、max |
一定期間におけるトランザクションあたりの L1(メモリ内)キャッシュ内の要素数。たとえば、1 日の期間として API 構文: |
ポリシーエラー | policy_error |
sum |
指定した期間におけるポリシーエラーの総数です。 ポリシーエラーは通常、意図的に発生します。たとえば、リクエストで無効な API キーを渡すと ポリシーエラーが分析に記録されるのは、そのエラーが API プロキシ障害を招く場合だけです。たとえば、ポリシーの エラー時のポリシー名( ターゲットの失敗( API 構文: |
プロキシエラー | is_error |
sum |
指定した期間に API プロキシが失敗した回数の合計。プロキシ障害は、ポリシーが失敗した場合、またはターゲット サービスからの プロキシ( API 構文: |
リクエスト処理レイテンシ | request_processing_latency |
avg、min、max |
Apigee が受信リクエストを処理するのにかかる平均時間、最小時間、または最大時間(ミリ秒単位)。この時間は、リクエストが Apigee に到達すると開始され、Apigee がリクエストをターゲット サービスに転送したときに終了します。 さまざまなディメンションを使用することで、リクエスト処理レイテンシを API プロキシ別、デベロッパー アプリ別、リージョン別などで調べることができます。 API 構文: |
リクエスト サイズ | request_size |
sum、avg、min、max |
Apigee が受信したリクエスト ペイロードのサイズ(バイト単位)。 API 構文: |
レスポンス キャッシュの実行数 | ax_cache_executed |
sum |
一定期間に
ただし、ポリシー内の Debug ツールで、実行された API 呼び出しの API 構文: |
レスポンス処理レイテンシ | response_processing_latency |
avg、min、max |
Apigee が API レスポンスを処理するのに要する時間(平均値、最小値、または最大値。ミリ秒単位)。この時間は API プロキシがターゲット サービス レスポンスを受信すると開始され、Apigee がレスポンスを元の呼び出し元に転送したときに終了します。 さまざまなディメンションを使用することで、レスポンス処理レイテンシを API プロキシ別、リージョン別などで調べることができます。 API 構文: |
レスポンス サイズ | response_size |
sum、avg、min、max |
クライアントに返されるレスポンス ペイロードのサイズ(バイト単位)。 API 構文: |
ターゲット エラー | target_error |
sum |
ターゲット サービスからの API 構文: |
ターゲット レスポンス タイム | target_response_time |
sum、avg、min、max |
ターゲット サーバーが呼び出しに応答する合計時間、平均時間、最小時間、または最大時間(ミリ秒単位)。この指標により、ターゲット サーバーのパフォーマンスがわかります。この時間は、Apigee がリクエストをターゲット サービスに転送すると開始され、Apigee がレスポンスを受信したときに終了します。 なお、API 呼び出しが( API 構文: |
レスポンスの合計時間 | total_response_time |
sum、avg、min、max |
Apigee がクライアントからリクエストを受信してからクライアントにレスポンスを返信するまでの時間(合計値、平均値、最小値、または最大値。ミリ秒単位)。この時間には、ネットワーク オーバーヘッド(ロードバランサやルーターがそれぞれの処理にかかる時間)、リクエスト処理レイテンシ、レスポンス処理レイテンシ、ターゲット レスポンス時間(レスポンスがキャッシュではなく、ターゲット サービスから返信された場合)が含まれます。 さまざまなディメンションを使用することで、処理レイテンシを API プロキシ別、デベロッパー アプリ別、リージョン別などで調べることができます。 API 構文: |
トラフィック | message_count |
sum |
指定の期間に Apigee によって処理された API 呼び出しの合計数。 ディメンションを使用すると、トラフィック数を最も意味のある形に分類できます。 API 構文: |
収益化 | |||
料金 | fees |
sum、avg、min、max |
設定料金、定期的な料金、前払い追加料金の金額。 API 構文: |
デベロッパーへの収益分配率 | x_apigee_mintng_dev_share |
sum、avg、min、max |
トランザクションの収益におけるデベロッパーのシェア。デベロッパーのシェアは、料金プランで収益分配を有効にした場合にのみ計算されます。 デベロッパーのシェアは、次の式で計算されます。 x_apigee_mintng_dev_share = revShareGrossPrice * (share percentage)
シェアの割合の値は料金プランから取得されます。 API 構文: |
収益化の金額 | x_apigee_mintng_price |
sum、avg、min、max |
トランザクションの総収益。トランザクションの収益は、DataCapture ポリシーで取得された API 構文: |
API 料金の乗数 | x_apigee_mintng_price_multiplier |
sum、avg、min、max |
トランザクションごとの費用にかける係数(乗数)。トランザクションごとの費用は、料金プランの使用量に基づく料金で指定されます。 API 構文: |
収益化率 | x_apigee_mintng_rate |
sum、avg、min、max |
トランザクションに対して課金される料金。トランザクションに対して課金される料金は、次の数式を使用して計算されます。 x_apigee_mintng_rate = (consumption-based pricing rate) * perUnitPriceMultiplier value
従量制の料金のレートの値は料金プランから取得され、 API 構文: |
ディメンション
ディメンションにより、指標をわかりやすいグループに分けて見ることができます。たとえば、トラフィックの合計数を確認するには、デベロッパー アプリごとや API プロキシごとに表示したほうが、かなり効果的になります。
Apigee でそのまま使用できるように用意されているディメンションは、次のとおりです。
ディメンション | Apigee API で使用される名前 | 説明 |
---|---|---|
アクセス トークン | access_token |
アプリ エンドユーザーの OAuth アクセス トークン。 |
API プロダクト | api_product |
|
キャッシュキー | ax_cache_key |
アクセスされた Debug ツールで、キャッシュからの読み取りまたはキャッシュへの書き込みを行う |
キャッシュ名 | ax_cache_name |
Debug ツールで、 |
キャッシュ ソース | ax_cache_source |
Debug ツールで、 キャッシュ レベルの詳細については、キャッシュの仕組みをご覧ください。 |
クライアント ID | client_id |
API 呼び出しを行うデベロッパー アプリのコンシューマ キー(API キー)。リクエスト内で API キーとして渡されるか、OAuth トークンに含まれます。 このディメンションを取得するには、呼び出しを受信するプロキシが有効な API キーまたは OAuth トークンであることを検証するように構成されている必要があります。アプリが Apigee に登録されている場合、デベロッパー アプリは OAuth トークンの生成に使用される API キーを取得します。詳細については、完全な分析データを生成する方法をご覧ください。 上記の条件が満たされていない場合は、値 |
デベロッパー / アプリ | developer_app |
API 呼び出しを行う Apigee 登録済みのデベロッパー アプリ。 このディメンションを取得するには、呼び出し対象の API プロキシを含む 1 つ以上の API プロダクトにアプリを関連付ける必要があり、プロキシは API 呼び出しで送信された API キーまたは OAuth トークンを確認する必要があります。このキーまたはトークンがデベロッパー アプリの識別子となります。詳細については、完全な分析データを生成する方法をご覧ください。 上記の条件が満たされていない場合は、値 |
デベロッパーのメール | developer_email |
|
デベロッパー ID | developer |
Apigee によって生成される このディメンションを取得するには、デベロッパーが呼び出し対象の API プロキシを含む 1 つ以上の API プロダクトにアプリを関連付ける必要があり、プロキシは API 呼び出しで送信された API キーまたは OAuth トークンを確認する必要があります。このキーまたはトークンがデベロッパーの識別子となります。詳細については、完全な分析データを生成する方法をご覧ください。 上記の条件が満たされていない場合は、値 |
環境 | environment |
API プロキシがデプロイされる Apigee 環境。たとえば test や prod です。 |
エラー時の障害コード | ax_edge_execution_fault_code |
エラーの障害コード。例: |
エラー時のフロー名 | ax_execution_fault |
エラーが発生した API プロキシの名前付きフロー。たとえば、 Apigee API で使用されるフルネームは、改行なしで エラーが発生しなかった場合、 |
フローリソース | flow_resource |
Apigee でのみ使用します。詳しくは、アナリティクスで「リソースフロー」ディメンションを使用する方法をご覧ください。 |
エラー発生フローの状態 | ax_execution_fault |
エラーが発生した API プロキシフローの状態の名前( Apigee API で使用されるフルネームは、改行なしで |
ゲートウェイ フロー ID | gateway_flow_id |
API 呼び出しが Apigee 内を移動する際、各呼び出しは独自のゲートウェイ フロー ID を取得します。たとえば、rrt329ea-12575-114653952-1 です。ゲートウェイ フロー ID は、組織、環境、タイムスタンプなど他のディメンションが呼び出し間で同一である高 TPS 状況において、指標を見分ける場合に便利です。 |
組織 | organization |
API プロキシがデプロイされる Apigee 組織。 |
エラー発生時のポリシー名 | ax_execution_fault |
エラーをスローして API 呼び出しが失敗する原因となったポリシーの名前。 Apigee API で使用されるフルネームは、改行なしで ポリシーがエラーをスローしたのにもかかわらず、ポリシールート属性 |
プロキシ | apiproxy |
API プロキシのマシン名(表示名ではない)。 |
プロキシ ベースパス | proxy_basepath |
API プロキシ ProxyEndpoint で構成された BasePath。ベースパスには、API プロキシ URL のドメインとポートの部分は含まれません。たとえば、API プロキシのベース URL が 値は |
プロキシのデプロイタイプ | proxy_deployment_type |
デプロイされたプロキシの API プロキシタイプ。プロキシタイプを指定すると、結果はそのプロキシタイプに制限されます。考えられる値は、 |
プロキシパス接尾辞 | proxy_pathsuffix |
API プロキシのベースパスに追加されたるソースパス。たとえば、API プロキシのベース URL が
値は |
プロキシ リビジョン | apiproxy_revision |
API 呼び出しを処理した API プロキシのリビジョン番号。これは、必ずしも API プロキシの最新リビジョンを意味するわけではありません。API プロキシにリビジョンが 10 個ある場合、8 番目のリビジョンがデプロイされることがあります。また、プロキシのデプロイで説明しているように、リビジョンが異なるベースパスを持つ限り、API に複数のリビジョがデプロイされる場合があります。 |
解決済みクライアント IP | ax_resolved_client_ip |
配信元クライアント IP アドレス。 Akamai などのルーティング プロダクトを使用してクライアントの実際の IP アドレスを取得する場合、クライアントの IP は HTTP ヘッダー
|
レスポンス ステータス コード | response_status_code |
Apigee からクライアントに転送された HTTP レスポンス ステータス コード(200 、404 、503 など)。Apigee では、ターゲットからのレスポンス ステータス コードは、AssignMessage ポリシーや RaiseFault ポリシーなどのポリシーで上書きできます。このため、このディメンションは、ターゲット レスポンス コード(target_response_code)と異なる場合があります。 |
仮想ホスト | virtual_host |
API 呼び出しが行われた仮想ホストの名前。詳細については、環境と環境グループについてをご覧ください。 |
インバウンド / クライアント | ||
クライアント IP アドレス | client_ip |
元のクライアント(proxy_client_ip)やロードバランサなど、ルーターを通過するシステムの IP アドレス。X-Forwarded-For ヘッダーに複数の IP がある場合、これはリストの最後の IP です。 |
デバイス カテゴリ | ax_ua_device_category |
API 呼び出し元のデバイスの種類(Tablet 、Smartphone など)。 |
OS ファミリー | ax_ua_os_family |
呼び出し元のデバイスのオペレーティング システム ファミリー(Android 、iOS など)。 |
OS のバージョン | ax_ua_os_version |
呼び出し元のデバイスのオペレーティング システムのバージョン。 オペレーティング システムのバージョンを確認する場合に、これを OS ファミリー(ax_ua_os_family)と一緒に 2 つ目のドリルダウン ディメンションとして使用すると便利です。 |
プロキシ クライアント IP | proxy_client_ip |
呼び出し元クライアントの IP アドレス。 |
参照されるクライアント IP | ax_true_client_ip |
Akamai などのルーティング プロダクトを使用してクライアントの実際の IP アドレスを取得する場合、クライアント IP は HTTP ヘッダー
|
リクエストパス | request_path |
クエリ パラメータを除いた、ターゲット サービスへのリソースパス(ドメインを含まない)。 たとえば、Apigee サンプル ターゲット |
リクエスト URI | request_uri |
クエリ パラメータを含む、ターゲット サービスへのリソースパス(ドメインを含まない)。 たとえば、Apigee のサンプル ターゲット |
リクエスト動詞 | request_verb |
API リクエスト内の HTTP リクエスト動詞(GET、POST、PUT、DELETE など)。 |
ユーザー エージェント | useragent |
API 呼び出しに使用されたユーザー エージェントまたはソフトウェア エージェントの名前。次に例を示します。
|
ユーザー エージェント ファミリー | ax_ua_agent_family |
ユーザー エージェントのファミリー(Chrome Mobile 、curl など)。 |
ユーザー エージェント タイプ | ax_ua_agent_type |
ユーザー エージェントのタイプ(Browser 、Mobile Browser 、Library など)。 |
ユーザー エージェント バージョン | ax_ua_agent_version |
ユーザー エージェントのバージョン。 エージェント ファミリーのバージョンを取得する場合に、これをユーザー エージェント ファミリー(ax_ua_agent_family)と一緒に 2 つ目のドリルダウン ディメンションとして使用すると便利です。 |
アウトバウンド / ターゲット | ||
ターゲット | target |
リクエストを処理したターゲット エンドポイント。たとえば、default のようにします。 |
ターゲット ベースパス | target_basepath |
クエリ パラメータを除く、ターゲット サービスへのリソースパス(ドメインを含まない)。プロキシの たとえば、API プロキシが次のターゲットを呼び出すとします。 <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> この例では、target_basepath は ターゲットが次のようになっているとします。 <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> </HTTPTargetConnection> この場合、target_basepath は null になります。 Debug ツールで、フロー図の最後の AX アイコンを選択すると、 |
gRPC サービス名 | x_apigee_grpc_service_name |
ターゲット サービスが gRPC の場合にのみ適用されます。gRPC サービス名。gRPC プロキシについては、gRPC API プロキシの作成をご覧ください。 |
gRPC ステータス | x_apigee_grpc_status |
ターゲット サービスが gRPC の場合にのみ適用されます。gRPC リクエストのステータス。gRPC プロキシについては、gRPC API プロキシの作成をご覧ください。 |
ターゲット ホスト | target_host |
ターゲット サービスのホスト。たとえば、API プロキシが http://mocktarget.apigee.net/help を呼び出す場合、target_host は mocktarget.apigee.net です。 |
ターゲット IP アドレス | target_ip |
API プロキシにレスポンスを返しているターゲット サービスの IP アドレス。 |
ターゲット レスポンス コード | target_response_code |
ターゲット サービスによって API プロキシに返された HTTP レスポンス ステータス コード( 値 これは、レスポンス ステータス コード(response_status_code)ディメンションとは異なります。 |
gRPC RPC 名 | x_apigee_grpc_rpc_name |
ターゲット サービスが gRPC の場合にのみ適用されます。RPC 名。gRPC プロキシについては、gRPC API プロキシの作成をご覧ください。 |
ターゲット URL | target_url |
API プロキシの TargetEndpoint で定義されたターゲット サービスの完全な URL。 <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> この例では、target_url は この URL は、API プロキシ処理中に、 プロキシ チェーンでは、呼び出し元プロキシの target_url は null となります。 |
X-Forwarded-For IP | x_forwarded_for_ip |
|
X-Forwarded-For Proto | x_forwarded_proto |
クライアントがルーターに接続するために使用されるプロトコル。有効な値は、 |
時間 | ||
曜日 | ax_day_of_week |
API 呼び出しが行われた曜日の 3 文字の略語。たとえば、Mon、Tue、Wed です。 |
月 | ax_month_of_year |
API 呼び出しが行われた月の数値。たとえば、3 月は 03 となります。 |
時間帯 | ax_hour_of_day |
API 呼び出しが行われた 2 桁の時間(24 時間形式)。たとえば、API 呼び出しが午後 10 時と午後 11 時の間の時間に行われた場合、ax_hour_of_day は 22 になります。 時刻値は UTC です。 |
タイムゾーン | ax_geo_timezone |
API 呼び出しが行われたタイムゾーンの共通名(America/New_York および Europe/Dublin など) |
月の週 | ax_week_of_month |
月の週を表す数値。たとえば、月の第 3 週に行われた API 呼び出しの場合、ax_week_of_month は 3 です。 |
ロケーション | ||
都市 | ax_geo_city |
API 呼び出し元の都市。 |
大陸 | ax_geo_continent |
API 呼び出し元となった大陸の 2 文字のコード。たとえば、北米の場合は NA です。 |
国 | ax_geo_country |
API 呼び出し元となった国の 2 文字のコード。たとえば、米国の場合は US です。 |
地域 | ax_geo_region |
地域を指すコード(STATE-COUNTRY など)。たとえば、米国ワシントン州は WA-US となります。 |
リージョン | ax_dn_region |
API プロキシがデプロイされる Apigee データセンターの名前(us-east-1 など)。 |
収益化 | ||
作成日時 | created |
現在、Apigee 組織で使用できます。Apigee ハイブリッド組織では使用できません。 アプリ デベロッパーと API プロダクトの料金一覧が追加されたときの UNIX タイムスタンプ。 |
料金タイプ | fees_type |
料金のタイプ。設定料金、定期的数料、前払い追加料金のいずれかになります。この値は、Fees 指標を選択した場合にのみ入力されます。 |
収益の通貨 | x_apigee_mintng_currency |
|
料金プラン ID。 | x_apigee_mintng_rate_plan_id |
現在、Apigee 組織で使用できます。Apigee ハイブリッド組織では使用できません。 アプリ デベロッパー向けの収益化率料金プラン。 |
トランザクションの成功 | x_apigee_mintng_tx_success |
トランザクションの収益化ステータスは、DataCapture ポリシーで取得された transactionSuccess 収益化変数の値に設定されます。 |
フィルタ
フィルタを使用すると、結果を特定の特性を持つ指標に限定できます。いくつかのサンプル フィルタを以下に示します。フィルタを定義するときに指標およびディメンションの API スタイル名を使用します。
名前が books または music の API プロキシの指標を返します。
filter=(apiproxy in 'books','music')
名前が m
で始まる API プロキシの指標を返します。
filter=(apiproxy like 'm%')
名前が m
で始まらない API プロキシの指標を返します。
filter=(apiproxy not like 'm%')
レスポンス ステータス コードが 400
~599
の API 呼び出しの指標を返します。
filter=(response_status_code ge 400 and response_status_code le 599)
レスポンス ステータス コード 200
とターゲット レスポンス コード 404
を使用して、API 呼び出しの指標を返します。
filter=(response_status_code eq 200 and target_response_code eq 404)
レスポンス ステータス コードが 500
の API 呼び出しの指標を返します。
filter=(response_status_code eq 500)
結果がエラーにならなかった API 呼び出しの指標を返します。
filter=(is_error eq 0)
結果が null
レスポンスにならなかった API 呼び出しの指標を返します。
filter=(response_status_code isnot null)
レポート フィルタを構築するために使用できる演算子を以下に示します。
演算子 | 説明 |
---|---|
in |
リストに含む |
notin |
リストから除外する |
is |
response_status_code is null を使用して、ステータス コードが null のレスポンスをフィルタリングします。 |
isnot |
response_status_code isnot null を使用して、ステータス コードが null でないレスポンスをフィルタリングします。 |
eq |
次と等しい、== |
ne |
次と等しくない、!= |
gt |
次より大きい、> |
lt |
次より小さい、< |
ge |
次以上、>= |
le |
次以下、<= |
like |
文字列パターンが指定したパターンに一致する場合に true を返します。 |
not like |
文字列パターンが指定したパターンに一致する場合に false を返します。 |
similar to |
パターンが指定した文字列に一致するかどうかに応じて true または false を返します。like と似ていますが、SQL 標準の正規表現の定義を使用してパターンを解釈する点が異なります。 |
not similar to |
パターンが指定した文字列に一致するかどうかに応じて false または true を返します。SQL 標準の正規表現を使用してパターンを解釈する点を除き、not like と似ています。 |
and |
AND ロジックを使用して複数のフィルタ式を含めることができます。フィルタには、すべての条件を満たすデータが含まれます。 |
or |
OR ロジックを使用して、さまざまなフィルタ式を評価できます。フィルタには、少なくとも 1 つの条件を満たすデータが含まれます。 |