Linux, Speedtest, SQL · 24 min read · Nov 11, 2025

Cómo usar speedtest en un servidor Linux para verificar, almacenar e informar sobre las velocidades de Internet gráficamente

Siguiendo un conjunto de problemas de mala conectividad de banda ancha que estaba experimentando, decidí que quería monitorear la velocidad en Mbps que estaba obteniendo de mi proveedor de manera regular. Estaba viendo cifras especialmente malas al intentar descargar archivos por la noche, con velocidades mucho más rápidas logradas muy temprano en la mañana.

Tengo un servidor Linux Debian sentado en una esquina, que es mi máquina de prueba y desarrollo para sitios web alojados en ISPConfig, así como algo de código de Let’s Encrypt con el que me gusta jugar, así que busqué un software que me permitiera realizar pruebas de ancho de banda, ejecutable desde una línea de comandos de Linux, que pudiera formar la base de un sistema automatizado de scripts de shell para producir los datos en bruto que necesitaba. Quería almacenar los datos en una base de datos SQL para hacer que las consultas fueran simples (podría reunir más datos fácilmente y extraer solo un subconjunto más pequeño para los períodos de tiempo que me interesaban) y tener un front-end web que pudiera producir un gráfico simple para visualizar los datos y ayudar a resaltar los problemas de conectividad.

El primer resultado de mi búsqueda fue el artículo realmente útil de Antonio Valencia en: https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/

Después de seguir las instrucciones allí para instalar speedtest, un rápido juego mostró que podía usarlo para ejecutar pruebas contra un amplio conjunto de servidores de Internet y también producir salida en formato CSV, que es bastante adecuado para ser importado directamente en una tabla SQL con el mínimo esfuerzo en desarrollo de software.

Para la cantidad relativamente pequeña de datos que se generarían, decidí usar SQLite como el almacenamiento de backend y una búsqueda rápida de las bibliotecas de gráficos basadas en javascript de código abierto disponibles me llevó a chart.js, que tiene un diseño simple y limpio con una interfaz de datos simple pero mucha capacidad para ajustar opciones avanzadas si es necesario. Convertir datos SQL para extraer solo el subconjunto de datos que quería graficar con salida a través de JSON mediante un código PHP sencillo era el camino a seguir.

Así que, en general, necesitaba diseñar un sistema que se viera así:

Un servidor Linux ejecutando speedtest como un cronjob - tal vez 1 por hora - con la salida de speedtest almacenada en una base de datos SQLite - todo controlado por un archivo de script de shell bash. Un front-end web, siendo una mezcla de HTML, CSS, javascript y PHP para extraer datos de SQLite y producir un gráfico de barras que muestre las cifras de Mbps logradas durante las 24 horas anteriores (o cualquier otro período que pudiera decidir).

Un poco de experimentación con la ejecución de speedtest una docena de veces de manera interactiva me mostró que había algunos servidores disponibles que parecían dar resultados que estaban muy en línea con el tipo de velocidades que estaba experimentando. Consideré que era una buena idea probar contra más de un servidor para tener una mejor comprensión de cómo mis cifras de Mbps se veían afectadas por la ubicación del servidor objetivo y la hora del día en una zona horaria diferente.

Si quieres seguir adelante y configurar un sistema similar para ti, necesitarás seleccionar uno o más servidores de los cientos disponibles para speedtest que se adapten a tu ubicación.

1 Requisitos previos

  • un servidor linux - estoy usando Debian 9.1 - stretch
  • acceso tty al servidor con inicio de sesión root - uso PuTTY desde una laptop con Windows
  • ISPConfig instalado y un sitio web configurado con una cuenta FTP también - estoy usando 3.1.6 con apache configurado como el servidor web (podrías manejarte solo con un servidor web, con algunos cambios menores en las siguientes instrucciones)
  • PHP - estoy usando 7.0, pero esto debería funcionar con la mayoría de las versiones anteriores también
  • cliente FTP - uso Filezilla - y PureFTPd ejecutándose en el servidor
  • nano - o tu editor visual favorito

Asumo aquí que te sientes cómodo iniciando sesión en un servidor Linux, cómo moverte por los directorios, el diseño de dónde espera tu servidor web que estén los archivos y cómo FTP archivos a esos directorios.

Aquí están los pasos detallados para permitirte configurar todo esto.

