Como usar speedtest em um servidor Linux para verificar, armazenar e relatar velocidades de internet graficamente

Seguindo um conjunto de problemas de conectividade de banda larga ruim que eu estava enfrentando, decidi que queria monitorar a velocidade em Mbps que estava recebendo do meu provedor regularmente. Eu estava vendo números especialmente ruins ao tentar baixar arquivos à noite, com velocidades muito mais rápidas alcançadas muito cedo pela manhã.

Eu tenho um servidor Linux Debian sentado em um canto, que é minha máquina de teste e desenvolvimento para sites hospedados no ISPConfig, além de algum código Let’s Encrypt com o qual gosto de brincar, então procurei algum software que permitisse testes de largura de banda, executável a partir de uma linha de comando Linux, que pudesse formar a base de um sistema de script shell automatizado para produzir os dados brutos que eu precisava. Eu queria armazenar os dados em um banco de dados SQL para facilitar as consultas (eu poderia então facilmente reunir mais dados e apenas extrair um subconjunto menor para períodos de tempo que me interessavam) e ter uma interface web que pudesse produzir um gráfico simples para visualizar os dados e ajudar a destacar os problemas de conectividade.

O primeiro resultado da minha pesquisa foi o artigo realmente útil de Antonio Valencia em: https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/

Após seguir as instruções lá para instalar o speedtest, um rápido teste mostrou que eu poderia usá-lo para executar testes contra um amplo conjunto de servidores de internet e também produzir saída em formato CSV, que é bastante adequado para ser importado diretamente em uma tabela SQL com o mínimo de esforço em desenvolvimento de software.

Para a quantidade relativamente pequena de dados que seria gerada, decidi usar SQLite como o armazenamento de back-end e uma rápida pesquisa das bibliotecas de gráficos baseadas em javascript de código aberto disponíveis me levou ao chart.js, que tem um design simples e limpo com uma interface de dados simples, mas muita capacidade de ajustar opções avançadas, se necessário. Converter dados SQL para extrair apenas o subconjunto de dados que eu queria graficar com saída via JSON através de algum código PHP direto foi o caminho a seguir.

Então, no geral, eu precisava projetar um sistema que se parecesse com isso:

Um servidor Linux executando speedtest como um cronjob - talvez 1 por hora - com a saída do speedtest sendo armazenada em um banco de dados SQLite - tudo controlado por um arquivo de script shell bash. Uma interface web, sendo uma mistura de HTML, CSS, javascript e PHP para extrair dados do SQLite e produzir um gráfico de barras mostrando os números de Mbps alcançados nas 24 horas anteriores (ou qualquer outro período que eu pudesse decidir).

Um pouco de experimentação com a execução do speedtest uma dúzia de vezes interativamente me mostrou que havia alguns servidores disponíveis que pareciam dar resultados que estavam muito alinhados com os tipos de velocidades que eu estava experimentando. Eu considerei uma boa ideia testar contra mais de um servidor para ter uma melhor compreensão de como meus números de Mbps eram afetados pela localização do servidor alvo e pela hora do dia em um fuso horário diferente.

Se você quiser acompanhar e configurar um sistema semelhante para si mesmo, então você precisará selecionar um ou mais servidores entre os centenas disponíveis para o speedtest que se adequem à sua localização.

1 Pré-requisitos

um servidor linux - estou usando Debian 9.1 - stretch
acesso tty ao servidor com login root - eu uso PuTTY de um laptop Windows
ISPConfig instalado e um site configurado com uma conta FTP também - estou usando 3.1.6 com apache configurado como o servidor web (você poderia gerenciar apenas com um servidor web, com algumas pequenas mudanças nas instruções a seguir)
PHP - estou usando 7.0, mas isso deve funcionar com a maioria das versões anteriores também
cliente FTP - eu uso Filezilla - e PureFTPd rodando no servidor
nano - ou seu editor visual favorito

Estou assumindo aqui que você está confortável em fazer login em um servidor Linux, como navegar pelos diretórios, o layout de onde seu servidor web espera que os arquivos estejam e como transferir arquivos para esses diretórios via FTP.

Aqui estão os passos detalhados para permitir que você configure tudo isso.

2 Instalar speedtest

