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

アカウントメトリクスの概要

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

アカウントメトリクスは、アカウントの履歴メトリック、統計、および分析を表示します。 これは、Cato管理アプリケーションのサイト接続ウィンドウに似たデータを返します。

再販業者アカウントの場合、接続するCato API用に各顧客アカウント内で別々のAPIキーを作成できます。 レート制限とアカウントメトリクスAPIクエリの詳細については、Cato APIレート制限の理解を参照してください。

バケット粗さとAPIクエリ制限の操作

アカウントメトリクスAPIクエリごとに返される項目数の最大限度は100,000です。 クエリがこの制限に達すると、追加のデータは返されず、エラーメッセージが表示されます。

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

• サイトの総数とVPNユーザー
• メトリクスの数（APIラベル/テレメトリ）
• バケットの数

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

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

(10 + 140) * 5 * 150 = 112,500 アイテムがクエリにあります。 この例では、クエリを正常に実行するためにバケットの数を減らすことができます。

APIラベルの種類の詳細については、Cato API - アカウントメトリクス > 時系列を参照してください。

クエリの最小粒度の計算

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

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

例えば、以下の表の最初の行は、7日間、100サイトとVPNユーザー、5メトリクスのクエリ制限を示しています:

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

以下の表は、最小バケット粒度を持つアカウントメトリクスクエリのサンプル設定を示しています:

アカウントメトリクスフィールドの詳細

以下は、クエリに応じてアカウントメトリクスフィールドが返すことができる詳細情報です:

• ID - アカウントID
• from - 開始時刻
• to - 終了時刻
• granularity - バケットサイズ
• サイト - 各サイトに返されるデータ（クエリとフィールドがネストされた配列）
• 時系列 - データの時間枠を示し、バケットとデータ間の関係を定義する（クエリとフィールドがネストされた配列）

アカウントメトリクス ID

IDフィールドはユニークなアカウントの内部IDを示します。

このアカウントIDはCato管理アプリケーションには表示されず、代わりにCato管理アプリケーションのURLの数字です。 例えば、次のURLの場合、アカウントIDは26です：https://cc2.catonetworks.com/#!/26/topology。

アカウントメトリクス From

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

アカウントメトリクス To

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

アカウントメトリクス 粒度

粒度フィールドは、単一のメトリクスバケットに対する秒数を示します。 バケットの数は時系列 > バケット引数で定義されています。

粒度は次の式に従って計算されます: timeFrame/buckets。 例えば、クエリが60バケットで5分のデータ（timeFrame）を返す場合、粒度（バケットサイズ）は5秒（300秒 / 60）です。

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

粒度フィールドの詳細については、アカウントメトリクス > 粒度の操作を参照してください。

アカウントメトリクス サイト

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

アカウントメトリクスのサイトフィールドの詳細については、Cato API - アカウントメトリクス > サイトを参照してください。

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

クエリで指定された時間枠（バケット）によってアカウントのメトリクスを示し、履歴統計とメトリクスを含みます。 このデータは、Cato管理アプリケーションの各サイトのサイト接続ウィンドウに似ています。

アカウントメトリクスの時系列フィールドの詳細については、Cato API - アカウントメトリクス > 時系列を参照してください。

アカウントメトリクスの引数

以下は、クエリによって返されるデータを渡して定義できる引数です:

• accountID - アカウントID
• ID - アカウントID（レガシー引数）
• timeFrame - クエリの開始時間と終了時間
• groupInterfaces - リンクの分析を単一のリンクに統合する（ブール値trueの場合）
• groupDevices - 複数のサイト、および複数のソケットを持つ単一のサイトの場合、分析を単一のソケットに統合する（ブール値trueの場合）

アカウントメトリクス accountID 引数

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

このアカウントIDはCato管理アプリケーションには表示されず、代わりにCato管理アプリケーションのURLの数字です。 例えば、次のURLの場合、アカウントIDは26です：https://cc2.catonetworks.com/#!/26/topology。

アカウントメトリクス timeFrame 引数

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

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

• last.<時間の長さ> - lastタイプの<時間の長さ>値はISO-8601に準拠しており、前の特定の時間をデータとして返します。 例:
  • timeFrame = last.PT5M は、過去5分間を示しています
  • timeFrame = last.PT2H は、過去2時間を示しています
  • timeFrame = last.P1D は、過去1日間を示しています
  • timeFrame = last.P3M は、過去3ヶ月間を示しています
  • timeFrame = last.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分から2020年2月21日午前4時50分までの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分から2020年4月11日午前4時50分までの2ヶ月間の分析データを示しています
  • timeFrame = utc.{2019-10-01/04:50:00--2020-02-01/04:50:00} は、2019年10月1日午前4時50分から2020年2月1日午前4時50分までの4ヶ月間の分析データを示しています

    この形式を使用すると、複数の暦年を含む時間枠を構成できます

timeFrame引数と粒度フィールドの詳細については、アカウントメトリクス > 粒度の操作を参照してください。

アカウントメトリクス groupInterfaces 引数

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

アカウントメトリクス groupDevices 引数

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