アナリティクス指標、ディメンション、フィルタのリファレンス

このトピックは、アナリティクスの指標、ディメンション、フィルタのリファレンスです。これらの使用方法については、API Analytics の概要をご覧ください。

このトピックでは、指標およびディメンションが UI に表示されるときの名前と、API 呼び出しで使用するときの名前を示します。

指標

以下は、カスタム レポートおよび Management API 呼び出しで取得できる API 指標です。

カスタム レポート名 Management API で使用する名前 関数 説明
1 秒あたりの平均トランザクション数 tps なし

1 秒あたりの平均トランザクション数(つまり API プロキシ リクエスト数)。期間中のトランザクション数が比較的少ない場合、1 秒あたりの平均トランザクション数が小数第 2 位より小さいと、UI カスタム レポートでゼロと表示されることがあります。

API 構文: tps

キャッシュ ヒット cache_hit sum

ターゲット サービスからのレスポンスの代わりに Response Cache を使用する API リクエストが正常に行われた数。

API 構文: sum(cache_hit)

L1 キャッシュ要素数 ax_cache_l1_count avg、min、max

指定された期間におけるトランザクションあたりの L1 (メモリ内)キャッシュ内の要素数を返します。たとえば、1 日の期間で max を選択し、特定のトランザクションにおける同日中のキャッシュ内の最高要素数が 12 であった場合、カウントは 12 となります。avg の場合、問い合わせの対象期間内に 3 つのトランザクションがあり、それぞれのキャッシュ数が 5、6、7 であった場合、平均は 6 となります。L1 キャッシュはメモリ内キャッシュであり、L2 データベース キャッシュとは異なります。これについてはキャッシュの仕組みで説明しています。

API 構文: avg(ax_cache_l1_count)

ポリシーエラー policy_error sum

指定された期間におけるポリシーエラーの総数です。

ポリシーエラーは通常は設計により発生します。たとえば、Verify API Key ポリシーは、リクエストで無効な API キーが渡されたときエラーをスローします。Spike Arrest ポリシーがエラーをスローするのは、API 呼び出し数がポリシーで定義された制限を超えた場合です。そのため、この指標は API 内で潜在的に問題が起こりやすい箇所を見つける場合に役立ちます。たとえば、policy_error 指標が developer_app ディメンションでグループ化されている場合は、API キーまたは OAuth トークンが指定のアプリで期限切れになっていることを検出するのに役立つ可能性があります。あるいは特定の API プロキシが多数の Spike Arrest エラーをスローしている場合は、そのプロキシの Spike Arrest 制限が休日のトラフィック増加によるものではないことを見いだせる可能性があります。

ポリシーエラーがアナリティクスに記録されるのは、そのエラーが API プロキシ障害になる場合だけです。たとえば、ポリシーの continueOnError 属性が true に設定されている場合、API プロキシはポリシーが失敗した場合でもリクエストの処理を続けます。その場合、ポリシーエラーはアナリティクスに記録されません。

エラー時のポリシー名(ax_execution_fault_policy_name)ディメンションは、ポリシーエラーをポリシー名別にグループ化する場合に便利です。

ターゲット障害(404 や 503 など)はポリシー障害としてカウントしません。これらは API プロキシ障害(is_error)としてカウントします。

API 構文: sum(policy_error)

プロキシ エラー is_error sum

指定された期間に API プロキシがエラーとなった回数の合計です。プロキシ障害が発生するのは、ポリシーが失敗したときか、ターゲット サービスからランタイム障害(404 や 503 など)が発生したときです。

プロキシ(apiproxy)ディメンションは、API プロキシ障害をプロキシ別にグループ化する場合に便利です。

API 構文: sum(is_error)

リクエスト処理レイテンシ request_processing_latency avg、min、max

Edge が受信リクエストを処理するのにかかる平均、最小、または最大時間(ミリ秒)。この時間はリクエストが Edge に到達したとき開始し、Edge がリクエストをターゲット サービスに転送したとき終了します。

さまざまなディメンションを使用することで、リクエスト処理レイテンシを API プロキシ別、デベロッパー アプリ別、リージョン別などで調べることができます。

API 構文: max(request_processing_latency)

リクエスト サイズ request_size sum、avg、min、max

