Surveillance de la bande passante pour développeurs et sysadmins sur Mac

Une suite de tests qui devrait prendre 90 secondes en prend 14 minutes, et la CI dépasse son délai. L'exécution locale est lente aussi. Vous lancez un profileur — le CPU est correct. La mémoire est correcte. Puis vous remarquez que la fixture de test fait quelques centaines de requêtes HTTPS sortantes par exécution parce que quelqu'un a ajouté un appel d'API réelle au hook de setup il y a trois mois, et maintenant chaque PR martèle un endpoint sandboxé qui vient d'être limité. La surveillance de bande passante l'aurait attrapé dès le premier jour.

Pour les développeurs et sysadmins sur Mac, l'observabilité réseau est l'une de ces compétences qui se cumulent. Une fois que vous savez quel outil répond à quelle question, vous arrêtez de gaspiller des heures sur des problèmes qui sont en réalité un processus voyou faisant quelque chose d'évident. Ce billet est la pile pratique : quand atteindre tcpdump, quand Wireshark, quand nettop, quand un moniteur par application comme ova, et comment les combiner. Si vous cherchiez un moniteur de bande passante pour développeurs Mac, l'objectif ici est l'arbre de décision pratique, pas la visite marketing.

Les quatre niveaux, brièvement

Les outils de diagnostic couvrent quatre niveaux d'abstraction :

1. Octets de paquets — tcpdump. Chaque octet sur le câble, plus les en-têtes. Le niveau le plus bas. Bon pour capturer puis analyser.
2. Inspection de paquets — Wireshark. Les données de tcpdump, décodées en couches de protocole lisibles. Génial pour comprendre ce que fait une connexion.
3. Par processus en direct — nettop. Natif macOS, montre les connexions actuelles et les débits par processus.
4. Agrégat par application dans le temps — ova. Application de barre de menu, chronologie parcourable, regroupement des processus auxiliaires.

L'astuce pour bien utiliser ceux-ci est de faire correspondre le niveau à la question. Si vous demandez « combien de bande passante notre suite de tests a utilisé la semaine dernière », tcpdump est la mauvaise réponse ; ova ou un outil d'historique par application similaire est la bonne. Si vous demandez « pourquoi cette connexion HTTPS spécifique est lente », nettop ne vous dira pas — il faut Wireshark.

tcpdump : la vue octets-sur-le-câble

tcpdump est sur chaque Mac. C'est le bon outil quand :

• Vous suspectez un problème de protocole spécifique (échecs de poignée de main TLS, retransmissions, fragmentation).
• Vous devez capturer du trafic pour analyse ultérieure.
• Vous travaillez sur une machine de classe serveur où les outils GUI ne sont pas disponibles.

Une capture par défaut utile :

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

• -i en0 — capture sur l'interface Wi-Fi (utilisez en1 pour ethernet sur les Macs avec les deux, ou vérifiez ifconfig).
• -n — ne pas résoudre les noms d'hôte (beaucoup plus rapide).
• -s 0 — capturer le paquet entier, pas juste les en-têtes.
• -w capture.pcap — écrire dans un fichier pcap lisible par Wireshark.

Pour filtrer :

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

Le premier capture seulement le trafic vers un nom d'hôte spécifique en HTTPS. Le second capture seulement l'établissement/fermeture des connexions TCP — utile pour compter les connexions sans se noyer dans les octets de payload.

Wireshark : décodage de protocole

Wireshark lit les fichiers pcap et les décode en une hiérarchie lisible : trame Ethernet, paquet IP, segment TCP, enregistrement TLS, requête HTTP. Gratuit, local, pas de composant cloud. Installez via Homebrew :

brew install --cask wireshark

Le langage de filtre d'affichage est la magie. Quelques filtres à fort impact :

• http.response.code >= 400 — montre les réponses HTTP en échec.
• tcp.analysis.retransmission — montre les retransmissions TCP, souvent un signe de congestion réseau ou de problèmes côté pair.
• tls.handshake.type == 1 — montre les Client Hellos TLS (un par connexion).
• dns and dns.qry.name contains "example.com" — montre les requêtes DNS pour un domaine spécifique.

