이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
ss lsof netstat로 네트워크 관찰에서 붙잡아야 할 핵심 판단 기준은 무엇인가?도구는 state, process, 수량을 나누어 본다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
Actuator metric은 Java 내부 이름으로 보이고ss/lsof는 OS 이름으로 보이므로 PID와 timestamp로 두 세계를 붙인다흐름은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 ss lsof netstat로 네트워크 관찰이다. ss, lsof, netstat 계열 명령으로 socket과 process를 연결해 보는 방법을 정리한다.
먼저 붙잡을 기준은 다음 문장이다. 도구는 state, process, 수량을 나누어 본다. ss는 socket state를 빠르게 보고, lsof는 socket을 process와 FD에 붙이며, netstat 계열 counter는 누적 drop과 overflow를 확인한다. 세 도구의 역할을 섞으면 snapshot과 누적값을 잘못 해석한다.
핵심 모델
- 판단 기준: 도구는 state, process, 수량을 나누어 본다.
ss는 현재 socket state, queue, local/remote address를 빠르게 확인하는 도구다.lsof는 socket이 어떤 process와 FD에 연결되어 있는지 확인하는 도구다.netstat와/proc/net/netstat는 listen overflow/drop 같은 누적 counter를 볼 때 유용하다.- Head나 조건 없이 전체 출력하면 장애 중 터미널과 시스템에 불필요한 부하를 줄 수 있다.
- 명령 결과에는 시각, host, PID, port, 필터 조건을 함께 남겨야 재현 가능한 증거가 된다.
문서별 핵심 구분
ss는 socket state와 수량을 빠르게 보여 준다.lsof는 socket과 process, FD를 연결한다.netstat계열 counter는 backlog drop 같은 누적 신호를 볼 때 유용하다.
원리
네트워크 관찰은 “무슨 명령을 쳤다”가 아니라 “그 명령이 어떤 사실을 증명한다”로 정리해야 한다. ss는 현재 kernel socket table의 state와 queue를 보여 주고, lsof는 process가 어떤 FD로 socket을 잡고 있는지 보여 준다.
netstat -s나 /proc/net/netstat는 snapshot이 아니라 누적 counter를 볼 때 의미가 있다. Listen drop이 증가했는지 보려면 한 번의 값보다 장애 전후 차이가 중요하다.
대량 lsof와 전체 netstat 출력은 운영 중 비용이 될 수 있다. 먼저 PID, port, state로 범위를 줄이고 head, wc -l, 시간 간격 샘플을 사용해 필요한 증거만 남긴다.
도구별 역할을 분리하면 “TIME_WAIT이 많다”에서 멈추지 않고, 어떤 process의 어떤 remote endpoint에서 늘었는지, queue drop이 실제로 증가했는지까지 좁힐 수 있다.
Java/Spring 연결
- Actuator metric은 Java 내부 이름으로 보이고
ss/lsof는 OS 이름으로 보이므로 PID와 timestamp로 두 세계를 붙인다. tomcat.connections.current가 늘면ss에서 해당 port의 ESTABLISHED 수와 방향을 비교한다.- HTTP client pool metric이 튀면
lsof와 remote address를 확인해 outbound socket이 어느 시스템으로 몰렸는지 본다. netstatcounter 증가는 Spring 코드 path를 말해 주지 않으므로 thread dump와 application log로 다음 계층을 연결한다.- Runbook에는 명령 출력 예시와 함께 어떤 Actuator metric을 같은 시간에 찍을지 적어 둔다.
- Spring 코드 리뷰에서는
ss lsof netstat로 네트워크 관찰판단 기준이 어떤 thread, pool, timeout, resource 설정으로 드러나는지 확인한다.
코드와 설정 예시
date -Is
ss -tan state time-wait | wc -l
lsof -Pan -p <pid> -iTCP | head
grep -E 'ListenOverflows|ListenDrops' /proc/net/netstat예시는 같은 시간에 state 수, process-FD 매핑, 누적 counter를 같이 남기는 방식이다. date -Is를 먼저 찍어 두면 Actuator, LB 로그, application 로그와 시간축을 맞출 수 있다.
관찰 명령
ss -s
ss -tanp | head
lsof -iTCP -sTCP:ESTABLISHED -P -n | head
netstat -ant 2>/dev/null | headss lsof netstat로 네트워크 관찰 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 PID, 수집 시각을 함께 남기고 출력이 큰 명령은 범위를 제한한다.
지표 해석
| 신호 | 먼저 의심할 것 | 다음 확인 |
|---|---|---|
ss -s state 분포 변화 | 연결 상태 편중 | state별 상세 ss -tan state ... |
lsof 특정 PID FD 증가 | process가 socket을 많이 보유 | FD limit, remote endpoint |
| ListenDrops 증가 | accept/backlog overflow | busy thread, LB timeout |
netstat snapshot만 있음 | 증거 불충분 | 시간 간격을 둔 counter 차이 |
ss lsof netstat로 네트워크 관찰에서는 핵심 신호와 보조 지표를 같은 시간축에서 맞춘다. 먼저 변한 신호와 뒤따라 포화된 신호를 분리해야 원인과 결과를 구분할 수 있다.
장애 상황에서 보는 순서
date -Is와 host/PID를 먼저 남긴다.ss -s로 전체 state 분포를 보고 상세 state를 고른다.ss -ltnp로 listen port와 process를 확인한다.lsof -Pan -p <pid> -iTCP로 socket FD와 remote endpoint를 확인한다./proc/net/netstatcounter를 시간 간격을 두고 두 번 이상 비교한다.
이 순서는 ss lsof netstat로 네트워크 관찰 후보를 빠르게 좁히기 위한 기본 루틴이다. 결론을 내리기 전에는 애플리케이션 증거와 JVM/OS 증거를 최소 한 번 이상 맞춘다.
실전 팁
ss로 state를 고르고lsof로 process와 FD를 붙인 뒤 counter로 누적 여부를 확인한다.- 전체 출력보다
state,sport,dport, PID 필터를 먼저 사용한다. - 누적 counter는 한 번 찍은 값보다 전후 차이가 중요하므로 시간 간격을 둔다.
- 명령 결과를 남길 때는 시각과 필터 조건을 같이 적어 재실행 가능하게 만든다.
- 장애 회고에는 사용한 명령이 어떤 후보를 배제했는지까지 적는다.
주니어 팁
ss는 state,lsof는 process와 FD,netstatcounter는 누적값이라는 역할 차이를 먼저 외운다.- 명령을 실행하기 전에 어떤 port, PID, state를 확인하려는지 한 문장으로 적는다.
- 장애 중에는 전체 출력보다
head,wc -l, 필터 조건으로 좁혀서 본다.
시니어 팁
- Runbook에는 명령 자체보다 “이 출력이면 어떤 후보를 의심/배제한다”는 해석 기준을 적는다.
- 대규모 트래픽 환경에서는 전체 socket table 조회가 비용이 될 수 있으므로 필터 기반 명령을 표준화한다.
- 관찰 결과는 Actuator, LB log, application log와 같은 timestamp 형식으로 수집되게 맞춘다.
Guru급 팁
ss lsof netstat로 네트워크 관찰주제는 단일 snapshot보다 변화 방향이 중요하다. 같은 명령을 간격을 두고 실행해 상태가 증가, 유지, 회복 중 어디인지 본다.- 고급 도구는
ss lsof netstat로 네트워크 관찰가설을 좁힐 때만 사용하고 기본 지표와 모순되는지 먼저 확인한다. ss lsof netstat로 네트워크 관찰조치 후에는 CPU, memory, socket, disk, pool 중 다음 포화 지점이 어디로 이동했는지 확인한다.
위험 신호!
ss결과만 보고 어떤 process의 socket인지 확인하지 않는다.lsof전체 출력으로 운영 환경에 불필요한 부하를 준다./proc/net/netstat누적값을 한 번만 찍고 증가 여부를 판단한다.- PID와 시각을 남기지 않아 thread dump, 로그, metric과 맞출 수 없다.
- 도구 출력이 많다는 이유로 핵심 state와 remote endpoint를 요약하지 않는다.
확인 질문
확인 질문
ss,lsof,netstat의 역할은 어떻게 다른가?
ss는 socket state와 queue,lsof는 process와 FD 매핑,netstat계열은 누적 counter 확인에 강하다.- Listen drop이 실제로 증가했는지 보려면 어떻게 수집해야 하는가?
/proc/net/netstat같은 누적 counter를 시간 간격을 두고 두 번 이상 비교해야 한다.- 네트워크 관찰 결과를 다른 지표와 연결하려면 무엇을 반드시 남겨야 하는가?
- 수집 시각, host, PID, port, state 필터, 실행한 명령을 함께 남겨야 한다.