Cato APIの使用を開始する前に、Cato APIのサポートポリシーを確認することを強くお勧めします。

accountMetricsの概要

accountMetricsクエリは、サイトとSDPユーザーのCato Cloudへの接続状態と品質を分析するのに役立ちます。 このデータは、サイトとCato Cloud間のDTLSトンネル内のトラフィックのためのものです。

accountMetricsは、アカウントのための履歴メトリック、統計、アナリティクスを表示します。 これは、Cato管理画面のサイト接続性ウィンドウと同様のデータを返します。

リセラーアカウントでは、接続する各顧客アカウント内でCato APIと接続するための別々のAPIキーを作成できます。 レート制限とaccountMetrics APIクエリの詳細については、Cato APIのレート制限について理解するを参照してください。

バケット粒度とAPIクエリ制限の作業

accountMetrics APIクエリごとに返されるアイテムの最大制限は100,000です。 クエリがこの制限に達すると、クエリは追加データを返さず、エラーメッセージが表示されます。

Catoは、次の要素を掛け合わせてこの制限を計算します：

• 合計サイト数+VPNユーザー数
• メトリック数（APIラベル/テレメトリー）
• バケット数

言い換えれば、(サイト数+VPNユーザー数)*(メトリック数)*(バケット数)の合計は100,000未満でなければなりません。 例えば、以下のクエリはエラーを発生させます：

• 10 サイト
• 140 VPNユーザー
• 5 メトリック
• 150 バケット

(10 + 140) * 5 * 150 = クエリ内のアイテム 112,500。 この例では、クエリを成功させるためにバケット数を減らすことができます。

APIラベルの種類に関する詳細については、Cato API - AccountMetrics > 時系列をご覧ください。

クエリの最小粒度の計算

このセクションでは、クエリの期間に基づいて最小粒度（バケットサイズ）を計算する方法を説明します。

1. 期間 - 期間を秒に変換
2. バケット制限 - 100000 / ((サイト数 + VPNユーザー数) * (メトリック数)) に基づいてバケット制限を計算
3. 最小粒度 = (期間) / (バケット制限)

例えば、以下の表の1番目の行は、7日、100サイトとVPNユーザー、5メトリックでのクエリ制限を示しています：

• 7 日 = 604,800 秒
• 200 バケット = 10000 / (100) * (5)
• 3024 秒の最小粒度 = 604800 / 200

次のテーブルは、最小バケット粒度でのaccountMetricsクエリのサンプル設定を示しています：

accountMetrics項目の詳細

これらは、accountMetrics項目がクエリに対して返すことができる詳細です：

• ID - アカウントID
• from - 開始時間
• to - 終了時間
• granularity - バケットサイズ
• サイト - 各サイトに対して返されるデータ (ネストされたクエリとフィールドを含む配列)
• timeseries - データの時間枠で、バケットとデータの関係を定義 (ネストされたクエリとフィールドを含む配列)

accountMetrics ID

ID 項目は、アカウント内のユニークな内部IDを示します。

このアカウントIDはCato管理画面には表示されず、代わりにCato管理画面のURL の番号です。 例として、次のURLでは、アカウントIDは26です： https://cc2.catonetworks.com/#!/26/topology。

accountMetrics From

From フィールドはクエリデータの開始時間を示し、時間枠引数で定義されています。

accountMetrics への

To フィールドはクエリデータの終了時間を示し、時間枠引数で定義されています。

accountMetrics 粒度

Granularity フィールドは、1つのメトリックバケットの秒単位の期間を示します。 バケットの数は、timeseries > バケット引数で定義されています。

粒度は、次の式に従って計算されます: 時間枠/バケット。 例として、クエリが5分のデータ(時間枠)を60のバケットで返す場合、粒度(バケットサイズ)は5秒(300秒/60)です。

バケットの最小粒度は5秒です。 バケットの粒度が5秒未満の場合、そのバケットに対してデータが返されない可能性があります。

粒度フィールドの詳細については、accountMetrics > 粒度と共に作業するをご覧ください。