2 Instalar speedtest

Inicia sesión en tu servidor linux como root y ejecuta el comando:

# pip install speedtest-cli

Consulta https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/ y https://pypi.python.org/pypi/speedtest-cli para más información si tienes algún problema.

Nota: speedtest y speedtest-cli son idénticos en mi instalación, así que solo haré referencia a speedtest en lo siguiente.

3 Instalar SQLite3

# apt-get install sqlite3

Usa el equivalente para tu distribución si apt-get no es para ti.

4 Crear bandwidth.sh

Ingresa el siguiente código de script bash en un archivo y guárdalo como /usr/local/etc/bandwidth.sh - editaremos esto un poco más tarde para hacerlo específico para ti.

#!/bin/bash
# ejecutar speedtests contra 3 servidores y guardar todos los resultados de salida en un archivo CSV para importar a la base de datos sqlite
#
# ejecutado por cronjob una vez por hora
#
#
function getCSVString () {
    # si speedtest falló (por ejemplo, no pudo acceder a un servidor) necesitamos crear una entrada cero ficticia para este intervalo de tiempo
    
    # obtener una cadena de marca de tiempo en el mismo formato que genera speedtest - y necesitamos tiempo UTC
    local RIGHTNOW=$(date --utc +%Y-%m-%dT%H:%M:%SZ)
    
    # ¿contra qué servidor estamos probando?
    if [ $1 = "5443" ] 
    then
        echo "5443,Fasthosts Internet,Gloucester,$RIGHTNOW,73.09,0.0,0.0,0.0"
    fi
    if [ $1 = "1234" ] 
    then
        echo "1234,Uno,Milton Keynes,$RIGHTNOW,168.27,0.0,0.0,0.0"
    fi
    if [ $1 = "1783" ] 
    then
        echo "1783,Comcast,\"San Francisco, CA\",$RIGHTNOW,8420.0,0.0,0.0,0.0"
    fi
    
# caso de prueba/debug solo
    if [ $1 = "199999999" ]
    then
        echo "99999,Test,Test,$RIGHTNOW,99.99,0.0,0.0,0.0"
    fi
}

function runTest () {
    # ejecutar speedtest contra el servidor nombrado con salida csv guardada en un archivo tmp
    /usr/local/bin/speedtest --csv --server $1 > /usr/local/etc/speedtest.tmp
    if [ $? -gt 0 ] 
    then
        # speedtest falló, así que crea una entrada cero en lugar de cualquier mensaje de error
        getCSVString $1 > /usr/local/etc/speedtest.tmp
    fi

    # guardar salida lista para la siguiente prueba de servidor
    cat /usr/local/etc/speedtest.tmp >> /usr/local/etc/speedtest.csv
}

# principal
#######
# ejecutar speedtest contra 3 servidores y guardar todos los resultados de salida en un archivo csv
cd /usr/local/etc

# limpiar archivo csv - necesita estar vacío al inicio de la ejecución
rm -f /usr/local/etc/speedtest.csv

############################################
# caso de prueba/debug - fuerza a speedtest a fallar
############################################
# runTest "199999999"
# sleep 5
####### comentar después de la prueba ##########
############################################

runTest "5443"
sleep 10

runTest "1234"
sleep 10

runTest "1783"
sleep 1

# ahora importa los datos csv en la base de datos sqlite
sqlite3 -batch /usr/local/etc/bandwidth.db <<"EOF"
.separator ","
.import /usr/local/etc/speedtest.csv bandwidth
EOF

# agregar la ejecución actual del csv a la copia de seguridad
cat /usr/local/etc/speedtest.csv >> /usr/local/etc/speedtest.bak

Pido disculpas por mi enfoque “cinturón y tirantes” de usar rutas completas para archivos en todas partes, incluso cuando no es necesario. Es solo la forma en que me gusta hacerlo. Siéntete libre de mejorar esto si te sientes cómodo editando scripts bash.

Establece las propiedades del archivo para hacer que este script sea ejecutable:

# chmod 0700 bandwidth.sh

5 Crear una base de datos SQLite

Crea la base de datos SQLite bandwidth.db en /usr/local/etc:

#sqlite3 bandwidth.db

y luego, en el aviso sqlite>, crea una nueva tabla con el siguiente comando (no te olvides del punto y coma final):

