Monitoramento de largura de banda para devs e sysadmins no Mac

Uma suíte de testes que deveria levar 90 segundos está levando 14 minutos, e o CI está dando timeout. A rodada local também está lenta. Você anexa um profiler — CPU está bem. Memória está bem. Aí você nota que o fixture do teste está fazendo algumas centenas de requisições HTTPS de saída por execução porque alguém adicionou uma chamada de API real no setup hook três meses atrás, e agora todo PR está martelando um endpoint sandbox que acabou de receber rate-limit. Monitoramento de banda teria flagrado isso no dia um.

Para desenvolvedores e sysadmins no Mac, observabilidade de rede é uma daquelas habilidades que se acumulam. Quando você sabe qual ferramenta responde qual pergunta, para de desperdiçar horas em problemas que são na verdade um processo doido fazendo algo óbvio. Este post é a pilha de trabalho: quando ir ao tcpdump, quando ao Wireshark, quando ao nettop, quando a um monitor por app como o ova e como combinar tudo. Se você esteve procurando "monitor de banda para devs no Mac", o objetivo aqui é a árvore de decisão prática, não o tour de marketing.

Os quatro níveis, brevemente

As ferramentas de diagnóstico cobrem quatro níveis de abstração:

1. Bytes do pacote — tcpdump. Cada byte na linha, mais cabeçalhos. O nível mais baixo. Bom para capturar e depois analisar.
2. Inspeção de pacote — Wireshark. Os dados do tcpdump decodificados em camadas legíveis de protocolo. Ótimo para entender o que uma conexão está fazendo.
3. Por processo ao vivo — nettop. Nativo do macOS, mostra conexões e taxas atuais por processo.
4. Agregado por app no tempo — ova. App de barra de menu, linha do tempo navegável, agrupamento de processos auxiliares.

O truque para usar bem é casar o nível com a pergunta. Se você pergunta "quanta banda nossa suíte de testes usou semana passada", tcpdump é a resposta errada; ova ou ferramenta similar de histórico por app é a certa. Se pergunta "por que essa conexão HTTPS específica está lenta", o nettop não vai te dizer — você precisa do Wireshark.

tcpdump: a visão de bytes-na-linha

tcpdump está em todo Mac. É a ferramenta certa quando:

• Você suspeita de um problema específico de protocolo (falhas de handshake TLS, retransmissões, fragmentação).
• Precisa capturar tráfego para análise depois.
• Está trabalhando numa máquina classe servidor onde ferramentas GUI não estão disponíveis.

Uma captura padrão útil:

sudo tcpdump -i en0 -n -s 0 -w capture.pcap

• -i en0 — captura na interface Wi-Fi (use en1 para ethernet em Macs com ambas, ou cheque com ifconfig).
• -n — não resolve hostnames (muito mais rápido).
• -s 0 — captura o pacote completo, não só cabeçalhos.
• -w capture.pcap — escreve num arquivo pcap legível pelo Wireshark.

Para filtrar:

sudo tcpdump -i en0 -n 'host api.example.com and port 443'
sudo tcpdump -i en0 -n 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0'

A primeira captura só tráfego para um hostname específico em HTTPS. A segunda captura só setup/teardown de conexão TCP — útil para contar conexões sem se afogar em bytes de payload.

Wireshark: decodificação de protocolo

O Wireshark lê arquivos pcap e os decodifica numa hierarquia legível: frame Ethernet, pacote IP, segmento TCP, registro TLS, requisição HTTP. Gratuito, local, sem componente de nuvem. Instale via Homebrew:

brew install --cask wireshark

A linguagem de filtro de exibição é a mágica. Alguns filtros de alto impacto:

• http.response.code >= 400 — mostra respostas HTTP que falharam.
• tcp.analysis.retransmission — mostra retransmissões TCP, frequentemente sinal de congestionamento ou problemas no peer.
• tls.handshake.type == 1 — mostra TLS Client Hellos (um por conexão).
• dns and dns.qry.name contains "example.com" — mostra queries DNS para um domínio específico.

