Sur cette page

La bande passante est toujours a zero

Un Sentinel Agent dont toutes les valeurs de bande passante sont a 0, dont les seuils de trafic ne se declenchent jamais et dont les protocoles sont tous Unidentified n’observe presque jamais un hote inactif : il lui manque son runtime de capture de paquets.

Inactif, ou non mesure ?

Une bande passante a 0 a la meme apparence dans les deux cas. L’agent remonte donc un statut de capture a chaque collecte, et l’interface web l’affiche. Verifiez ces indices avant de conclure a un reseau calme :

Ou Ce que vous voyez
Barre d’outils du graphe de decouverte Un badge ambre No packet capture. Survolez-le : l’infobulle reprend la raison remontee par l’agent lui-meme.
Menu deroulant du filtre Proto Une ligne en tete precisant que les protocoles sont deduits du seul port et du nom de processus.
Infobulle d’un lien de la carte « not measured — no packet capture » a la place d’une valeur de bande passante, et aucune mini-courbe.
Rapport processus Une icone d’avertissement sur les pastilles de seuil Traffic In et Traffic Out et sur leurs deux panneaux de graphique.

Si aucun de ces indices n’apparait et que les valeurs sont malgre tout a 0, la capture fonctionne et les liens sont reellement inactifs : un 0.000 kbits/s authentique est une mesure et s’affiche comme telle.

Sur une carte fusionnee (niveau 2), le badge indique « No packet capture on at least one agent ». La carte fusionne plusieurs agents et ne garantit un trafic fiable que si tous les agents contributeurs ont pu capturer : un seul hote sans pilote marque donc toute la vue. Ouvrez la carte propre a chaque hote pour identifier lequel.

Ce qui fonctionne malgre tout

Seule la bande passante est perdue. L’agent reste actif, le service continue de tourner, et rien d’autre ne se degrade :

  • Conserve — l’inventaire complet des connexions : IP et port local et distant, PID, nom du processus, sens, interface. La carte de topologie est complete.
  • Conserve — les metriques CPU, memoire, disque, systeme de fichiers, processus, ainsi que netBytesRate / netTxDrops par interface, qui proviennent des compteurs de l’OS et non des paquets.
  • Conserve — les libelles de protocole, mais deduits du seul numero de port et du nom de processus. C’est pourquoi la categorie Unidentified grossit : les ports ephemeres ne portent aucun indice de port bien connu et il n’y a aucun contenu a inspecter.
  • Perdu — toutes les valeurs en kbits/s. Le trafic entrant / sortant par processus reste a 0, l’usage des liens de la carte reste a 0, et les seuils de trafic ne peuvent jamais se declencher.

Lire la raison

L’infobulle du badge porte la raison remontee par l’agent. Chacune appelle un correctif different.

« couldn’t load wpcap.dll » / echec de l’enumeration des peripheriques

Aucun runtime pcap n’est installe.

  • Windows — installez le runtime Npcap. Le SDK n’est pas necessaire.
  • Linux — installez libpcap0.8 (Debian/Ubuntu) ou libpcap (RHEL).

Sur RHEL, le binaire livre cherche libpcap.so.0.8 alors que la distribution fournit libpcap.so.1 :


ln -s /usr/lib64/libpcap.so.1 /usr/lib64/libpcap.so.0.8

Echec de OpenLive / permission refusee

Le runtime est present mais l’agent n’a pas le droit de l’ouvrir.

  • Linux — accordez la capacite au binaire de l’agent lui-meme, puis redemarrez le service :

setcap cap_net_raw+ep /opt/mugnsoft/discovery_agent
  • Windows — les installeurs Npcap recents activent par defaut Restrict driver access to Administrators only. Executez le service en LocalSystem / sous un compte administrateur, ou reinstallez Npcap avec cette option decochee.
La capacite se pose sur le binaire de l’agent, et non sur un processus auxiliaire : la capture de paquets s’execute au sein de l’agent. Le remplacement du binaire lors d’une mise a jour efface la capacite : reappliquez setcap apres chaque montee de version.

Aucune interface de capture exploitable

Le runtime est charge et les permissions sont correctes, mais toutes les interfaces ont ete ecartees — typiquement un conteneur ou un hote dont les seules interfaces sont des peripheriques docker/veth, qui sont ignores.

Si le trafic recherche est de l’IPC local a l’hote, activez plutot la capture du bouclage :


{
  "discoCaptureLoopbackEnabled": "true"
}

Attendez-vous a une hausse des valeurs de bande passante une fois active, puisque le trafic local commence a etre comptabilise. Ce drapeau ne fonctionne aujourd’hui que sous Linux.

Verifier depuis les journaux

L’agent journalise l’etat de la capture uniquement lors d’un changement — un avertissement quand la capture devient indisponible, une ligne d’information quand elle revient — de sorte qu’un hote durablement sans pilote journalise une fois au lieu de le faire a chaque cycle. Recherchez capture dans le journal de l’agent :


grep -i "capture" /opt/mugnsoft/discovery_agent/log/*.log

Comme la journalisation n’a lieu qu’au changement, l’absence de lignes recentes ne prouve pas que la capture fonctionne. Le badge de l’interface web reflete la derniere collecte : c’est la verification fiable.

Tous les protocoles sont « Unidentified »

C’est la consequence attendue de ce qui precede, et non une panne distincte. Sans contenu capture, une connexion n’est etiquetee que si son port est bien connu. Les connexions cote client sur des ports ephemeres — navigateurs, IPC, la majorite du trafic sortant — n’ont aucun indice de ce type et se retrouvent dans Unidentified.

Deux parametres influent :

  • discoProtocolDetectionEnabled (defaut "true") — inspection approfondie du contenu des paquets. Si vous le passez deliberement a "false", attendez-vous a la meme croissance d'Unidentified, meme sur un hote qui capture normalement.
  • discoCaptureLoopbackEnabled (defaut "false") — l’IPC local a l’hote reste invisible tant qu’il n’est pas active.

Les deux sont relus au debut de chaque cycle de collecte : une modification s’applique au cycle suivant, sans redemarrer l’agent.

Voir aussi

Traductions

Le composant ne demarre pas