sqlite> CREATE TABLE IF NOT EXISTS "bandwidth" ("serverid" INTEGER NOT NULL , "sponsor" VARCHAR NOT NULL , "servername" VARCHAR NOT NULL , "times" DATETIME PRIMARY KEY NOT NULL UNIQUE , "distance" FLOAT NOT NULL , "ping" FLOAT NOT NULL , "download" FLOAT NOT NULL , "upload" FLOAT NOT NULL );
sqlite> .quit

Esto crea una tabla llamada bandwidth con campos que se mapean directamente en el formato de salida CSV de speedtest.

6 Obtener una lista de servidores

Necesitarás una lista de los servidores que usa speedtest.

# speedtest --list > servers.txt

Ahora revisa servers.txt para los ids numéricos del servidor o servidores contra los que deseas ejecutar tus pruebas.

# nano servers.txt

El archivo se verá similar a esto:

Recuperando configuración de speedtest.net...
 5833) Hub Network Services Ltd (Newport, Gales) [57.50 km]
 5938) Spectrum Internet (Cardiff, Gran Bretaña) [65.89 km]
 5443) Fasthosts Internet (Gloucester, Gran Bretaña) [74.31 km]
 6504) Secure Web Services Ltd (Shrewsbury, Gran Bretaña) [78.64 km]
 7265) Unitron Systems & Development Ltd (Telford, Gran Bretaña) [87.11 km]
 8225) Exascale Limited (Wolverhampton, Gran Bretaña) [96.08 km]
 3110) zero.net.uk Ltd (Studley, Gran Bretaña) [96.12 km]
12401) Dragon WiFi LTD (Haverfordwest, Reino Unido) [120.78 km]
 1153) Warwicknet Ltd. (Coventry, Gran Bretaña) [125.18 km]
 1685) Vodafone UK (Newbury, Gran Bretaña) [153.25 km]
 4384) Iomart (Leicester, Gran Bretaña) [157.40 km]
 1234) Uno (Milton Keynes, Gran Bretaña) [170.71 km]
 3504) TNP Ltd. (Manchester, Gran Bretaña) [170.93 km]
11747) Vispa (Manchester, Reino Unido) [170.93 km]

Los ids de servidor están en el lado izquierdo. La cifra al final de cada línea es la estimación que speedtest ha hecho de la distancia, en kilómetros, entre tu ubicación y la del servidor, aunque no estoy seguro de que sea muy precisa y puede cambiar de ejecución a ejecución. Los servidores de prueba se enumerarán en orden de esta distancia comenzando con el más cercano. Probar contra los servidores cerca de la parte superior de esta lista debería, en teoría, darte los pings más rápidos y las mejores velocidades de descarga y carga en comparación con los servidores más abajo en la lista que están mucho más lejos.

7 Seleccionar ids de servidor y editar bandwidth.sh

Ahora sería el momento de ejecutar speedtest manualmente contra una selección de los diferentes ids de servidor disponibles y ver qué tipo de resultados obtienes. Elegí un par de servidores cerca de mí en el Reino Unido y uno en California para comparación. El formato del comando a usar es:

# speedtest --server 1234

La salida que ves será similar a:

Recuperando configuración de speedtest.net...
Probando desde xxxxxxx (n.n.n.n)...
Recuperando lista de servidores de speedtest.net...
Seleccionando el mejor servidor basado en ping...
Alojado por Uno (Milton Keynes) [187.87 km]: 33.243 ms
Probando velocidad de descarga................................................................................
Descarga: 1.60 Mbit/s
Probando velocidad de carga...............................................................................................
Carga: 0.55 Mbit/s

Una vez que hayas seleccionado los servidores que deseas usar, coloca los ids numéricos de servidor (he usado 3 servidores, pero puedes variar esto si lo deseas) en las líneas relevantes en bandwidth.sh

runTest "5443"
sleep 10

runTest "1234"
sleep 10

runTest "1783"
sleep 1