Edge により受信されるリクエスト ペイロードのサイズ(バイト単位)。

API 構文: avg(request_size)

Response Cache 実行後 ax_cache_executed sum

Response Cache ポリシーが指定の期間中に実行された総回数。

Response Cache ポリシーは API プロキシで 2 か所に添付されるため(1 回はリクエスト中、もう 1 回はレスポンス中)、通常は 1 回の API 呼び出しで 2 回実行されます。キャッシュ「get」とキャッシュ「put」はそれぞれを 1 回の実行としてカウントします。

ただし、ポリシー内の <SkipCacheLookup> 要素が(リクエスト内で)true の場合はレスポンス キャッシュ実行は 0 に、ポリシー内の <SkipCachePopulation> 要素が(レスポンス内で)true の場合は 0 になります。

Trace ツールで、実行された API 呼び出しの [Response Cache] アイコンをクリックし、responsecache.executed フロー変数を見ると、キャッシュ実行(1 の値)があったかどうかがわかります。

API 構文: sum(ax_cache_executed)

レスポンス処理レイテンシ response_processing_latency avg、min、max

Edge が API レスポンスを処理するのにかかる平均時間、最小時間、または最大時間(ミリ秒)です。この時間は API プロキシがターゲット サービス レスポンスを受信したとき開始し、Apigee がレスポンスを元の呼び出し元に転送したとき終了します。

さまざまなディメンションを使用することで、レスポンス処理レイテンシを API プロキシ別、リージョン別などで調べることができます。

API 構文: min(response_processing_latency)

レスポンス サイズ response_size sum、avg、min、max

クライアントに返されるレスポンス ペイロードのサイズ(バイト単位)。

API 構文: max(response_size)

ターゲット エラー target_error sum

ターゲット サービスからの 5xx レスポンスの総数。これらのターゲット サービスエラーは、Apigee に起因するものではありません。

API 構文: sum(target_error)

ターゲット レスポンス時間 target_response_time sum、avg、min、max

ターゲット サーバーが呼び出しに応答する合計時間、平均時間、最小時間、または最大時間(ミリ秒)です。この指標により、ターゲット サーバーのパフォーマンスがわかります。この時間は Edge がリクエストをターゲット サービスに転送したとき開始し、Edge がレスポンスを受信したとき終了します。

API 呼び出しが(たとえば Response Cache ポリシーを使用して)キャッシュからレスポンスを返す場合、その呼び出しはターゲット サービスに到達しないため、ターゲット レスポンス時間指標は記録されていないことにご留意ください。

API 構文: avg(target_response_time)

合計レスポンス時間 total_response_time sum、avg、min、max

Edge がクライアントからリクエストを受信してからクライアントにレスポンスを返信するまでの合計時間、平均時間、最小時間、または最大時間(ミリ秒単位)です。この時間には、ネットワーク オーバーヘッド(たとえばロードバランサやルーターがそれぞれの仕事をするのにかかる時間)、リクエスト処理レイテンシ、レスポンス処理レイテンシ、ターゲット レスポンス時間(レスポンスが、キャッシュではなくターゲット サービスから返される場合)が含まれます。

さまざまなディメンションを使用することで、処理レイテンシを API プロキシ別、デベロッパー アプリ別、リージョン別などで調べることができます。

API 構文: avg(total_response_time)

トラフィック message_count sum

指定された期間に Edge により処理される API 呼び出しの合計数。

ディメンションを使用することで、トラフィック数を最も有意義な方法でグループ化できます。

API 構文: sum(message_count)

ディメンション

ディメンションにより、指標をわかりやすいグループに分けて見ることができます。たとえば、総トラフィック数を見る際は、デベロッパー アプリごとや API プロキシごとに表示したほうが効果的です。

以下は、そのまま使用できる Apigee のディメンションです。さらに、カスタム アナリティクスを使用して API メッセージ コンテンツを分析するの説明に沿って独自のディメンションを作成できます。

カスタム レポート名 Management API で使用する名前 説明
Apigee のエンティティ
アクセス トークン access_token アプリのエンドユーザーの OAuth アクセス トークン。
API プロダクト api_product