Wireshark est démesuré pour « combien de bande passante Slack a utilisé aujourd'hui » mais exactement le bon outil pour « pourquoi cette connexion particulière timeoute à 30 secondes alors que d'autres réussissent ». C'est aussi le bon outil quand vous avez une pcap capturée d'une machine cliente et avez besoin d'investiguer après coup.

nettop : la vue par processus en direct

nettop est livré avec macOS. C'est l'équivalent intégré le plus proche d'un moniteur en direct par application :

sudo nettop -P -m route

Drapeaux utiles :

• -P — grouper par processus.
• -m route — montrer l'information de route (quelle interface).
• -x — montrer les compteurs d'octets (pas juste les débits).
• -c <intervalle> — rafraîchissement périodique, par exemple -c 2.
• -J bytes_in,bytes_out,interface — choisir des colonnes spécifiques à afficher.

nettop est en mode texte uniquement, rafraîchit son propre écran, et fonctionne sur SSH. C'est le bon outil quand vous avez besoin d'une réponse rapide « est-ce que quelque chose est bizarre maintenant » sur un Mac distant (un runner CI, la machine d'un collègue où vous êtes en SSH pour un triage).

L'inconvénient : nettop n'a pas d'historique. Au moment où vous quittez, les données sont parties.

ova : historique par application avec regroupement des auxiliaires

ova se loge dans la barre de menu et fournit ce que nettop ne fournit pas : historique persistant, chronologies parcourables, et regroupement des processus auxiliaires. Échantillonnant à environ 1 Hz, les données sont écrites localement et restent jusqu'à ce que vous les supprimiez.

Les deux choses qu'ova fait que les outils intégrés ne font pas :

1. Regroupement des processus auxiliaires. Chrome crée un PID auxiliaire par onglet ; Slack a sa propre architecture d'auxiliaires ; Discord, Telegram, les applications Electron en général font ceci. nettop les montre comme des lignes séparées (« Slack Helper (Plugin) », « Slack Helper (GPU) », etc.), ce qui est techniquement correct mais illisible. ova les regroupe sous « Slack » pour que la ligne corresponde à ce que vous voulez vraiment dire.
2. Historique parcourable. « Que s'est-il passé mardi dernier à 15 h » est une question à laquelle on répond en cliquant et tirant sur la chronologie. La réponse de nettop est « je n'en ai aucune idée, je ne tournais pas ».

Pour le quotidien d'un développeur — « est-ce que la build a martelé le registry », « quel test a tiré 4 Go », « c'est quoi ce pic récurrent au début de chaque heure » — ova répond vite sans cérémonie. nettop est votre repli quand vous avez besoin de « tout de suite, sans installation ».

Exemples concrets

Déboguer un martèlement d'API

Une équipe se plaint que l'API de staging est lente. Vous suspectez qu'un client est dans une boucle de retry. Avec ova dans la barre de menu sur le Mac du dev fautif, vous parcourez vers l'heure de la lenteur et voyez l'outil CLI de l'équipe pointer à 80 Mo/s pendant 15 minutes. C'est la piste. Ouvrez Wireshark sur une capture de 30 secondes et confirmez : chaque requête reçoit un 503 et le client réessaie avec un backoff de 100 ms. Le bug est dans la politique de retry — exponentielle, pas constante — et maintenant vous savez exactement quoi corriger.

Trouver un processus de test fou

CI est correct mais les exécutions de test locales sont lentes. Ouvrez ova, lancez la suite, parcourez le pic. Vous voyez node tirer 200 Mo durant une fenêtre de 30 secondes. tcpdump filtré sur le port suspect montre que la fixture de test récupère des données en direct depuis un vrai CDN à chaque test, au lieu d'utiliser les fixtures enregistrées. Remplacez par une fixture locale, la suite retombe à 90 secondes.

Sortie inattendue d'une bibliothèque tierce

Une revue de conformité demande si la base de code appelle à la maison quelque part. L'analyse statique est partielle ; la seule réponse définitive est « observer le réseau pendant un usage représentatif ». Faites tourner l'application pendant une heure avec ova ; capturez la même heure avec tcpdump pour vérification. Recoupez les destinations vues dans la colonne hostname de nettop. Tout ce qui est inattendu se fait investiguer. Ce genre d'audit est difficile sans historique par application.

Un agent de synchro fou sur la flotte d'un sysadmin

Message Slack interne : « mon Mac semble lent ». Vous SSHez, lancez sudo nettop -P -m route. Un agent de sauvegarde que tout le monde avait oublié faire une réindexation complète, tirant 30 Mo/s soutenus. Tuez le démon, ouvrez un ticket pour corriger le calendrier. Correction de cinq minutes, aurait été d'une heure sans le bon outil.

Voyez ova en action

Un moniteur de bande passante en barre de menu consultable d'un coup d'œil — local, signé, ~3 Mo.

Télécharger pour macOS

Hooks scriptables

Pour l'automatisation :

nettop en sortie quasi-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

Ceci produit un seul échantillon (le drapeau -L 1) que vous pouvez capturer dans un script. Passez dans awk ou jq après quelques manipulations.

Seuils de bande passante

Un script rapide « alerter si un processus dépasse X » peut être construit autour de 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}'