También necesitarás ajustar el código en la rutina de error que crea una entrada ficticia si speedtest debería fallar en alguna ejecución particular.

    # ¿contra qué servidor estamos probando?
    if [ $1 = "5443" ] 
    then
        echo "5443,Fasthosts Internet,Gloucester,$RIGHTNOW,73.09,0.0,0.0,0.0"
    fi
    if [ $1 = "1234" ] 
    then
        echo "1234,Uno,Milton Keynes,$RIGHTNOW,168.27,0.0,0.0,0.0"
    fi
    if [ $1 = "1783" ] 
    then
        echo "1783,Comcast,\"San Francisco, CA\",$RIGHTNOW,8420.0,0.0,0.0,0.0"
    fi

Los números después de $RIGHTNOW en allí (por ejemplo, 73.09) son las distancias en kilómetros desde tu ubicación hasta el servidor en cuestión. No uso estos en ningún lugar, así que son solo un marcador de posición y podrían ser cualquier valor numérico.

Ten en cuenta que en el ejemplo 1783 tenemos que poner comillas en la ubicación y escaparlas para poder incluirlas en el archivo CSV que estamos creando. Las comillas son necesarias aquí porque esta ubicación tiene una coma dentro. Sin las comillas escapadas, la coma se trataría como un delimitador de campo CSV, lo que causaría un problema con la importación de SQLite. Si el servidor que seleccionas tiene un texto de ubicación similar con una coma, entonces necesitarás usar las comillas escapadas.

8 Configurar un cronjob

Configura un cronjob para ejecutarse una vez por hora (o tan a menudo como desees dentro de lo razonable) para ejecutar /usr/local/etc/bandwidth.sh. Si estás ejecutando ISPConfig, entonces puedes usarlo para programar un cronjob.

Crear cronjob

Alternativamente, en la línea de comandos de linux podrías ingresar:

# crontab -e

Deberías ver algo similar a esto (recuerda que estás conectado como ‘root’):

* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
* * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
1 * * * * /usr/local/etc/bandwidth.sh 2>&1

Si no estás ejecutando ISPConfig, entonces esto puede estar inicialmente vacío. Agrega esa última línea exactamente como se muestra arriba - el espaciado es importante - para ejecutar el script de shell comenzando a las 00:01 AM y luego repetir cada hora, todos los días. Puedes elegir diferentes horas, por supuesto. (La primera vez que ejecutes esto, crontab te preguntará qué editor deseas usar - selecciono nano.)

9 Establecer PHP open_basedir

Agrega /usr/local/etc a la entrada open_basedir de PHP para el sitio web. En ISPConfig, esto se encuentra en la pestaña Opciones para el sitio web.

Establecer open_basedir

Esto permite que el código bandwidth.php pueda acceder a la base de datos SQLite, que acabamos de crear, en ese directorio.

Podríamos haber omitido esto si hubiéramos decidido crear la base de datos en un directorio que ya esté configurado como accesible, como /var/www/clients/client1/web1/web/, pero eso sería una mala elección desde una perspectiva de seguridad.

10 Crear bandwidth.php

Necesitas copiar este código en un archivo llamado bandwidth.php en tu servidor en el directorio base de documentos web. Si estás usando ISPConfig, esto será algo como /var/www/clients/client1/web1/web/

 
 
 
Monitor de Ancho de Banda - velocidades de descarga en las últimas 24 horas




Velocidades de descarga - últimas 24 horas

Edita este archivo para usar el serverid que deseas informar. Estoy usando el servidor 1234 en mi ejemplo aquí, ya que descubrí que, después de explorar unos días de datos, este servidor estaba produciendo cifras de Mbps más alineadas con las velocidades que sentía que estaba obteniendo. El serverid está en la cláusula WHERE de la declaración SQL SELECT:

SELECT serverid, strftime("%H:%M", times) || " " || strftime("%d/%m/%Y", times) AS timestamp, sponsor, servername,   
download   
FROM bandwidth   
WHERE serverid = 1234   
ORDER BY times   
LIMIT 24 OFFSET (SELECT COUNT(*)/3 FROM bandwidth)-24;

¿Qué está haciendo exactamente esta declaración SQL? Si no estás familiarizado con SQL, entonces veamos cada parte.

a. SELECT es el comando para leer registros de una tabla de base de datos SQL y es seguido por los campos a leer y otras opciones.

b. strftime(“%H:%M”, times) || “ “ || strftime(“%d/%m/%Y”, times) AS timestamp