呼び出されている API プロキシを含む API プロダクトの名前。このディメンションを取得するには、呼び出し元のデベロッパー アプリが、API プロキシを含む 1 つ以上の API プロダクトに関連付けられていなければなりません。そして呼び出し先のプロキシは、API 呼び出しで送信される API キーまたは OAuth トークンを調べなければなりません。キーまたはトークンは API プロダクトに関連付けられています。詳細については、最初にすべきこと: 完全なアナリティクス データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。アナリティクス エンティティの値「(not set)」の意味もご覧ください。

キャッシュキー ax_cache_key

アクセスされた Response Cache 値を含むキー。このキーが Response Cache で構成される方法について詳しくは、Response Cache ポリシーをご覧ください。

Trace ツールで、キャッシュに対して読み書きを行う Response Cache ポリシーを選択すると、この値が responsecache.cachekey フロー変数に表示されます。

キャッシュ名 ax_cache_name

Response Cache ポリシーが使用する Key-Value を含むキャッシュの名前。接頭辞 orgName__envName__ が付きます。たとえば、組織が「foo」、環境が「test」、キャッシュ名が「myCache」の場合、ax_cache_name は foo__test__myCache です。

Trace ツールで、Response Cache ポリシーを選択すると、この値が responsecache.cachename フロー変数に表示されます。

キャッシュ ソース ax_cache_source

Response Cache が取得されたキャッシュ レベル(「L1」メモリ内または「L2」データベース)。このディメンションは、レスポンスがキャッシュではなくターゲットから送られたとき(およびレスポンス キャッシュがターゲット レスポンスでリフレッシュされたとき)、またはリクエスト内のキャッシュキーが無効なときに「CACHE_MISS」も表示します。キャッシュキーはサイズが 2 KB に制限されています。

Trace ツールで、Response Cache ポリシーを選択すると、この値が responsecache.cachesource フロー変数に表示されます。

キャッシュ レベルの詳細については、キャッシュの仕組みをご覧ください。

解決済みクライアント IP ax_resolved_client_ip

発信側クライアント IP アドレスを含みます。ax_resolved_client_ip ディメンションの値は、ax_true_client_ip ディメンションと x_forwarded_for_ip ディメンションの値から計算されます。

Akamai などのルーティング製品を使用してクライアントの真の IP アドレスを取得する場合、クライアント IP は Edge の HTTP ヘッダー True-Client-IP に渡されることにご留意ください。その後、ax_true_client_ip ディメンションを設定するために使用されます。

ax_resolved_client_ip ディメンションの値は以下のように計算されます。

  1. ax_true_client_ip が null でなくローカル IP アドレスを含まない場合は、ax_resolved_client_ipax_true_client_ip に設定します。
  2. 上記に該当しない場合は、ax_resolved_client_ipx_forwarded_for_ip の最初の非ローカル IP アドレスに設定します。
  3. ax_true_client_ipx_forwarded_for_ip の両方にローカル IP だけが含まれる場合は、ax_resolved_client_ipx_forwarded_for_ip の最後のローカル IP に設定します。
  4. ax_true_client_ipx_forwarded_for_ip の両方が null の場合は、ax_resolved_client_ip を「(not set)」に設定します。
  5. ax_true_client_ip がローカル IP で x_forwarded_for_ip が null の場合、ax_resolved_client_ip を「(not set)」に設定します。
クライアント ID client_id

API 呼び出しを行っているデベロッパー アプリのコンシューマ キー(API キー)。リクエスト内で API キーとして渡されるか、OAuth トークンに含まれます。

このディメンションを取得するには、呼び出しを受信するプロキシが有効な API キーまたは OAuth トークンの有無を調べるよう構成されていなければなりません。デベロッパー アプリが API キーを取得し、アプリが Edge に登録されている場合は、これを使用して OAuth トークンを生成できます。詳細については、最初にすべきこと: 完全なアナリティクス データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。アナリティクス エンティティの値「(not set)」の意味もご覧ください。

デベロッパー アプリ developer_app

API 呼び出しを行っている、Edge 登録したデベロッパー アプリ。

このディメンションを取得するには、呼び出し対象の API プロキシを含む 1 つ以上の API プロダクトにアプリが関連付けられていなければなりません。そしてプロキシは、API 呼び出しで送信される API キーまたは OAuth トークンを調べなければなりません。キーまたはトークンは、デベロッパー アプリを識別します。詳細については、最初にすべきこと: 完全なアナリティクス データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。アナリティクス エンティティの値「(not set)」の意味もご覧ください。