Faça login no seu servidor linux como root e execute o comando:

# pip install speedtest-cli

Veja https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/ e https://pypi.python.org/pypi/speedtest-cli para mais informações se você tiver algum problema.

Nota: speedtest e speedtest-cli são idênticos na minha instalação, então eu apenas farei referência ao speedtest a seguir.

3 Instalar SQLite3

# apt-get install sqlite3

Use o equivalente para sua distribuição se apt-get não for para você.

4 Criar bandwidth.sh

Digite o seguinte código do script bash em um arquivo e salve-o como /usr/local/etc/bandwidth.sh - vamos editar isso um pouco mais tarde para torná-lo específico para você.

#!/bin/bash
# executar speedtests contra 3 servidores e salvar todos os resultados de saída em um arquivo CSV para importação no banco de dados sqlite
#
# executado por cronjob uma vez por hora
#
#
function getCSVString () {
    # se o speedtest falhar (por exemplo, não conseguiu acessar um servidor) precisamos criar uma entrada dummy zero para este intervalo de tempo
    
    # obter uma string de timestamp no mesmo formato que o speedtest gera - e precisamos do horário UTC
    local RIGHTNOW=$(date --utc +%Y-%m-%dT%H:%M:%SZ)
    
    # contra qual servidor estamos testando?
    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 teste/debug apenas
    if [ $1 = "199999999" ]
    then
        echo "99999,Teste,Teste,$RIGHTNOW,99.99,0.0,0.0,0.0"
    fi
}

function runTest () {
    # executar speedtest contra o servidor nomeado com saída csv salva em arquivo tmp
    /usr/local/bin/speedtest --csv --server $1 > /usr/local/etc/speedtest.tmp
    if [ $? -gt 0 ] 
    then
        # speedtest falhou, então crie uma entrada zero no lugar de qualquer mensagem de erro
        getCSVString $1 > /usr/local/etc/speedtest.tmp
    fi

    # salvar saída pronta para o próximo teste de servidor
    cat /usr/local/etc/speedtest.tmp >> /usr/local/etc/speedtest.csv
}

# principal
#######
# executar speedtest contra 3 servidores e salvar todos os resultados de saída em arquivo csv
cd /usr/local/etc

# limpar arquivo csv - precisa estar vazio no início da execução
rm -f /usr/local/etc/speedtest.csv

############################################
# caso de teste/debug - força o speedtest a falhar
############################################
# runTest "199999999"
# sleep 5
####### comente após o teste ##########
############################################

runTest "5443"
sleep 10

runTest "1234"
sleep 10

runTest "1783"
sleep 1

# agora importe os dados csv no banco de dados sqlite
sqlite3 -batch /usr/local/etc/bandwidth.db <<"EOF"
.separator ","
.import /usr/local/etc/speedtest.csv bandwidth
EOF

# adicionar a execução atual do csv ao backup
cat /usr/local/etc/speedtest.csv >> /usr/local/etc/speedtest.bak

Peço desculpas pela minha abordagem “cinto e fivela” de usar caminhos completos para arquivos em todos os lugares, mesmo quando não é necessário. É apenas a maneira como gosto de fazer. Sinta-se à vontade para melhorar isso se você estiver confortável com a edição de scripts bash.

Defina as propriedades do arquivo para tornar este script executável:

# chmod 0700 bandwidth.sh

5 Criar um banco de dados SQLite

Crie o banco de dados SQLite bandwidth.db em /usr/local/etc:

#sqlite3 bandwidth.db