es para reformatear la cadena de fecha y hora que speedtest ha creado en su salida CSV a algo un poco más amigable. Quiero fechas formateadas al estilo del Reino Unido, así que esto tomará una cadena como “2017-08-31T12:02:51.898186Z” y la convierte en “12:02 31/08/2017”. Es más simple hacer este reformateo directamente en la declaración SQL en lugar de tener que procesarlo después. Las horas aquí van a ser UTC/GMT, lo cual está bien para mí, pero puede que desees cambiar esto; por ejemplo, si quieres fechas formateadas al estilo de EE. UU., entonces cambia esa segunda parte a strftime(“%m/%d/%Y”, times).

c. serverid, timestamp, sponsor, servername, download son los campos que queremos leer de la tabla SQL y crear en nuestro objeto JSON.

d. FROM bandwidth es el nombre de la tabla SQL de la que estamos leyendo.

e. WHERE serverid = 1234 establece el subconjunto de la tabla que se va a leer - cambia esto para que coincida con el serverid que has usado, y puede que desees leer datos para más de un servidor - pero eso complicará el gráfico.

f. ORDER BY times establece el orden de salida - queremos que esté ordenado por la marca de tiempo que speedtest estableció para cada ejecución.

g. LIMIT 24 restringe la salida a 24 registros, ya que solo queremos mostrar 24 horas de datos y porque nuestro cronjob está configurado para ejecutarse una vez por hora. Si estuvieras ejecutando dos veces por hora, entonces necesitarías establecer esto en 48 para obtener 24 horas de datos.

h. OFFSET (SELECT COUNT()/3 FROM bandwidth)-24; queremos los últimos 24 registros de la tabla ya que son las entradas más recientes que nos interesan, así que tenemos que especificar un OFFSET para emparejar con el LIMIT. Sin esto, siempre estaríamos obteniendo los primeros 24 registros en la tabla en lugar de los 24 más recientes. Para obtener el desplazamiento correcto, contamos todos los registros en la tabla con (SELECT COUNT()) y luego dividimos esto por 3 (ya que estamos ejecutando speedtest 3 veces por hora, una vez para cada uno de los 3 servidores diferentes) y luego restamos 24 de este total para obtener la posición de OFFSET correcta para que LIMIT 24 obtenga los registros que queremos.

Si has cambiado el script bash para ejecutar algo diferente a 3 pruebas de servidor diferentes por hora, entonces ajusta esa parte /3 en consecuencia. Si solo estás probando contra un servidor, entonces la división no es necesaria en absoluto.

También puede que desees ajustar el tamaño general del gráfico, donde he tomado la ruta fácil de codificar un tamaño adecuado para mi pantalla - se establece en esta línea:

11 Obtener una copia local de los archivos

Prefiero tener versiones locales de cualquier archivo de css y js que se necesiten en una página web y si tú eres igual, entonces necesitarás obtener una copia en tu servidor de Chart.bundle.min.js y colocarla en el directorio /var/www/clients/client1/web1/web/scripts en tu servidor (o en el directorio base que sea correcto para ti).

Puedes descargar el archivo desde: https://cdnjs.cloudflare.com/ajax/libs/Chartajs/2.6.0/Chart.bundle.min.js

Si no deseas usar una copia local, entonces edita bandwidth.php para apuntar a la versión pública de CDN en su lugar. Simplemente cambia esta línea:

a esto:

12 Habilitar PHP en ISPConfig

No olvides habilitar PHP en la configuración de tu sitio web, si esto no se ha establecido ya.

Habilitar PHP en el sitio web

13 Cargar bandwidth.php en el navegador

Finalmente hemos terminado. Una vez que el script de shell bandwidth.sh ha tenido tiempo para ejecutarse varias veces para generar algunos datos (o podrías ejecutarlo manualmente varias veces al principio), apunta tu navegador al sitio web de tu servidor Linux, carga bandwidth.php y deberías ver algo como esto:

Gráfico de ancho de banda

Y sí, ¡mi banda ancha realmente es tan mala!

Finalmente, aquí hay algunos puntos adicionales que vale la pena cubrir:

14 Salida de gráfico de barras