accountMetrics サイト

サイト フィールドには、アカウント内の1つ以上のサイトに関連するデータが含まれます。 また、ユーザーIDを使用してVPN ユーザーのデータを指定することもできます。

accountMetricsのサイトフィールドについて詳しくは、Cato API - AccountMetrics > サイトをご覧ください。

アカウントメトリック時系列

指定された期間（バケット）に基づいて、クエリ内でアカウントのメトリックを表示し、過去の統計とメトリックを含みます。 このデータは、Cato管理アプリケーションの各サイトでのサイト接続性ウィンドウのフィールドに類似しています。

accountMetricsの時系列フィールドについて詳しくは、Cato API - AccountMetrics > 時系列をご覧ください。

アカウントメトリックのための引数

これは、渡すことができ、クエリによって返されるデータを定義する引数です：

• accountID - アカウント ID
• ID - アカウント ID（レガシー引数）
• 時間枠 - クエリの開始および終了時刻
• グループインタフェース - リンクの分析を単一のリンクに結合します（ブール値 trueの場合）
• グループデバイス - 複数のサイトおよび複数のソケットを持つ単一のサイトの場合、分析を単一のソケットに結合します（ブール値 trueの場合）

accountMetrics アカウントID 引数

クエリが返すデータのアカウントIDを入力してください。 この引数は必須です。

このアカウントIDはCato管理アプリケーションには表示されず、代わりにCato管理アプリケーションのURLに存在する番号です。 例えば、以下のURLではアカウントIDは26です：https://cc2.catonetworks.com/#!/26/topology。

アカウントメトリック時間枠引数

クエリが返すデータの期間を入力してください。 引数は<種類>.<時間の値>の形式です。 この引数は必須です。

時間枠を定義するためのサポートされているオプションは次のとおりです：

• 最後に。<時間の持続値> - 最後にタイプの<時間の持続値>はISO-8601に準拠し、前の特定の時刻のデータを返します。 例：
  • 時間枠 = 最後に.PT5M 前の5分を表示します
  • 時間枠 = 最後に.PT2H 前の2時間を表示します
  • 時間枠 = 最後に.P1D 前の1日を表示します
  • 時間枠 = 最後に.P3M 前の3か月を表示します
  • 時間枠 = 最後に.P1Y 前の1年を表示します
• utc.<短時間枠仕様> - 時間枠は指定されたタイムゾーンに従って、形式YY-MM-DD/hh:mm:ssで開始日と終了日を結合します。 引数にはすべての日付と時間の値を入力する必要があります。 例：
  • timeFrame = utc.2020-02-{11/04:50:00--21/04:50:00} は、2020年2月11日4:50:00 から 2020年2月21日4:50:00 への 10 日の分析データを表示します
  • timeFrame = utc.2020-02-11/{04:50:15--16:50:15} は、2020年2月11日の4:50:15 から 16:50:15 への 12 時間の分析データを表示します
  • timeFrame = utc.2020-{02-11/04:50:00--04-11/04:50:00} は、2020年2月11日4:50:00 から 4月11日4:50:00 への 2 月の分析データを表示します
  • timeFrame = utc.{2019-10-01/04:50:00--2020-02-01/04:50:00} は、2019年10月1日4:50:00 から 2020年2月1日4:50:00 への 4 月の分析データを表示します

    このフォーマットでは、複数の暦年を含む時間枠を設定できます

timeFrame 引数と Granularity フィールドの詳細については、accountMetrics を使用する > Granularity を参照してください。

accountMetrics groupInterfaces 引数

ブール引数 groupInterfaces が true に設定されている場合、すべてのインターフェースのデータが1つのインターフェースに集約されます。

accountMetrics groupDevices 引数

ブール引数 groupDevices が true に設定されている場合、すべてのソケット（通常は可用性が高い場合は2つ）の分析が1つの結果として集約されます。 集約されたソケットの最良の結果を得るには、両方のソケットのリンクに一貫した名前と機能（例：宛先）があることをお勧めします。