Wireshark é overkill para "quanta banda o Slack usou hoje", mas é exatamente certo para "por que essa conexão específica dá timeout em 30 segundos enquanto outras dão certo". Também é a ferramenta certa quando você tem um pcap capturado de uma máquina cliente e precisa investigar depois.

nettop: a visão por processo ao vivo

nettop vem com o macOS. É o equivalente built-in mais próximo a um monitor por app ao vivo:

sudo nettop -P -m route

Flags úteis:

• -P — agrupa por processo.
• -m route — mostra informação de rota (qual interface).
• -x — mostra contagens de bytes (não só taxas).
• -c <interval> — refresh periódico, por exemplo -c 2.
• -J bytes_in,bytes_out,interface — escolhe colunas específicas para mostrar.

nettop é só texto, atualiza a própria tela e funciona via SSH. É a ferramenta certa quando você precisa de uma resposta rápida "tem alguma coisa estranha agora" num Mac remoto (um runner de CI, a máquina de um colega em que você está SSH'd para triagem).

A desvantagem: nettop não tem histórico. No segundo em que você sai, os dados se vão.

ova: histórico por app com agrupamento de auxiliares

ova fica na barra de menu e fornece o que o nettop não fornece: histórico persistente, linhas do tempo navegáveis e agrupamento de processos auxiliares. Amostrando a aproximadamente 1 Hz, os dados são gravados localmente e ficam até você apagar.

As duas coisas que o ova faz e que as ferramentas built-in não:

1. Agrupamento de processos auxiliares. Chrome cria um PID auxiliar por aba; Slack tem sua própria arquitetura de helpers; Discord, Telegram, apps Electron em geral fazem isso. nettop mostra como linhas separadas ("Slack Helper (Plugin)", "Slack Helper (GPU)", etc.), o que é tecnicamente correto mas ilegível. ova agrupa sob "Slack" para que a linha seja o que você de fato quer dizer.
2. Histórico navegável. "O que aconteceu na terça às 15h" se responde clicando e arrastando na linha do tempo. A resposta do nettop é "não faço ideia, eu não estava rodando."

Para o dia a dia de um dev — "o build martelou o registry?", "qual teste puxou 4 GB?", "que pico recorrente é esse no início de cada hora?" — ova responde rápido sem cerimônia. nettop é seu fallback quando você precisa de "agora, sem instalação."

Exemplos concretos

Debug de martelamento de API

Um time reclama que a API de staging está lenta. Você suspeita que um cliente está em loop de retry. Com o ova na barra de menu do dev infrator, você navega até a hora da lentidão e vê a CLI do time em pico de 80 MB/s por 15 minutos. Essa é a pista. Abra o Wireshark numa captura de 30 segundos e confirme: cada requisição está recebendo 503 e o cliente está fazendo retry com backoff de 100 ms. O bug está na política de retry — exponencial, não constante — e agora você sabe exatamente o que consertar.

Achando um processo de teste descontrolado

CI está bem, mas execuções locais estão lentas. Abra o ova, rode a suíte, navegue até o pico. Você vê node puxando 200 MB numa janela de 30 segundos. tcpdump filtrado para a porta suspeita mostra que o fixture do teste está buscando dados ao vivo de uma CDN real a cada teste, em vez de usar os fixtures gravados. Substitua por fixture local e a suíte cai para 90 segundos.

Tráfego de saída surpreendente de uma biblioteca de fornecedor

Uma revisão de compliance pergunta se a base de código liga para casa em algum lugar. Análise estática é parcial; a única resposta definitiva é "observar a rede durante uso representativo." Rode o app por uma hora com o ova; capture a mesma hora com tcpdump para verificação. Cruze os destinos vistos na coluna de hostname do nettop. Qualquer coisa inesperada vira investigação. Esse tipo de auditoria é difícil sem histórico por app.

Um agente de sync descontrolado na frota de um sysadmin

Mensagem interna no Slack: "meu Mac está lento." Você dá SSH, roda sudo nettop -P -m route. Um agente de backup que todos esqueceram que estava instalado está fazendo um re-index completo, puxando 30 MB/s sustentados. Mate o daemon, abra um chamado para corrigir o agendamento. Correção de cinco minutos, teria sido uma hora sem a ferramenta certa.

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

Hooks scriptáveis

Para automação:

nettop em saída tipo JSON

nettop -P -L 1 -k state,interface_name,rx_dupe,rx_ooo,re-tx,rtt_avg,rcvsize,tx_win,tc_class,tc_mgt,cc_algo,P,C,R,W -J bytes_in,bytes_out

Isso produz uma única amostra (a flag -L 1) que você pode capturar num script. Pipe para awk ou jq depois de alguma modelagem.

Limites de banda

Um script rápido "alerte se algum processo passar de X" pode ser construído em torno do nettop:

sudo nettop -P -L 1 -J bytes_in,bytes_out -k state,interface_name,P,C,R,W \
  | awk 'NR>1 && ($2+$3) > 1000000 {print}'

(Bruto, mas funcional.) Para uma versão production-quality, olhe iftop para tráfego-por-host ou bmon para nível de interface.

tcpdump como watchdog

sudo tcpdump -i en0 -n 'host suspicious.example.com' -w "/tmp/capture-$(date +%Y%m%d-%H%M).pcap" -G 3600 -W 24

Rotaciona um arquivo de captura de 1 hora, mantém 24 deles. Útil para "não sei quando isso acontece mas quero pegar da próxima vez."

Exportações do ova

ova grava seu histórico localmente. Se você precisa alimentar isso num dashboard ou relatório, o caminho de exportação é o ponto de partida certo — os dados são seus e não há camada de sync de fornecedor no meio.

Escolhendo o monitor de banda certo para fluxos de dev no Mac

Uma matriz curta:

O padrão é: nettop e ova para "o que" e "quando", tcpdump e Wireshark para "por que" no nível de protocolo. A maior parte das perguntas voltadas a dev se resolve sem nunca abrir o Wireshark — essa é uma ferramenta de menor frequência reservada para problemas de protocolo genuinamente confusos.

Padrões específicos de sysadmin

Se você mantém uma frota de Macs (time pequeno, estúdio de design, casa de vídeo), os padrões são diferentes:

• Descoberta primeiro. Rode sudo nettop -P -m route em cada máquina via SSH ou gerenciamento remoto para ver o que está rodando. Procure processos desconhecidos — sinais reveladores de extensões de navegador indesejadas, adware empacotado ou software beta esquecido.
• Histórico nos usuários pesados. Para os usuários pesados de rede do time (editores de vídeo subindo dailies, devs empurrando artefatos grandes), uma ferramenta de histórico por app captura problemas recorrentes sem precisar estar lá no momento em que acontecem.
• Linha de base documentada. Capture saída do nettop num Mac "bom" e num Mac "que reclama". O diff costuma ser óbvio.

O que fazer a seguir

Se você está partindo do zero numa pilha de monitor de banda para dev no Mac, instale o ova para a visão de histórico sempre ligada, aprenda as três incantações de nettop acima e marque o Wireshark para quando precisar. Esse é o conjunto de trabalho. A maior parte dos problemas no dia de um dev ou sysadmin se resolve no nível por app ou por processo; as ferramentas de pacote estão lá para os casos mais difíceis que aparecem mensalmente, não diariamente.

A suíte de testes martelando uma API, o agente de sync descontrolado, o runner de CI que secretamente baixa 8 GB por build — todos visíveis no momento em que você tem a ferramenta certa aberta. O custo é alguns minutos de setup. O retorno é da próxima vez que algo está "lento sem motivo" e a resposta está na barra de menu em vez de duas horas de caça com profiler.