Debemos notar que las cifras de descarga y carga almacenadas en la tabla SQL están en bps en lugar de Mbps (junto con un desconcertante número de dígitos decimales - números como 1533681.5922415722). Esta es simplemente la forma en que speedtest produce los datos cuando se ejecuta en modo CSV. Para mostrar la cifra de Mbps, en lugar de bps, en la salida del eje y del gráfico de barras hay un par de líneas incluidas en el código Javascript en bandwidth.php para realizar la conversión:

    mbps = Math.round(bandwidth_data[i].download/1000).toFixed(3)/1000; 
    bvalue = mbps.toLocaleString(undefined, { minimumFractionDigits: 3 });

Usar toLocaleString debería insertar la puntuación decimal correcta (un “.” o “,”) según la configuración regional de tu navegador, pero esto depende de la implementación y es algo inconsistente. Si ves . en lugar de , y te molesta, entonces Globalize es la forma de solucionar esto. Consulta ‘18 Pasos adicionales e ideas’ a continuación.

Se necesitan algunas líneas más para sobreescribir el tratamiento predeterminado del código de hover de ceros finales, ya que chart.js normalmente mostrará “2.000” como solo “2”, lo cual no es lo que quiero, especialmente después de haberme tomado la molestia de asegurarme de que están allí en primer lugar:

    // sobreescribimos el tooltip predeterminado que elimina ceros finales aunque ya los pusimos allí
    tooltips: {
        callbacks: {
            label: function(tooltipItem, data) {
                var value = data.datasets[0].data[tooltipItem.index];
                var label = 'descarga: ';
                var retvalue = value.toLocaleString(undefined, { minimumFractionDigits: 3 });
                return label + ' ' + retvalue + ' Mbps';
            }
        }
    },

Este es un buen ejemplo de cómo puedes ‘profundizar’ en chart.js y cambiar la forma en que hace las cosas.

Además, he establecido las opciones del gráfico para imprimir la marca de tiempo en el eje x para cada barra:

    xAxes: [{
        ticks: {
            autoSkip: false,
            maxTicksLimit: 24
        }
    }],

La opción predeterminada (con autoSkip configurado como verdadero) resultó en un par de huecos extraños en las etiquetas. Necesitarás cambiar maxTicksLimit si deseas mostrar algo diferente a 24 entradas.

Si deseas más ayuda para cambiar cualquiera de las opciones de chart.js o no puedes hacer que lo que deseas funcione, entonces consulta las páginas específicas de chart.js en Stack Overflow; hay mucha información útil allí - https://stackoverflow.com/questions/tagged/chart.js - Solo usa el cuadro de búsqueda para reducir lo que estás buscando. Desafortunadamente, la documentación de chart.js carece de algunos de los ejemplos más avanzados que sin duda serían de gran ayuda para familiarizarse con este magnífico código de código abierto.

15 Manejo de errores

Durante mis pruebas iniciales, noté un par de veces que speedtest informó “No se puede recuperar la lista de servidores de speedtest” en el archivo CSV. Presumiblemente, esto reflejaba los momentos en que mi conexión de banda ancha era tan mala que speedtest no podía conectarse al servidor de prueba en absoluto. Este texto, obviamente, no está en un formato que deseamos importar en la base de datos SQLite, así que necesitaba una solución para esto que eliminara este texto no deseado del archivo CSV y también incluyera una entrada cero en la base de datos para el intervalo de tiempo específico, ya que de lo contrario cualquier entrada faltante en la tabla SQL simplemente sería invisible y también arruinaría la alineación que quería tener de tener 24 entradas por día al crear el gráfico.

Verás en bandwidth.sh que el script prueba el código de salida establecido por speedtest usando la variable de script $? y si es mayor que cero, esto indica que speedtest falló. Esto activará la función para crear una entrada CSV ficticia - que luego se usa para sobrescribir el archivo CSV para esa ejecución.

Hay un par de líneas en el script bash que están comentadas, pero que probarán esta rutina de error para generar una entrada cero ficticia si ejecutas el script después de descomentar esas líneas.

############################################
# caso de prueba/debug - fuerza a speedtest a fallar
############################################
# runTest "199999999"
# sleep 5
####### comentar después de la prueba ##########
############################################

Esto utiliza un id de servidor ‘sin sentido’ que speedtest no acepta, lo que provoca que devuelva un código de salida no cero. El script entonces debería crear una entrada ficticia que puede sentarse felizmente en la tabla SQL y ser ignorada o podrías eliminarla.

