Eu também me perguntei isso e fui motivado pela sua pergunta!
Eu colecionei o quão perto eu poderia chegar de cada uma das filas que você listou com algumas informações relacionadas a cada uma delas. Congratulo-me com comentários / feedback, qualquer melhoria no monitoramento torna as coisas mais fáceis de gerenciar!
net.core.somaxconn
net.ipv4.tcp_max_syn_backlog
net.core.netdev_max_backlog
$ netstat -an | grep -c SYN_RECV
Mostrará a contagem global atual de conexões na fila, você pode dividir isso por porta e colocar isso em instruções exec no snmpd.conf se você quiser pesquisá-lo a partir de um aplicativo de monitoramento.
De:
netstat -s
Eles mostrarão com que frequência você está vendo solicitações da fila:
146533724 packets directly received from backlog
TCPBacklogDrop: 1029
3805 packets collapsed in receive queue due to low socket buffer
fs.file-max
De:
$ cat /proc/sys/fs/file-nr
2720 0 197774
Este arquivo (somente leitura) fornece o número de arquivos atualmente abertos. isto contém três números: o número de alças de arquivos alocados, o número de identificadores de arquivos gratuitos e o número máximo de identificadores de arquivos.
net.ipv4.ip_local_port_range
Se você puder criar uma lista de exclusão de serviços (netstat -an | grep LISTEN), poderá deduzir quantas conexões estão sendo usadas para atividades efêmeras:
netstat -an | egrep -v "MYIP.(PORTS|IN|LISTEN)" | wc -l
Também deve monitorar (do SNMP):
TCP-MIB::tcpCurrEstab.0
Também pode ser interessante coletar estatísticas sobre todos os estados vistos nesta árvore (established / time_wait / fin_wait / etc):
TCP-MIB::tcpConnState.*
net.core.rmem_max
net.core.wmem_max
Você teria que dtrace / strace seu sistema para solicitações de setsockopt. Não acho que as estatísticas dessas solicitações sejam rastreadas de outra forma. Este não é realmente um valor que muda a minha compreensão. O aplicativo que você implantou provavelmente solicitará um valor padrão. Eu acho que você poderia 'perfil' seu aplicativo com strace e configurar esse valor de acordo. (discuta?)
net.ipv4.tcp_rmem
net.ipv4.tcp_wmem
Para acompanhar o quão próximo você está do limite, é necessário observar a média e o máximo dos campos tx_queue e rx_queue (regularmente):
# 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
Para rastrear erros relacionados a isso:
# netstat -s
40 packets pruned from receive queue because of socket buffer overrun
Também deve estar monitorando o pool 'buffer' 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