Este artículo explica una consulta de ejemplo de la API de accountMetrics para monitorear el máximo rendimiento de subida y bajada para un sitio.
Recomendamos que utilice bytesUpstreamMax y bytesDownstreamMax, que son métricas de pico. Las licencias de Cato se basan en estos valores, no en el rendimiento promedio.
Esta es una consulta para recuperar una serie temporal de 10 cubetas para el periodo de tiempo de 15:00:00 a 15:10:00 del 6 de febrero de 2024, para el sitio con ID=12345. 10 cubetas para un marco de tiempo de 10 minutos significa que cada cubeta es efectivamente un minuto.
{
accountMetrics(
accountID: 7890
timeFrame: "utc.2024-02-06/{15:00:00--15:10:00}"
groupDevices: true
groupInterfaces: true
) {
from
to
sitios (siteIDs:[12345]) {
interfaces {
nombre
timeseries (labels:[bytesUpstreamMax] buckets:10) {
label
units
data
}
}
}
}
}
Así es como se ve la consulta en el Playground de la API GraphQL:
La respuesta completa es:
{
"data": {
"accountMetrics": {
"from": "2024-02-06T15:00:00Z",
"to": "2024-02-06T15:10:00Z",
"sitios": [
{
"interfaces": [
{
"nombre": "todo",
"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
]
]
}
]
}
]
}
]
}
}
}
Cada elemento de la serie temporal / array de datos es una lista donde el primer elemento es la marca de tiempo al inicio de esa cubeta, y el segundo elemento es la métrica para esa cubeta. Las marcas de tiempo están en UTC, el tiempo de la Época Unix en nanosegundos. Un comando de una línea en Python convierte la marca de tiempo en la primera cubeta a una cadena legible:
python3 -c "import datetime;print(datetime.datetime.fromtimestamp(1707231600000/1000))"
Ejecutar este comando en un Mac se ve así:
sh-3.2$ python3 -c "import datetime;print(datetime.datetime.fromtimestamp (1707231600000/1000))" 2024-02-06 15:00:00 sh-3.2$
También puede ejecutar un comando bash de la siguiente manera:
date -r $((1707231600000/1000))
Estos son los resultados del comando bash:
Cato-admin-M:tools catoadmin$ date -r $((1707231600000/1000)) Tue 6 Feb 2024 15:00:00 GMT
Usando estas técnicas para convertir todas las marcas de tiempo de la salida anterior, vemos que coinciden con el inicio de las cubetas para cada minuto en nuestro marco de tiempo:
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
El segundo elemento en cada elemento de la serie temporal es la métrica que en este caso es el pico de rendimiento de subida en esa cubeta. Se pueden solicitar múltiples métricas en una sola consulta – es común solicitar tanto bytesUpstreamMax como bytesDownstreamMax. La métrica siempre se expresa como una tasa, independientemente del parámetro de entrada perSecond. El campo units indica que estas son bytes, por lo que debemos multiplicar por 8 para convertir a los más usuales bits por segundo.
Observando el primer elemento en nuestra respuesta arriba:
[ 1707231600000, 6008 ],
Podemos interpretar esto como:
-
2024-02-06 15:00:00 UTC fue el inicio de esta cubeta
-
Sabemos por nuestros parámetros que esta es una cubeta de un minuto (también puede pedirle a la API que devuelva la granularidad de la cubeta si no está seguro)
-
Durante esta cubeta, el mayor rendimiento fue de 6008 bytes por segundo. Multiplicando por 8, obtenemos un valor máximo de 8*6008 = 48,064 bits por segundo = 48kbps.
Aplicando este mismo principio a todos los elementos en nuestra serie temporal devuelta, obtenemos estos valores:
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 graficamos estos valores en Excel, el gráfico de líneas se ve así:
Para el periodo de tiempo correspondiente y el sitio, el gráfico “Max Throughput – Upstream” se ve así:
A primera vista, estos gráficos parecen algo diferentes, pero eso es principalmente porque el gráfico CMA proviene de una consulta con un número mucho mayor de cubetas – para facilitar la demostración, estamos utilizando un recuento de cubetas pequeño (10) con nuestra consulta Playground. Si colocamos el gráfico de Excel de nuestros datos de consulta sobre el gráfico CMA, se puede ver una fuerte correlación:
0 comentarios
El artículo está cerrado para comentarios.