デベロッパーのメール developer_email

API 呼び出しを行ったアプリを所有する、Edge 登録したデベロッパーのメール。

このディメンションを取得するには、呼び出し対象の API プロキシを含む 1 つ以上の API プロダクトに関連付けられたアプリを、デベロッパーが所有していなければなりません。そしてプロキシは、API 呼び出しで送信される API キーまたは OAuth トークンを調べなければなりません。キーまたはトークンは、デベロッパー アプリを識別します。詳細については、最初にすべきこと: 完全なアナリティクス データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。アナリティクス エンティティの値「(not set)」の意味もご覧ください。

デベロッパー ID developer

Edge 登録した一意のデベロッパー ID。形式は org_name@@@unique_id です。

このディメンションを取得するため、呼び出し対象の API プロキシを含む 1 つ以上の API プロダクトに関連付けられたアプリをデベロッパーが所有していなければなりません。そしてプロキシは、API 呼び出しで送信される API キーまたは OAuth トークンを調べなければなりません。キーまたはトークンは、デベロッパーを識別します。詳細については、最初にすべきこと: 完全なアナリティクス データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。アナリティクス エンティティの値「(not set)」の意味もご覧ください。

環境 environment API プロキシがデプロイされている Edge 環境。たとえば、「test」または「prod」です。
エラー時のフロー名 ax_execution_fault
  _flow_name

エラーが発生した API プロキシ内の名前付きフロー。たとえば、「PreFlow」、「PostFlow」、あるいは作成した条件付きフローの名前などです。

Management API で使用するフルネームは、改行なしの ax_execution_fault_flow_name になることに注意してください。

エラーが発生していない場合は、値「(not set)」が表示されます。

フロー リソース flow_resource Apigee による使用のみ。興味がある場合は、こちらのコミュニティ投稿をご覧ください。
エラー時のフロー状態 ax_execution_fault
  _flow_state

エラーが発生した API プロキシフロー状態の名前。「PROXY_REQ_FLOW」や「TARGET_RESP_FLOW」など。

Management API で使用するフルネームは、改行なしの ax_execution_fault_flow_state になることに注意してください。

ゲートウェイ フロー ID gateway_flow_id API 呼び出しが Edge 内を移動する際、各呼び出しは独自のゲートウェイ フロー ID を取得します。例: rrt329ea-12575-114653952-1。ゲートウェイ フロー ID は、組織、環境、タイムスタンプなど他の指標が呼び出し間で同一である高 TPS 状況において、指標を見分ける場合に便利です。
組織 organization API プロキシがデプロイされている Edge 組織。
エラー時のポリシー名 ax_execution_fault
  _policy_name

エラーをスローして API 呼び出しが失敗する原因となったポリシーの名前。

Management API で使用するフルネームは、改行なしの ax_execution_fault_policy_name になることに注意してください。

ポリシーがエラーをスローしたのにもかかわらずポリシールート属性 continueOnErrortrue に設定されている場合、API プロキシフローは失敗せず継続し、ポリシーエラーはこのディメンションでカウントされません。

プロキシ apiproxy API プロキシのマシン名(表示名ではない)。
プロキシ ベースパス proxy_basepath

API プロキシ ProxyEndpoint で構成された BasePath。ベースパスに API プロキシ URL のドメインやポート部分は含まれません。たとえば、API プロキシのベース URL が https://apigeedocs-test.apigee.net/releasenotes/ の場合、ベースパスは /releasenotes です。

値は proxy.basepath フロー変数にも格納されます。

プロキシパス接尾辞 proxy_pathsuffix

API プロキシ ベースパスに追加されたリソースパス。たとえば、API プロキシのベース URL が https://apigeedocs-test.apigee.net/hello/ であり、呼び出しが https://apigeedocs-test.apigee.net/hello/json に対して行われた場合、pathsuffix は /json です。

pathsuffix を使用しない場合、値は空となります。

値は proxy.pathsuffix フロー変数にも格納されます。

