Allowed Metric Names

Name

Description

SyncookiesSent

An application wasn’t able to accept a connection fast enough, so the kernel couldn’t store an entry in the queue for this connection. Instead of dropping it, it sent a cookie to the client.

SyncookiesRecv

After sending a cookie, it came back to us and passed the check.

SyncookiesFailed

After sending a cookie, it came back to us but looked invalid.

EmbryonicRsts

PruneCalled

RcvPruned

If the kernel is really really desperate and cannot give more memory to this socket even after dropping the ofo queue, it will simply discard the packet it received. This is Really Bad.

OfoPruned

When a socket is using too much memory (rmem), the kernel will first discard any out-of-order packet that has been queued (with SACK).

OutOfWindowIcmps

LockDroppedIcmps

ArpFilter

TW

TWRecycled

TWKilled

PAWSPassive

PAWSActive

PAWSEstab

DelayedACKs

We waited for another packet to send an ACK, but didn’t see any, so a timer ended up sending a delayed ACK.

DelayedACKLocked

We wanted to send a delayed ACK but failed because the socket was locked. So the timer was reset.

DelayedACKLost

We sent a delayed and duplicated ACK because the remote peer retransmitted a packet, thinking that it didn’t get to us.

ListenOverflows

We completed a 3WHS but couldn’t put the socket on the accept queue, so we had to discard the connection.

ListenDrops

We couldn’t accept a connection because one of: we had no route to the destination, we failed to allocate a socket, we failed to allocate a new local port bind bucket. Note: this counter also include all the increments made to ListenOverflows

TCPPrequeued

TCPDirectCopyFromBacklog

TCPDirectCopyFromPrequeue

TCPPrequeueDropped

TCPHPHits

TCPHPHitsToUser

TCPPureAcks

TCPHPAcks

TCPRenoRecovery

A packet was lost and we recovered after a fast retransmit.

TCPSackRecovery

A packet was lost and we recovered by using selective acknowledgements.

TCPSACKReneging

TCPFACKReorder

We detected re-ordering using FACK (Forward ACK — the highest sequence number known to have been received by the peer when using SACK — FACK is used during congestion control).

TCPSACKReorder

We detected re-ordering using SACK.

TCPRenoReorder

We detected re-ordering using fast retransmit.

TCPTSReorder

We detected re-ordering using the timestamp option.

TCPFullUndo

We detected some erroneous retransmits and undid our CWND reduction.

TCPPartialUndo

We detected some erroneous retransmits, a partial ACK arrived while we were fast retransmitting, so we were able to partially undo some of our CWND reduction.

TCPDSACKUndo

We detected some erroneous retransmits, a D-SACK arrived and ACK’ed all the retransmitted data, so we undid our CWND reduction.

TCPLossUndo

We detected some erroneous retransmits, a partial ACK arrived, so we undid our CWND reduction.

TCPLoss

TCPLostRetransmit

TCPRenoFailures

TCPSackFailures

TCPLossFailures

TCPFastRetrans

TCPForwardRetrans

TCPSlowStartRetrans

TCPTimeouts

TCPRenoRecoveryFail

TCPSackRecoveryFail

TCPSchedulerFailed

TCPRcvCollapsed

TCPDSACKOldSent

TCPDSACKOfoSent

TCPDSACKRecv

TCPDSACKOfoRecv

TCPSACKDiscard

We got a completely invalid SACK block and discarded it.

TCPDSACKIgnoredOld

We got a duplicate SACK while retransmitting so we discarded it.

TCPDSACKIgnoredNoUndo

We got a duplicate SACK and discarded it.

TCPAbortOnSyn

We received an unexpected SYN so we sent a RST to the peer.

TCPAbortOnData

We were in FIN_WAIT1 yet we received a data packet with a sequence number that’s beyond the last one for this connection, so we RST’ed.

TCPAbortOnClose

We received data but the user has closed the socket, so we have no wait of handing it to them, so we RST’ed.

TCPAbortOnMemory

This is Really Bad. It happens when there are too many orphaned sockets (not attached a FD) and the kernel has to drop a connection. Sometimes it will send a reset to the peer, sometimes it wont.

TCPAbortOnTimeout

The connection timed out really hard.

TCPAbortOnLinger

We killed a socket that was closed by the application and lingered around for long enough.

TCPAbortFailed

We tried to send a reset, probably during one of teh TCPABort* situations above, but we failed e.g. because we couldn’t allocate enough memory (very bad).

TCPMemoryPressures

Number of times a socket was put in “memory pressure” due to a non fatal memory allocation failure (reduces the send buffer size etc).

TCPBacklogDrop

We received something but had to drop it because the socket’s receive queue was full.

RtoAlgorithm

The algorithm used to determine the timeout value used for retransmitting unacknowledged octets.

RtoMin

The minimum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout. In particular, when the timeout algorithm is “rsre ” (3), an object of this type has the semantics of the LBOUND quantity described in RFC 793.

RtoMax

The maximum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout. In particular, when the timeout algorithm is “rsre” (3), an object of this type has the semantics of the UBOUND quantity described in RFC 793.

MaxConn

The limit on the total number of TCP connections theentity can support. In entities where the maximum number of connections isdynamic, this object should contain the value -1.

ActiveOpens

The number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state.

PassiveOpens

The number of times TCP connections have made a direct transition to the SYN-RCVD state from the LISTEN state.

AttemptFails

The number of times TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state.

EstabResets

The number of times TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state.

CurrEstab

The number of TCP connections for which the current state is either ESTABLISHED or CLOSE- WAIT.

InSegs

The total number of segments received, including those received in error. This count includes segments received on currently established connections.

OutSegs

The total number of segments sent, including those on current connections but excluding those containing only retransmitted octets.

RetransSegs

The total number of segments retransmitted – that is, the number of TCP segments transmitted containing one or more previously transmitted octets.

InErrs

The total number of segments received in error (for example, bad TCP checksums).

OutRsts

The number of TCP segments sent containing the RST flag.