Cet article explique une requête exemple de l'API accountMetrics pour surveiller le débit maximal montant et descendant pour un site.
Nous vous recommandons d'utiliser bytesUpstreamMax et bytesDownstreamMax, qui sont des métriques de pointe. Les licences Cato sont basées sur ces valeurs, et non sur le débit moyen.
Voici une requête pour récupérer une série temporelle de 10 intervalles pour la période de 15:00:00 à 15:10:00 le 6 février 2024, pour le site avec ID=12345. 10 intervalles pour une période de 10 minutes signifie que chaque intervalle représente effectivement une minute.
{
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
}
}
}
}
}
Voici à quoi ressemble la requête dans le GraphQL API Playground :
La réponse complète est :
{
"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
]
]
}
]
}
]
}
]
}
}
}
Chaque élément du tableau de séries temporelles / données est une liste où le premier élément est l'horodatage au début de cet intervalle, et le deuxième élément est la métrique pour cet intervalle. Les horodatages sont en UTC, le temps Unix Epoch en nanosecondes. Une commande Python en une ligne convertit l'horodatage dans le premier intervalle en une chaîne lisible par l'homme :
python3 -c "import datetime;print(datetime.datetime.fromtimestamp(1707231600000/1000))"
L'exécution de cette commande sur un Mac ressemble à ceci :
sh-3.2$ python3 -c "import datetime;print(datetime.datetime.fromtimestamp (1707231600000/1000))" 2024-02-06 15:00:00 sh-3.2$
Vous pouvez également exécuter une commande bash comme suit :
date -r $((1707231600000/1000))
Voici les résultats de la commande bash :
Cato-admin-M:tools catoadmin$ date -r $((1707231600000/1000)) Mar 6 Fév 2024 15:00:00 GMT
En utilisant ces techniques pour convertir tous les horodatages de la sortie ci-dessus, nous voyons qu'ils correspondent au début des intervalles pour chaque minute de notre période de temps :
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
Le deuxième élément de chaque série temporelle est la métrique qui, dans ce cas, est le débit montant maximal dans cet intervalle. Plusieurs métriques peuvent être demandées dans une seule requête – il est courant de demander à la fois bytesUpstreamMax et bytesDownstreamMax. La métrique est toujours exprimée comme un taux, peu importe le paramètre d'entrée perSecond. Le champ units indique qu'il s'agit de bytes, donc nous devons multiplier par 8 pour convertir en bits par seconde plus courants.
En regardant le premier élément dans notre réponse ci-dessus :
[ 1707231600000, 6008 ],
Nous pouvons interpréter cela ainsi :
-
2024-02-06 15:00:00 UTC était le début de cet intervalle
-
Nous savons d'après nos paramètres qu'il s'agit d'un intervalle d'une minute (vous pouvez également demander à l'API de retourner la granularité de l'intervalle si vous n'êtes pas sûr)
-
Pendant cet intervalle, le débit maximal était de 6008 bytes par seconde. En multipliant par 8, nous obtenons une valeur maximale de 8*6008 = 48 064 bits par seconde = 48kbps.
En appliquant ce même principe à tous les éléments de notre série temporelle retournée, nous obtenons ces valeurs :
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
Si nous traçons ces valeurs dans Excel, le graphique en courbes ressemble à ceci :
Pour la période et le site correspondants, le graphique « Débit Maximal – Montant » ressemble à ceci :
À première vue, ces graphiques semblent quelque peu différents, mais c'est surtout parce que le graphique CMA provient d'une requête avec un nombre beaucoup plus élevé d'intervalles – pour faciliter la démonstration, nous utilisons un petit nombre d'intervalles (10) avec notre requête Playground. Si nous superposons le graphique Excel des données de notre requête sur le graphique CMA, vous pouvez voir une forte corrélation :
0 commentaire
Cet article n'accepte pas de commentaires.