プロキシ リビジョン apiproxy_revision API 呼び出しを処理した API プロキシのリビジョン番号。これは、必ずしも API プロキシの最新リビジョンを意味するわけではありません。API プロキシにリビジョンが 10 個ある場合、8 番目のリビジョンが現在デプロイされている場合があります。また、リビジョンに異なる Base Path がある限り、API に複数のリビジョンがデプロイされている場合があります。これについては、UI でのプロキシのデプロイで説明しています。
レスポンス ステータス コード response_status_code Apigee からクライアントに転送された HTTP レスポンス ステータス コード(200、404、503 など)。Edge では、ターゲットからのレスポンス ステータス コードは Assign MessageRaise Fault などのポリシーで上書きが可能です。これが、このディメンションがターゲット レスポンス コード(target_response_code)と異なる理由です。
仮想ホスト virtual_host API 呼び出しが行われた仮想ホストの名前。たとえば、組織にはデフォルトで default(http)と secure(https)の 2 つの仮想ホストがあります。
インバウンド / クライアント
クライアント IP アドレス client_ip 元のクライアント(proxy_client_ip)やロードバランサなど、ルーターを通過するシステムの IP アドレスX-Forwarded-For ヘッダーに複数の IP がある場合、これはリストの最後の IP です。
デバイス カテゴリ ax_ua_device_category API 呼び出しを行ったデバイスのタイプ。「タブレット」や「スマートフォン」など。
OS ファミリー ax_ua_os_family 呼び出しを行っているデバイスのオペレーティング システム ファミリー(「Android」や「iOS」など)。
OS バージョン ax_ua_os_version

呼び出しを行っているデバイスのオペレーティング システムのバージョン。

オペレーティング システムのバージョンを調べる場合に、これを OS ファミリー(ax_ua_os_family)と一緒に 2 番目の「ドリルダウン」ディメンションとして使用すると便利です。

プロキシ クライアント IP proxy_client_ip

呼び出し元クライアントの IP アドレス。proxy.client.ip フロー変数に格納されます。多くの場合、これは着信呼び出しの X-Forwarded-For アドレスであり、Edge が最後の外部 TCP handshake から受信した IP アドレスです。呼び出し元クライアントやロードバランサである可能性があります。X-Forwarded-For ヘッダーに複数の IP がある場合は、リストの最後の IP となります。

参照されるクライアント IP ax_true_client_ip

Akamai などのルーティング製品を使用してクライアントの真の IP アドレスを取得する場合、クライアント IP は Edge の HTTP ヘッダー True-Client-IP に渡されます。このディメンションは、これらの真のクライアント IP をそのヘッダーから取得します。

ax_resolved_client_ip ディメンションを介してアクセスした、元のクライアント IP アドレスを調べるため、Edge は ax_true_client_ip ディメンションと x_forwarded_for_ip ディメンションを使用します。

リクエスト パス request_path

ターゲット サービスへのリソースパス(ドメインを含まない)。クエリ パラメータを除きます。

たとえば、Apigee サンプル ターゲット http://mocktarget.apigee.net には複数のリソース(挨拶を返す /user など)が含まれます。API プロキシが http://mocktarget.apigee.net/user を呼び出す方法に関係なく、request_path は /user です。

リクエスト URI request_uri

ターゲット サービスへのリソースパス(ドメインを含まない)。クエリ パラメータを含みます。

たとえば、Apigee サンプル ターゲット http://mocktarget.apigee.net には、/user?user={name} リソースや、指定された名前にカスタム挨拶を返すクエリ パラメータなど、複数のリソースが含まれます。API プロキシがいかにして http://mocktarget.apigee.net/user?user=Dude を呼び出すかに関係なく、request_uri は /user?user=Dude です。

リクエスト動詞 request_verb API リクエスト内の HTTP リクエスト動詞。GET、POST、PUT、DELETE など。
ユーザー エージェント useragent

