Note 2017 : le projet a continué à évoluer et est actuellement en version 2.4.3, je l'utilise pour mes modestes besoins couplé à Thruk

Cet article ne représente qu'un démarrage minimum avec ce produit dont les domaines d'applications sont très divers car il permet de tester un logiciel avec divers browser (Chrome, Firefox, Opera, Safari, Internet Explorer) sur divers systèmes d'exploitation (Linux, MacOs, diverses saveurs de Windows). 

Après la migration quasiment sans problèmes de plusieurs machines virtuelles ou physiques j'ai fini par migrer ma machine principale, celle connectée au modem fibre et qui abrite notamment ce site. Cette migration m'a donné quelques soucis notamment avec l'annuaire LDAP géré sur cette machine. 

Détails à venir.

L'installation dans une Machine virtuelle (ici KVM) n'est pas une opération horriblement complexe, voir les articles sur KVM. 

Afin de mesurer l'influence des "huge pages" j'ai réalisé deux séries de tests : 
- en utilisant les "huge pages", 8 Go alloués aux huge pages + paramètre "large-pages" dans la config Mysql. 

Pour ce premier test sur cette "grosse" table j'ai repris un ordre SQL dont je m'étais servi pour repérer les plus gros scanneurs. Je rappelle que cette table contient des données enregistrées par Ntopng sur ma machine "pont" vers Internet. Et les scans de port sont extrêmement courants, chaque machine connectée à Internet en subit plusieurs centaines par jour. 

Ennui "bizarre" lors d'une migration de bullseye à bookworm. 
J'ai déjà migré plusieurs systèmes (physiques ou virtuels) sans rencontrer le moindre ennui lors du passage de "apt dist-upgrade", mais ici j'ai rencontré un problème très bizarre.

Dans un premier temps on est un peu effrayé par la complexité et le nombre des métriques disponibles, et, en plus une métrique en cache plusieurs ... par exemple la métrique "node_disk_io_now" "cache" des valeurs pour chaque disque, ci dessous la liste obtenue pour une machine de mon réseau/

Tableau par réseau limité aux origines avec plus de 15000 hits sur une année.

Analyse sur 4 ans des origines de scans de ports.

Cette analyse a été réalisée à partir des archives de NtopNG sur les années de 2019 à 2022, elle concerne les réseaux et sous réseaux en ne retenant que les échanges ayant pour résultat zéro octets transmis, c'est à dire ayant touché un port fermé. Ceci peut concerner le scan d’un port fermé ou être le résultat d’une connexion rejetée par le pare-feu.