Moi aussi je me suis demandé cela et j'ai été motivé par votre question!
J'ai rassemblé à quel point je pouvais me rapprocher de chacune des files d'attente que vous avez énumérées avec des informations relatives à chacune d'elles. Je souhaite la bienvenue aux commentaires / réactions, toute amélioration apportée à la surveillance simplifie la gestion!
net.core.somaxconn
net.ipv4.tcp_max_syn_backlog
net.core.netdev_max_backlog
$ netstat -an | grep -c SYN_RECV
Affiche le nombre total actuel de connexions dans la file d'attente. Vous pouvez le décomposer par port et l'insérer dans les instructions exec dans le fichier snmpd.conf si vous souhaitez l'interroger à partir d'une application de surveillance.
De:
netstat -s
Celles-ci vous montreront à quelle fréquence vous voyez les demandes de la file d'attente:
146533724 packets directly received from backlog
TCPBacklogDrop: 1029
3805 packets collapsed in receive queue due to low socket buffer
fs.file-max
De:
http://linux.die.net/man/5/proc
$ cat /proc/sys/fs/file-nr
2720 0 197774
Ce fichier (en lecture seule) donne le nombre de fichiers actuellement ouverts. Il contient trois chiffres: le nombre de descripteurs de fichiers alloués, le nombre de descripteurs de fichiers libres et le nombre maximal de descripteurs de fichiers.
net.ipv4.ip_local_port_range
Si vous pouvez créer une liste d'exclusion de services (netstat -an | grep LISTEN), vous pouvez en déduire le nombre de connexions utilisées pour une activité éphémère:
netstat -an | egrep -v "MYIP.(PORTS|IN|LISTEN)" | wc -l
Devrait également surveiller (depuis SNMP):
TCP-MIB::tcpCurrEstab.0
Il peut également être intéressant de collecter des statistiques sur tous les états vus dans cet arbre (établi / time_wait / fin_wait / etc):
TCP-MIB::tcpConnState.*
net.core.rmem_max
net.core.wmem_max
Vous devriez dtrace / strace votre système pour les requêtes setsockopt. Je ne pense pas que les statistiques pour ces demandes soient suivies autrement. Ce n'est pas vraiment une valeur qui change de ma compréhension. L'application que vous avez déployée demandera probablement un montant standard. Je pense que vous pouvez «profiler» votre application avec strace et configurer cette valeur en conséquence. (discuter?)
net.ipv4.tcp_rmem
net.ipv4.tcp_wmem
Pour savoir si vous êtes proche de la limite, vous devez consulter les valeurs moyenne et maximale des champs tx_queue et rx_queue à partir de (régulièrement):
# cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 00000000:0FB1 00000000:0000 0A 00000000:00000000 00:00000000 00000000 500 0 262030037 1 ffff810759630d80 3000 0 0 2 -1
1: 00000000:A133 00000000:0000 0A 00000000:00000000 00:00000000 00000000 500 0 262029925 1 ffff81076d1958c0 3000 0 0 2 -1
Pour suivre les erreurs liées à ceci:
# netstat -s
40 packets pruned from receive queue because of socket buffer overrun
Devrait également surveiller le pool 'tampon' global (via SNMP):
HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Memory Buffers
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 74172456
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 51629704