この記事では、サイトの最大上りおよび下りスループットを監視するためのアカウントメトリクスAPIクエリの例を説明します。
クエリを作成する
ピークメトリックであるbytesUpstreamMaxおよびbytesDownstreamMaxを使用することをお勧めします。 Catoライセンスは平均スループットではなく、これらの値に基づいています。
これは、2024年2月6日の15:00:00から15:10:00の時間枠で、ID=12345のサイトのタイムシリーズで10バケットを取得するクエリです。 10分間の時間枠での10バケットは、各バケットが実質的に1分に相当します。
{
accountMetrics(
accountID: 7890
timeFrame: "utc.2024-02-06/{15:00:00--15:10:00}"
groupDevices: true
groupInterfaces: true
) {
from
to
sites (siteIDs:[12345]) {
interfaces {
name
timeseries (labels:[bytesUpstreamMax] buckets:10) {
label
units
data
}
}
}
}
}GraphQL API Playgroundでクエリがどのように見えるかは次の通りです：
完全な応答は次の通りです：
{
"data": {
"accountMetrics": {
"from": "2024-02-06T15:00:00Z",
"to": "2024-02-06T15:10:00Z",
"sites": [
{
"interfaces": [
{
"name": "all",
"timeseries": [
{
"label": "bytesUpstreamMax",
"units": "bytes",
"data": [
[
1707231600000,
6008
],
[
1707231660000,
12802
],
[
1707231720000,
6557
],
[
1707231780000,
3467
],
[
1707231840000,
7168
],
[
1707231900000,
3660
],
[
1707231960000,
6791
],
[
1707232020000,
5839
],
[
1707232080000,
4183
],
[
1707232140000,
4684
]
]
}
]
}
]
}
]
}
}
}タイムシリーズの結果を解釈する
タイムスタンプ
タイムシリーズ/データ配列の各要素はリストで、その最初の要素はそのバケットの開始時刻であり、二番目の要素はそのバケットのメトリックです。 タイムスタンプはUTCで、ナノ秒単位のUnixエポック時間です。 Pythonの1行コマンドで最初のバケット内のタイムスタンプを人間が読める文字列に変換します：
python3 -c "import datetime;print(datetime.datetime.fromtimestamp(1707231600000/1000))"
Macでこのコマンドを実行すると次のようになります：
sh-3.2$ python3 -c "import datetime;print(datetime.datetime.fromtimestamp(1707231600000/1000))" 2024-02-06 15:00:00 sh-3.2$
次のようにbashコマンドを実行することもできます：
date -r $((1707231600000/1000))
bashコマンドの結果は次の通りです：
Cato-admin-M:tools catoadmin$ date -r $((1707231600000/1000)) Tue 6 Feb 2024 15:00:00 GMT
これらの技術を使用して、上記の出力のすべてのタイムスタンプを変換すると、各分の時間枠でのバケットの開始と一致することがわかります：
1707231600000 -> 2024-02-06 15:00:00 1707231660000 -> 2024-02-06 15:01:00 1707231720000 -> 2024-02-06 15:02:00 1707231780000 -> 2024-02-06 15:03:00 1707231840000 -> 2024-02-06 15:04:00 1707231900000 -> 2024-02-06 15:05:00 1707231960000 -> 2024-02-06 15:06:00 1707232020000 -> 2024-02-06 15:07:00 1707232080000 -> 2024-02-06 15:08:00 1707232140000 -> 2024-02-06 15:09:00
ピーク上りスループット
各タイムシリーズ要素の二番目の項目は、このバケット内のピーク上りスループットを示すメトリックです。 単一のクエリで複数のメトリックを要求することができ、bytesUpstreamMaxとbytesDownstreamMaxを両方要求することが一般的です。 メトリックは常に秒単位の入力パラメータに関係なくレートとして表現されます。 unitsフィールドはこれがバイトであることを示しているため、より一般的なビット毎秒に変換するには8倍する必要があります。
上記の応答の最初の要素を見ると：
[ 1707231600000, 6008 ],
これを次のように解釈できます：
2024-02-06 15:00:00 UTCはこのバケットの開始でした
このパラメーターから、これは1分バケットであることがわかります（不明な場合はAPIにバケットの粒度を返すよう依頼することができます）
このバケットでは、最高のスループットは秒ごとに6008バイトでした。 8倍することで、ピーク値は8*6008 = 48,064ビット毎秒 = 48kbpsになります。
返されたタイムシリーズのすべての項目にこの原理を適用すると、これらの値になります：
1707231600000 -> 2024-02-06 15:00:00 48kbps 1707231660000 -> 2024-02-06 15:01:00 102kbps 1707231720000 -> 2024-02-06 15:02:00 52kbps 1707231780000 -> 2024-02-06 15:03:00 27kbps 1707231840000 -> 2024-02-06 15:04:00 57kbps 1707231900000 -> 2024-02-06 15:05:00 29kbps 1707231960000 -> 2024-02-06 15:06:00 54kbps 1707232020000 -> 2024-02-06 15:07:00 46kbps 1707232080000 -> 2024-02-06 15:08:00 33kbps 1707232140000 -> 2024-02-06 15:09:00 37kbps
これらの値をExcelにグラフ化すると、折れ線グラフは次のようになります：
対応する時間枠とサイトにとって、「最大スループット – 上り」のグラフは次のようになります：
最初の印象ではこれらのグラフは少し異なるように見えますが、これは主にCMAグラフがはるかに多くのバケットを持つクエリから来ているためです。デモの便宜上、Playgroundクエリでは小さなバケット数（10）を使用しています。 クエリデータからのExcelグラフをCMAグラフに重ねると、強い相関関係が見られます：