(Grossier, mais fonctionnel.) Pour une version de qualité production, regardez iftop pour le trafic par hôte ou bmon pour le niveau interface.

tcpdump comme watchdog

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

Fait tourner un fichier de capture d'une heure, en garde 24. Utile pour « je ne sais pas quand ça arrive mais je veux l'attraper la prochaine fois ».

Exports ova

ova écrit son historique localement. Si vous devez alimenter cela dans un tableau de bord ou un rapport, le chemin d'export est le bon point de départ — les données sont à vous, et il n'y a pas de couche de synchro éditeur au milieu.

Choisir le bon moniteur de bande passante dont les flux développeurs Mac ont réellement besoin

Une matrice courte :

Le motif est : nettop et ova pour « quoi » et « quand », tcpdump et Wireshark pour « pourquoi » au niveau protocole. La plupart des questions côté développeur sont répondues sans jamais ouvrir Wireshark — c'est un outil de basse fréquence réservé aux problèmes de protocole vraiment déroutants.

Motifs spécifiques aux sysadmins

Si vous maintenez une flotte de Macs (petite équipe, studio de design, boutique vidéo), les motifs sont différents :

• Découverte d'abord. Lancez sudo nettop -P -m route sur chaque machine via SSH ou gestion distante pour voir ce qui tourne. Cherchez des processus inconnus — signes révélateurs d'extensions de navigateur indésirables, d'adware empaqueté, ou de logiciels beta oubliés.
• Historique sur les utilisateurs intensifs. Pour les gros utilisateurs réseau de l'équipe (monteurs vidéo téléversant les rushes, devs poussant de gros artefacts), un outil d'historique par application attrape les problèmes récurrents sans devoir être là au moment où ils arrivent.
• Référence documentée. Capturez la sortie nettop pour un Mac « bon » et un Mac « plaintif ». Le diff est généralement évident.

Que faire ensuite

Si vous partez de zéro sur une pile de monitoring de bande passante pour développeur Mac, installez ova pour la vue d'historique toujours active, apprenez les trois incantations nettop ci-dessus, et mettez Wireshark en favori pour quand vous en aurez besoin. C'est l'ensemble de travail. La plupart des problèmes dans la journée d'un développeur ou sysadmin se résolvent au niveau par application ou par processus ; les outils au niveau paquet sont là pour les cas plus difficiles qui apparaissent mensuellement, pas quotidiennement.

La suite de tests qui martèle une API, l'agent de synchro fou, le runner CI qui télécharge secrètement 8 Go par build — tout cela est visible au moment où vous avez le bon outil ouvert. Le coût est de quelques minutes de configuration. Le bénéfice est la prochaine fois que quelque chose est « lent sans raison » et que la réponse est dans la barre de menu au lieu de deux heures de chasse au profileur.