e então, no prompt sqlite>, crie uma nova tabela com o seguinte comando (não perca o ponto e vírgula 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

Isso cria uma tabela chamada bandwidth com campos que mapeiam diretamente para o formato de saída CSV do speedtest.

6 Obter uma lista de servidores

Você precisará de uma lista dos servidores que o speedtest usa.

# speedtest --list > servers.txt

Agora verifique servers.txt para os ids numéricos do(s) servidor(es) que você deseja executar seus testes.

# nano servers.txt

O arquivo ficará semelhante a isto:

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

Os ids dos servidores estão no lado esquerdo. O número no final de cada linha é a estimativa que o speedtest fez da distância, em quilômetros, entre sua localização e a do servidor, embora eu não tenha certeza de que isso seja muito preciso e pode mudar de execução para execução. Os servidores de teste serão listados em ordem de distância começando com o mais próximo. Testar contra os servidores próximos ao topo desta lista deve, em teoria, fornecer os pings mais rápidos e as melhores velocidades de download e upload em comparação com servidores mais abaixo na lista que estão muito mais longe.

7 Selecionar ids de servidores e editar bandwidth.sh

Agora seria a hora de executar o speedtest manualmente contra uma seleção dos diferentes ids de servidores disponíveis e ver que tipo de resultados você obtém. Eu escolhi alguns servidores próximos a mim no Reino Unido e um na Califórnia para comparação. O formato do comando a ser usado é:

# speedtest --server 1234

A saída que você verá será semelhante a:

Recuperando configuração do speedtest.net...
Testando de xxxxxxx (n.n.n.n)...
Recuperando lista de servidores do speedtest.net...
Selecionando o melhor servidor com base no ping...
Hospedado por Uno (Milton Keynes) [187.87 km]: 33.243 ms
Testando velocidade de download................................................................................
Download: 1.60 Mbit/s
Testando velocidade de upload...............................................................................................
Upload: 0.55 Mbit/s

Uma vez que você tenha selecionado os servidores que deseja usar, coloque os ids numéricos dos servidores (eu usei 3 servidores, mas você pode variar isso se desejar) nas linhas relevantes em bandwidth.sh

runTest "5443"
sleep 10

runTest "1234"
sleep 10

runTest "1783"
sleep 1

Você também precisará ajustar o código na rotina de erro que cria uma entrada dummy se o speedtest falhar em qualquer execução específica.

    # contra qual servidor estamos testando?
    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

Os números após $RIGHTNOW ali (por exemplo, 73.09) são as distâncias em quilômetros da sua localização até o servidor em questão. Eu não uso esses números em lugar nenhum, então eles são apenas um espaço reservado e poderiam ser qualquer valor numérico.

Note que, no exemplo 1783, temos que colocar aspas na localização e escapá-las para que entrem no arquivo CSV que estamos criando. As aspas são necessárias aqui porque esta localização acontece de ter uma vírgula dentro dela. Sem as aspas escapadas, a vírgula seria tratada como um delimitador de campo CSV, o que causaria um problema com a importação do SQLite. Se o servidor que você selecionar tiver um texto de localização semelhante com uma vírgula, então você precisará usar as aspas escapadas.

8 Configurar um cronjob

Configure um cronjob para executar uma vez por hora (ou com a frequência que você quiser, dentro do razoável) para executar /usr/local/etc/bandwidth.sh. Se você estiver executando o ISPConfig, poderá usá-lo para agendar um cronjob.

Criar cronjob

Alternativamente, na linha de comando do linux, você poderia digitar:

# crontab -e

Você deve ver algo semelhante a isto (lembre-se de que você está logado 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

Se você não estiver executando o ISPConfig, então isso pode estar inicialmente vazio. Adicione essa última linha exatamente como mostrado acima - o espaçamento é importante - para executar o script shell começando às 00:01 e depois repetir a cada hora, todos os dias. Você pode escolher horários diferentes, é claro. (Na primeira vez que você executar isso, o crontab perguntará qual editor você deseja usar - eu seleciono nano.)

9 Definir open_basedir do PHP

Adicione /usr/local/etc à entrada open_basedir do PHP para o site. No ISPConfig, isso é encontrado na aba Opções para o Website.

Definir open_basedir

Isso permite que o código bandwidth.php acesse o banco de dados SQLite que acabamos de criar, nesse diretório.

Poderíamos ter pulado isso se tivéssemos decidido criar o banco de dados em um diretório que já está definido como acessível, como /var/www/clients/client1/web1/web/, mas isso seria uma má escolha do ponto de vista de segurança.

10 Criar bandwidth.php

Você precisa copiar este código para um arquivo chamado bandwidth.php em seu servidor no diretório base do documento web. Se você estiver usando o ISPConfig, isso será algo como /var/www/clients/client1/web1/web/

 
 
 
Monitor de Largura de Banda - velocidades de download nas últimas 24 horas





Velocidades de download - últimas 24 horas

Edite este arquivo para usar o serverid que você deseja relatar. Estou usando o servidor 1234 no meu exemplo aqui, pois descobri que, após explorar alguns dias de dados, este servidor estava produzindo números de Mbps mais alinhados com as velocidades que eu sentia que estava obtendo. O serverid está na cláusula WHERE da instrução 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;

O que exatamente esta instrução SQL está fazendo? Se você não estiver familiarizado com SQL, então vamos olhar cada parte.

a. SELECT é o comando para ler registros de uma tabela de banco de dados SQL e é seguido pelos campos a serem lidos e outras opções.

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

é para reformatar a string de data e hora que o speedtest criou em sua saída CSV para algo um pouco mais amigável. Eu quero datas formatadas no Reino Unido, então isso pegará uma string como “2017-08-31T12:02:51.898186Z” e a transformará em “12:02 31/08/2017”. É mais simples fazer essa reformatação diretamente na instrução SQL do que ter que processá-la depois. Os horários aqui vão ser UTC/GMT, o que está OK para mim, mas você pode querer mudar isso; por exemplo, se você quiser datas formatadas nos EUA, então mude essa segunda parte para strftime(“%m/%d/%Y”, times).

c. serverid, timestamp, sponsor, servername, download são os campos que queremos ler da tabela SQL e criar em nosso objeto JSON.

d. FROM bandwidth é o nome da tabela SQL da qual estamos lendo.

e. WHERE serverid = 1234 define o subconjunto da tabela a ser lido - mude isso para corresponder ao serverid que você usou, e você pode querer ler dados para mais de um servidor - mas isso complicará o gráfico.

f. ORDER BY times define a ordem de saída - queremos que seja ordenada pelo timestamp que o speedtest definiu para cada execução.

g. LIMIT 24 restringe a saída a 24 registros, pois só queremos mostrar 24 horas de dados e porque nosso cronjob está configurado para executar uma vez por hora. Se você estivesse executando duas vezes por hora, então precisaria definir isso como 48 para obter 24 horas de dados.

h. OFFSET (SELECT COUNT()/3 FROM bandwidth)-24; queremos os últimos 24 registros da tabela, pois são as entradas mais recentes que nos interessam, então precisamos especificar um OFFSET para combinar com o LIMIT. Sem isso, estaríamos sempre obtendo os primeiros 24 registros na tabela, em vez dos 24 mais recentes. Para obter o offset correto, contamos todos os registros na tabela com (SELECT COUNT()) e depois dividimos isso por 3 (já que estamos executando speedtest 3 vezes por hora, uma para cada um dos 3 servidores diferentes) e então subtraímos 24 desse total para obter a posição OFFSET correta para que LIMIT 24 obtenha os registros que queremos.

Se você alterou o script bash para executar algo diferente de 3 testes de servidores diferentes por hora, então ajuste essa parte /3 de acordo. Se você estiver testando contra um único servidor, então a divisão não é necessária.

Você também pode querer ajustar o tamanho geral do gráfico, onde eu tomei a rota fácil de codificar um tamanho adequado para a minha tela - está definido nesta linha:

11 Obter uma cópia local dos arquivos

Eu prefiro ter versões locais de quaisquer arquivos de css e js que são necessários em uma página web (mas não fontes do Google) e se você for o mesmo, então você precisará obter uma cópia no seu servidor do Chart.bundle.min.js e colocá-la no diretório /var/www/clients/client1/web1/web/scripts em seu servidor (ou em qual seja o diretório base certo para você).

Você pode baixar o arquivo em: https://cdnjs.cloudflare.com/ajax/libs/Chartajs/2.6.0/Chart.bundle.min.js

Se você não quiser usar uma cópia local, então edite bandwidth.php para apontar para a versão pública do CDN em vez disso. Basta mudar esta linha:

para isto:

12 Habilitar PHP no ISPConfig

Não se esqueça de habilitar o PHP nas configurações do seu Website, se isso ainda não tiver sido definido.

Habilitar PHP no website

13 Carregar bandwidth.php no navegador

Finalmente terminamos. Uma vez que o script shell bandwidth.sh teve tempo para rodar algumas vezes para gerar alguns dados (ou você poderia executá-lo manualmente várias vezes no início), aponte seu navegador para o site do seu servidor Linux, carregue bandwidth.php e você deve ver algo como isto:

Gráfico de Largura de Banda

E sim, minha banda larga realmente é tão ruim!

Finalmente, aqui estão alguns pontos extras que valem a pena cobrir:

14 Saída do Gráfico de Barras

Devemos notar que os números de download e upload armazenados na tabela SQL estão em bps, em vez de Mbps (junto com um número desconcertante de dígitos decimais - números como 1533681.5922415722). Esta é apenas a maneira como o speedtest produz os dados quando executado em modo CSV. Para mostrar o número de Mbps, em vez de bps, no eixo y da saída do gráfico de barras, há algumas linhas incluídas no código Javascript em bandwidth.php para realizar a conversão:

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

Usar toLocaleString deve inserir a pontuação decimal correta (um “.” ou “,”) conforme definido pela configuração de local do seu navegador, mas isso depende da implementação e é um tanto inconsistente. Se você ver . em vez de , e isso te incomoda, então o Globalize é o caminho para corrigir isso. Veja ‘18 Próximos passos e ideias’ abaixo.

Mais algumas linhas são necessárias para substituir o tratamento padrão do código de hover para zeros finais, já que o chart.js normalmente exibirá “2.000” como apenas “2”, o que não é o que eu quero, especialmente depois de ter ido ao trabalho de garantir que eles estão lá em primeiro lugar:

    // nós substituímos o tooltip padrão que remove zeros finais, mesmo que já os tenhamos colocado lá
    tooltips: {
        callbacks: {
            label: function(tooltipItem, data) {
                var value = data.datasets[0].data[tooltipItem.index];
                var label = 'download: ';
                var retvalue = value.toLocaleString(undefined, { minimumFractionDigits: 3 });
                return label + ' ' + retvalue + ' Mbps';
            }
        }
    },

Este é um bom exemplo de como você pode ‘aprofundar’ no chart.js e mudar a maneira como ele faz as coisas.

Além disso, eu defini as opções do gráfico para imprimir o timestamp no eixo x para cada barra:

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

A opção padrão (com autoSkip definida como verdadeira) resultou em alguns espaços em branco estranhos nos rótulos. Você precisará mudar maxTicksLimit se quiser exibir algo diferente de 24 entradas.

Se você quiser mais ajuda para mudar qualquer uma das opções do chart.js ou não conseguir fazer o que deseja funcionar, então por favor, verifique as páginas específicas do chart.js no Stack Overflow - há muitas informações úteis lá - https://stackoverflow.com/questions/tagged/chart.js - Basta usar a caixa de pesquisa para restringir o que você está procurando. Infelizmente, a documentação do chart.js é deficiente em alguns dos exemplos mais avançados que certamente seriam de grande ajuda para se familiarizar com este incrível código de código aberto.

15 Tratamento de Erros

Durante minhas execuções de teste iniciais, notei algumas vezes que o speedtest relatou “Não é possível recuperar a lista de servidores speedtest” no arquivo CSV. Presumivelmente, isso refletia os momentos em que minha conexão de banda larga estava tão ruim que o speedtest não conseguia se conectar ao servidor de teste. Este texto obviamente não está em um formato que queremos importar para o banco de dados SQLite, então eu precisava de uma solução para isso que descartasse esse texto indesejado do arquivo CSV e também incluísse uma entrada zero no banco de dados para o intervalo de tempo específico, pois, caso contrário, qualquer entrada ausente na tabela SQL simplesmente ficaria invisível e também desajustaria o alinhamento que eu queria de ter 24 entradas por dia ao criar o gráfico.

Você verá em bandwidth.sh que o script testa o código de saída definido pelo speedtest usando a variável de script $? e se for maior que zero, isso indica que o speedtest falhou. Isso acionará a função para criar uma entrada CSV dummy - que é então usada para sobrescrever o arquivo CSV para essa execução.

Há algumas linhas no script bash que estão comentadas, mas que testarão essa rotina de erro para gerar uma entrada dummy zero se você executar o script após descomentar essas linhas.

############################################
# caso de teste/debug - força o speedtest a falhar
############################################
# runTest "199999999"
# sleep 5
####### comente após o teste ##########
############################################

Isso usa um id de servidor ‘sem sentido’ que o speedtest não gosta, causando assim um código de saída não zero. O script então deve criar uma entrada dummy que pode ficar feliz na tabela SQL e ser ignorada ou você poderia deletá-la.

Outra maneira de forçar o speedtest a falhar, para este propósito de teste, seria remover a conexão de rede do servidor. Não se esqueça de que você pode executar o script bandwidth.sh manualmente a qualquer momento, você não precisa esperar que o cronjob o dispare, embora você deva evitar executá-lo manualmente se um cronjob estiver iminente. Ter dois scripts rodando simultaneamente provavelmente bagunçaria os arquivos CSV e, em seguida, a tabela SQL.

Se o pior acontecer, então há um arquivo CSV de backup mantido como /usr/local/etc/speedtest.bak que deve conter toda a saída CSV do speedtest desde a primeira execução do script bash. Isso poderia ser editado para remover qualquer uma das entradas indesejadas, a tabela SQL limpa e, em seguida, todo o conjunto de entradas CSV reimportado no SQLite.

16 Fusos Horários

O speedtest relata a hora em UTC (basicamente, isso é o mesmo que o Horário de Greenwich ou GMT). Usar UTC significa que todos os horários armazenados na tabela SQL são consistentes, e o Horário de Verão não terá nenhum impacto indesejado.

Mas isso significa que a rotina de tratamento de erros em bandwidth.sh precisa criar um timestamp para a entrada dummy para refletir isso. Isso é bem simples - nós apenas incluímos a flag –utc:

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

Se você quiser que os rótulos do eixo x do gráfico mostrem horários como algo diferente de UTC/GMT, então o melhor lugar para fazer tal mudança seria na instrução SQL SELECT, por exemplo:

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

Isso usaria as configurações de fuso horário do seu servidor Linux para ajustar os horários mostrados no gráfico. Ou você poderia mergulhar para descobrir como o Globalize poderia fazer isso no front-end.

Veja https://www.timeanddate.com/time/gmt-utc-time.html e http://www.tutorialspoint.com/sqlite/sqlite_date_time.htm para mais informações.

17 Próximos passos e ideias

O speedtest não precisa ser a fonte dos seus dados brutos - eles poderiam vir de qualquer lugar e ser para qualquer coisa, não apenas velocidade de internet. O princípio é o mesmo - um processo de servidor de back-end que pode obter os dados brutos em um formato útil e, em seguida, importá-los para o SQLite a partir de um script bash com um front-end que extrai o subconjunto de dados que você deseja e, em seguida, os gráficos.

Um script bash mais complexo poderia escrever dados diretamente em uma tabela SQL (usando o comando SQL INSERT) se formatar como CSV não for uma opção. Ao projetar a tabela SQL, pense em como você pode querer extrair os dados mais tarde.

Ao fazer quaisquer mudanças, tenha em mente o contexto do código que você está editando; ou seja, temos instruções SQL dentro de um script PHP dentro de Javascript dentro de HTML. Lembre-se do nível em que você está e codifique de acordo. Pode ser fácil perder a noção e acabar escrevendo código PHP no que deveria ser Javascript! Eu posso garantir que isso não funcionará.

Aqui estão algumas ideias para exploração adicional:

toLocaleString não é implementado de forma consistente entre navegadores. Use Globalize e trate todos os formatos de número, data e fuso horário com ele.
Confira httpstat (há uma versão em script bash) que permite coletar diferentes tipos de dados de conexão de internet. Armazene isso em uma tabela SQL (separada) e graficar a saída.
Melhore o front-end bandwidth.php para dar ao usuário a escolha de diferentes opções: 24, 48, 72 horas; selecionar uma data específica, incluir dados de upload e download, tempos de ping.
Converta o HTML para usar código Bootstrap responsivo para que funcione bem em diferentes dispositivos ou tamanhos de tela.
Explore algumas das outras opções do chart.js; talvez um gráfico combinado de linha e barra; mude as cores e o tamanho da barra.
substitua SQLite por MySQL e adicione mais segurança com acesso de leitura do PHP via usuário/senha.
Construa um sistema semelhante, mas usando node.js.