Otra forma de forzar a speedtest a fallar, para este propósito de prueba, sería desconectar la conexión de red del servidor. No olvides que puedes ejecutar el script bandwidth.sh manualmente en cualquier momento, no tienes que esperar a que el cronjob lo dispare, aunque deberías evitar ejecutarlo manualmente si un cronjob está a punto de ejecutarse. Tener dos scripts ejecutándose simultáneamente probablemente desordenaría los archivos CSV y luego la tabla SQL.

Si lo peor sucede, entonces hay un archivo CSV de respaldo mantenido como /usr/local/etc/speedtest.bak que debería contener toda la salida CSV de speedtest desde la primera ejecución del script bash en adelante. Esto podría ser editado para eliminar cualquiera de las entradas no deseadas, la tabla SQL borrada y luego todo el conjunto de entradas CSV reimportadas en SQLite.

16 Zonas horarias

Speedtest informa la hora en UTC (básicamente esto es lo mismo que la Hora Media de Greenwich o GMT). Usar UTC significa que todas las horas almacenadas en la tabla SQL son consistentes, y el horario de verano no tendrá ningún impacto no deseado.

Pero esto significa que la rutina de manejo de errores en bandwidth.sh necesita crear una marca de tiempo para la entrada ficticia para reflejar esto. Esto es bastante simple - solo incluimos la bandera –utc:

local RIGHTNOW=$(date --utc +%Y-%m-%dT%H:%M:%SZ)

Si deseas que las etiquetas del eje x del gráfico muestren horas como algo diferente a UTC/GMT, entonces el mejor lugar para hacer tal cambio sería en la declaración SQL SELECT, por ejemplo:

strftime("%H:%M", time(times, 'localtime')) || " " || strftime("%d/%m/%Y", times) AS timestamp

Esto usaría la configuración de zona horaria de tu servidor Linux para ajustar las horas mostradas en el gráfico. O podrías profundizar para averiguar cómo Globalize podría hacer esto en el front-end.

Consulta https://www.timeanddate.com/time/gmt-utc-time.html y http://www.tutorialspoint.com/sqlite/sqlite_date_time.htm para más información.

17 Pasos adicionales e ideas

Speedtest no necesita ser la fuente de tus datos en bruto - podría venir de cualquier lugar y ser para cualquier cosa, no solo velocidad de Internet. El principio es el mismo - un proceso de servidor backend que puede obtener los datos en bruto en un formato útil y luego importarlos en SQLite desde un script bash con un front-end que extrae el subconjunto de datos que deseas y luego lo grafica.

Un script bash más complejo podría escribir datos directamente en una tabla SQL (usando el comando SQL INSERT) si formatear como CSV no es una opción. Cuando diseñes la tabla SQL, piensa en cómo querrás extraer los datos más tarde.

Al hacer cualquier cambio, ten en cuenta el contexto del código que estás editando; es decir, tenemos declaraciones SQL dentro de un script PHP dentro de Javascript dentro de HTML. Recuerda el nivel en el que estás y codifica en consecuencia. Puede ser fácil perder la pista y terminar escribiendo código PHP en lo que debería ser Javascript. ¡Puedo garantizar que esto no funcionará!

Aquí hay algunas ideas para una mayor exploración:

  • toLocaleString no está implementado de manera consistente en todos los navegadores. Usa Globalize y maneja todos los formatos de número, fecha y zona horaria con él.
  • Consulta httpstat (hay una versión de script bash) que permite recopilar diferentes tipos de datos de conexión a Internet. Almacena esto en una (separada) tabla SQL y grafica la salida.
  • Mejora el front-end de bandwidth.php para dar al usuario la opción de diferentes opciones: 24, 48, 72 horas; seleccionar una fecha específica, incluir datos de carga y descarga, tiempos de ping.
  • Convierte el HTML para usar código Bootstrap responsivo para que funcione bien en diferentes dispositivos o tamaños de pantalla.
  • Explora algunas de las otras opciones de chart.js; tal vez un gráfico combinado de líneas y barras; cambia los colores y el tamaño de las barras.
  • reemplaza SQLite con MySQL y agrega más seguridad con acceso de lectura desde PHP a través de usuario/contraseña.
  • Construye un sistema similar pero usando node.js.

18 Enlaces

Share: X/Twitter LinkedIn

Recibe nuevas publicaciones en tu bandeja de entrada.

No spam. Cancela la suscripción en cualquier momento.