ユーザー エージェントまたはソフトウェア エージェントの名前。API 呼び出しを行うために使用します。次に例を示します。

  • Chrome から呼び出しを行う Pixel XL: Mozilla/5.0 (Linux; Android 7.1.2; Pixel XL Build/NHG47N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.92 Mobile Safari/537.36
  • Chrome から呼び出しを行う iPad: Mozilla/5.0 (iPad; CPU OS 10_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/54.0.2840.91 Mobile/14C92 Safari/602.1
  • ターミナルからの cURL: curl/7.51.0
ユーザー エージェント ファミリー 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_basepath

プロキシの <TargetEndpoint> で定義されるターゲット サービスへのリソースパス(ドメインを含まない)。クエリ パラメータは除きます。

たとえば、API プロキシが次のターゲットを呼び出すとします。


<TargetEndpoint name="default">
    ...
    <HTTPTargetConnection>
      <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
    </HTTPTargetConnection>

この例では、target_basepath は /user です。

ターゲットが次のようになっているとします。


<TargetEndpoint name="default">
    ...
    <HTTPTargetConnection>
      <URL>http://mocktarget.apigee.net</URL>
    </HTTPTargetConnection>
    

この場合、target_basepath は null になります。

Trace ツールで、フロー図の最後の AX アイコンを選択すると、target.basepath フロー変数が target_basepath ディメンションに対応しています。

ターゲット ホスト target_host ターゲット サービスのホスト。たとえば、API プロキシが http://mocktarget.apigee.net/help を呼び出す場合、target_host は mocktarget.apigee.net です。
ターゲット IP アドレス target_ip API プロキシにレスポンスを返しているターゲット サービスの IP アドレス。
ターゲット レスポンス コード target_response_code

ターゲット サービスにより API プロキシに返された HTTP レスポンス ステータス コード。200、404、503 など。

「null」の値は、リクエストがターゲット サービスに到達しないことを意味します。これは、レスポンスが Response Cache ポリシーにより返されたときや、リクエスト処理にエラーがあるときに発生します。

これは、レスポンス ステータス コード(response_status_code)ディメンションとは異なります。

ターゲット URL target_url

API プロキシの TargetEndpoint で定義されているターゲット サービスの完全な URL。


<TargetEndpoint name="default">
    ...
    <HTTPTargetConnection>
      <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
    </HTTPTargetConnection>
    

この例では、target_url は http://mocktarget.apigee.net/user?user=Dude です。

この URL は、API プロキシ処理中に、target.url フロー変数により上書きされる場合があることも留意してください。

プロキシ チェーンでは、およびスクリプト ターゲット(Node.js)を使用しているときは、呼び出し元プロキシの target_url は null となります。

X Forwarded For x_forwarded_for_ip

X-Forwarded-For ヘッダー内の IP アドレスのリスト。

ax_resolved_client_ip ディメンションを介してアクセスした、元のクライアント IP アドレスを調べるため、Edge は ax_true_client_ip ディメンションと x_forwarded_for_ip ディメンションを使用します。

時間
曜日 ax_day_of_week API 呼び出しが行われた曜日の 3 文字の省略形。たとえば、Mon、Tue、Wed です。
ax_month_of_year API 呼び出しが行われた月の数値。たとえば、3 月は「03」です。
時刻 ax_hour_of_day

24 時間制に基づいた、API 呼び出しが行われた 2 桁の時間。たとえば、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 などです。

フィルタ

フィルタを使用すると、結果を特定の特性を持つ指標に限定できます。いくつかのサンプル フィルタを以下に示します。フィルタを定義するときに指標およびディメンションの 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)
    

レポート フィルタを構築するために使用できる演算子を以下に示します。

演算子 説明
in リストに含む
notin リストから除外する
eq 等しい、==
ne 等しくない、!=
gt より大きい、>
lt より小さい、<
ge 以上、>=
le 以下、<=
like 文字列パターンが指定したパターンに一致する場合に true を返します。
not like 文字列パターンが指定したパターンに一致する場合に false を返します。
similar to パターンが指定した文字列に一致するかどうかに応じて true または false を返します。like と似ていますが、SQL 標準の正規表現の定義を使用してパターンを解釈する点が異なります。
not similar to パターンが指定した文字列に一致するかどうかに応じて false または true を返します。not like と似ていますが、SQL 標準の正規表現の定義を使用してパターンを解釈する点が異なります。
and 「and」論理演算子を使用して複数のフィルタ式を含めることができます。フィルタには、すべての条件を満たすデータが含まれます。
or 「or」 論理演算子を使用して、考えられるさまざまなフィルタ式を評価できます。フィルタには、少なくとも 1 つの条件を満たすデータが含まれます。