Como exportar dados de uso de rede do macOS

Você finalmente pegou o pico. Por três dias esteve se perguntando por que o uso de internet de casa pulou em horas aleatórias, e finalmente tem uma ferramenta aberta no momento certo para ver. E agora? Você quer esses dados fora da UI ao vivo e em algo que possa analisar, compartilhar com um colega ou correlacionar com um log de servidor. A capacidade de exportar dados de uso de rede do macOS importa mais do que as pessoas percebem, e o macOS tem opções decentes uma vez que você sabe onde olhar.

Este post percorre os caminhos práticos: nettop -L para capturas curtas, o unified log para eventos de rede do lado do sistema, scripts de amostragem para CSV e onde o ova armazena seus dados em disco.

Por que exportar dados de uso de rede do macOS

Alguns casos reais:

• Investigação de anomalia — você viu um upload de 2 GB às 3h, quer plotar o processo de origem ao longo da noite.
• Planejamento de capacidade — você está numa conexão tarifada ou com teto (Starlink Roam, Wi-Fi de hotel, tethering móvel) e quer saber o que é seguro deixar ligado.
• Debug de performance — seu time de servidor está perguntando quando os requests lentos começaram, e você quer sobrepor uso de rede do cliente nos logs deles.
• Orçamento de banda por projeto — você fatura clientes por hora e quer um sanity check do que os pipelines de build deles fizeram upload ontem.
• Curiosidade — você simplesmente quer olhar seus próprios dados.

Para todos esses, "abrir o Activity Monitor e ficar olhando" não dá. Você precisa de dados em disco, num formato que possa manipular.

Opção 1: modo log do nettop

O caminho de exportação mais simples é built-in. nettop -L <count> roda em modo log por <count> amostras, despejando cada amostra como linha de texto, e sai. Combinado com -J para escolher colunas e -s para definir intervalo, você ganha saída limpa que pode redirecionar para um arquivo.

nettop -L 600 -s 1 -P -J bytes_in,bytes_out,interface,state \
  > ~/Desktop/nettop-10min.txt

São 600 amostras em intervalo de um segundo — dez minutos de captura. Cada amostra lista cada processo ativo com as colunas que você pediu.

A saída não é exatamente CSV — tem cabeçalho por amostra, linhas em branco entre amostras e nomes de processo com espaços. Mas é parseável. Um pequeno script em awk ou Python transforma numa tabela limpa.

Limites do logging do nettop

• Só captura enquanto rodando. Se queria saber o que aconteceu ontem, sem sorte.
• Reporta cumulativo-desde-início-do-processo por padrão; você computa deltas você mesmo.
• Processos auxiliares aparecem como linhas separadas (sem agrupamento).
• O formato de amostra não é CSV de primeira classe; espere escrever um parser.

Para capturas ad-hoc de uma janela de tempo específica — "vou dar push no GitHub, deixa eu capturar cinco minutos em torno disso" — o nettop -L é ótimo. Para dados contínuos, você quer outra coisa.

Opção 2: o unified log

O unified log do macOS captura eventos estruturados de frameworks do sistema, incluindo rede. CFNetwork (a camada URLSession) e Network.framework ambos emitem linhas de log para ciclo de vida de conexão, handshake TLS, retries e falhas. Você pode extrair depois.

Para ver o que tem agora, consulte a última hora:

log show --last 1h --predicate 'subsystem == "com.apple.CFNetwork"' \
  --info --debug

Para exportar para um arquivo:

log show --last 24h --predicate 'subsystem == "com.apple.CFNetwork"' \
  --style compact > ~/Desktop/cfnetwork-day.log

Predicates úteis:

• subsystem == "com.apple.CFNetwork" — requests URLSession, TLS, redirects
• subsystem == "com.apple.network" — mudanças de path do Network.framework, estado de conexão
• process == "YourApp" — restringe a um app
• eventMessage CONTAINS "443" — busca de texto dentro das mensagens de log

O unified log mantém aproximadamente os últimos vários dias de eventos de sistema, dependendo do volume. Não é desenhado para contabilidade de bytes — é desenhado para auditoria de eventos. Mas se sua pergunta é "a conexão para api.example.com falhou às 14:23?", o unified log sabe.

log show vs log stream

log show lê o log histórico. log stream observa novos eventos ao vivo. Use log stream quando quiser deixar um terminal rodando e ver eventos enquanto acontecem:

log stream --predicate 'subsystem == "com.apple.network"' --level debug

Pipe para um arquivo com >> para anexar uma captura rotativa.

Opção 3: um script de amostragem custom

Se você quer saída CSV de banda por processo — o objetivo real para a maioria das pessoas — pode construir em 20 linhas de shell. A ideia: faça polling a cada N segundos, faça diff dos contadores cumulativos, emita CSV.

#!/usr/bin/env bash
# Sampler ingênuo de banda por processo.
INTERVAL=5
echo "timestamp,pid,process,delta_in,delta_out"
declare -A prev_in prev_out
while true; do
  ts=$(date +%s)
  while IFS=, read pid name in_bytes out_bytes; do
    pi=${prev_in[$pid]:-0}
    po=${prev_out[$pid]:-0}
    di=$((in_bytes - pi))
    do_=$((out_bytes - po))
    if (( di > 0 || do_ > 0 )); then
      echo "$ts,$pid,$name,$di,$do_"
    fi
    prev_in[$pid]=$in_bytes
    prev_out[$pid]=$out_bytes
  done < <(nettop -P -L 1 -J pid,interface,bytes_in,bytes_out 2>/dev/null \
            | awk 'NR>2 {print $2","$1","$3","$4}')
  sleep $INTERVAL
done

Isso é um esboço — código de produção lidaria com saídas de processo, agrupamento de auxiliares, rotação de log e o fato de que o formato de saída do nettop é chato de parsear — mas mostra o formato. Você amostra, faz diff, emite CSV. Rode sob caffeinate ou como agente launchd se quiser que sobreviva ao sleep.

Veja o ova em ação

Um monitor de banda na barra de menu para olhar de relance — local, assinado, ~3 MB.

Baixar para macOS

Opção 4: o banco local do ova

Um monitor de banda dedicado te poupa de escrever o script acima. O ova mantém um banco SQLite em:

~/Library/Application Support/ova/

O conteúdo são os mesmos dados de série temporal que você vê na UI: bytes in e out por app, amostrados a aproximadamente 1 Hz, com processos auxiliares agrupados sob o app pai. É local, sem sync de nuvem, sem telemetria. Você é dono do arquivo.

Por ser SQLite, qualquer coisa que lê SQLite lê: a CLI sqlite3, o módulo sqlite3 do Python, DB Browser for SQLite ou uma query rápida em DuckDB. Você pode:

• Exportar o histórico inteiro para CSV com um comando
• Rodar agregações ("qual app usou mais banda nessa semana, por hora")
• Fazer join com seus próprios logs (pipelines de build, logs de acesso de servidor, eventos de calendário)
• Fazer backup no seu alvo de backup normal

Uma exportação típica para CSV usando sqlite3:

sqlite3 -header -csv \
  ~/Library/Application\ Support/ova/<file>.sqlite \
  "SELECT timestamp, app, bytes_in, bytes_out FROM samples \
   WHERE timestamp > strftime('%s','now','-7 days') \
   ORDER BY timestamp" > ~/Desktop/last-week.csv

Receitas práticas, joins e privacidade

Uma vez que você tem um CSV — de qualquer fonte — algumas queries pagam o esforço.

Top apps por semana

SELECT app,
       SUM(bytes_in) / (1024*1024) AS mb_down,
       SUM(bytes_out) / (1024*1024) AS mb_up
  FROM samples
 WHERE timestamp > strftime('%s','now','-7 days')
 GROUP BY app
 ORDER BY (mb_down + mb_up) DESC
 LIMIT 20;

Quase sempre conta uma história clara. Navegador no topo, apps de sync no meio, serviços de sistema embaixo.

Heatmap por hora

SELECT strftime('%H', timestamp, 'unixepoch', 'localtime') AS hour,
       SUM(bytes_in + bytes_out) / (1024*1024) AS mb
  FROM samples
 WHERE timestamp > strftime('%s','now','-30 days')
 GROUP BY hour
 ORDER BY hour;

Te mostra quando seu tráfego dá pico. Para a maioria: 9h, 13h e 16h, com cauda longa de sync de nuvem durante a noite.

Detecção de anomalia

SELECT app,
       date(timestamp, 'unixepoch', 'localtime') AS day,
       SUM(bytes_out) / (1024*1024) AS mb_up
  FROM samples
 GROUP BY app, day
HAVING mb_up > 500
 ORDER BY mb_up DESC;

Sinaliza qualquer combinação app-dia com mais de 500 MB de upload. Um punhado é normal (Time Machine para alvo de rede, sync de fotos, transferências grandes). Uma lista inteira de apps não-familiares vale investigar.

Combinando fontes

O fluxo mais forte usa múltiplas fontes ao mesmo tempo.

• ova para contabilidade de bytes — o que foi usado, por qual app, quando
• Unified log para eventos — quando conexões começaram, falharam, fizeram retry
• tcpdump para a linha — quando algo é genuinamente misterioso

Você pode juntar pelo timestamp. Se o ova mostra um upload de 200 MB do cloudd às 3h14, o unified log mostra o que o cloudd estava sincronizando, e (se você tinha uma captura de pacote rodando) tcpdump mostra o espaço de IP de destino confirmando que era iCloud.

Uma nota sobre privacidade

Qualquer coisa que exporta dados de rede pode vazar informação que você não pretendia compartilhar. Hostnames, mesmo paths no unified log, podem revelar quais serviços você usa. Antes de mandar logs para um colega ou colar num chat:

• Tire endereços de IP se identificam sua rede de casa
• Redija hostnames que revelam serviços pessoais
• Remova nomes de processo que revelam apps que prefere não anunciar

Por isso ferramentas só locais importam. O ova não envia seus dados a lugar nenhum — fica no seu disco. O que você exporta é decisão sua.

Encerrando

Para exportar dados de uso de rede do macOS, você tem vários caminhos razoáveis: nettop -L para capturas curtas, o unified log para auditoria de eventos, scripts de amostragem custom para controle total e um monitor com SQLite local como o ova para contabilidade contínua por app. Escolha com base se precisa de eventos ou bytes, e quão longa é a janela que importa.

Para um caminho de baixo esforço que captura continuamente e te deixa consultar depois, instale o ova — cerca de 3 MB, macOS 14+, Apple Silicon e Intel, amostra a aproximadamente 1 Hz. Os dados ficam no diretório ~/Library/Application Support/ova/ em SQLite, então qualquer ferramenta de análise que você já conhece consegue ler.