포트 모니터링

HTTP 이외의 감시: 나머지 스택 모니터링

비즈니스를 유지하는 대부분의 서비스는 웹 서버가 아닙니다. 데이터베이스는 5432(포스트그레스), 3306(MySQL), 27017(몽고DB), 6379(레디스) 포트에서 대기하고 있습니다. 메일은 25, 465, 587, 993, 995 포트로 전송됩니다. SSH는 22번 포트에 있습니다. 게임 서버는 퍼블리셔가 정한 포트에서 동작합니다. 내부 마이크로서비스는 방화벽 뒤에서 플랫폼 팀이 설정한 어떤 포트이든 사용합니다. 이들 중 어떤 것도 HTTP로 통신하지 않습니다. 웹사이트 가동 모니터링 도구에서는 볼 수 없습니다. 그리고 이들 어느 하나라도 대기 중지되면 뭔가 눈에 띄는 것이 같이 멈춥니다.

포트 모니터링은 이 빈틈을 메워줍니다. 모니터에 호스트와 포트를 입력하면 매 체크마다 서비스가 대기하고 있는지 확인하기 위해 TCP 연결을 엽니다. 연결이 실패하면 – 데몬이 죽거나, 방화벽이 변경됐거나, 호스트가 다운됐거나, 우리와 서비스 사이의 네트워크에 문제가 있을 때 – 즉시 알림을 받게 됩니다.

모니터링 가능한 대상

• 데이터베이스: 5432(포스트그레스), 3306(MySQL/MariaDB), 1433(SQL 서버), 27017(몽고DB), 6379(레디스), 9042(카산드라), 11211(멤캐시드)
• 메일서버: 25(SMTP), 465(SMTPS), 587(제출), 110(POP3), 143(IMAP), 993(IMAPS), 995(POP3S)
• 원격접속: 22(SSH), 3389(RDP), 5900(VNC)
• 파일 전송: 21(FTP), 990(FTPS), 445(SMB), 2049(NFS)
• 비표준 또는 내부용: GraphQL 게이트웨이, gRPC, 큐(RabbitMQ 5672, Kafka 9092), 검색(Elasticsearch 9200, Solr 8983), 게임 서버, IoT 장치 등

체크 동작 방식

모니터는 5초 타임아웃으로 host:port에 원시 TCP 연결을 엽니다. SYN/ACK가 돌아오면 포트에 도달 가능하며 서비스가 대기 중임을 확인하고 체크가 정상입니다. 연결이 거절되거나 타임아웃, 경로 없음이면 체크 실패로 기록되고 커널의 에러 메시지("connection refused", "operation timed out", "no route to host")가 결과로 남아, 문제 파악이 쉬워집니다.

모니터는 어플리케이션 프로토콜로 통신을 시도하지 않습니다 — SQL 쿼리나 SMTP HELO를 보내지 않습니다. 이렇게 하면 체크가 빠르고 추가적인 부작용이 없습니다. 1분마다 100개의 서비스를 점검하는 상황에서 이것이 중요합니다. 어플리케이션 레벨의 확인이 필요하다면 포트 모니터링을 heartbeat 또는 자체 API 모니터와 결합하세요.

HTTP 및 핑과의 결합

각각의 공개 서비스에 대해 세 가지 모니터를 사용하면 진단 경로가 명확해집니다. 핑은 호스트가 네트워크에 살아 있음을 확인합니다. 포트 모니터링은 서비스가 대기 중임을 의미합니다. HTTP/API 모니터링은 서비스가 정상적으로 응답함을 보여줍니다. 문제가 발생하면 어느 계층이 멈췄는지 바로 알 수 있습니다. HTTP만 멈추면 앱이 크래시된 것입니다. 포트도 멈추면 데몬이 죽은 것입니다. 핑까지 멈추면 장비가 꺼졌거나 네트워크 전체가 사라진 것입니다.

설정

도구를 열고, "모니터 추가"를 클릭한 후 "TCP 포트" 유형을 선택하세요. 호스트 주소(프로토콜 제외)를 붙여넣고 포트 번호(1-65535)를 입력한 뒤 인터벌을 지정하세요. 저장하면 다음 체크 주기부터 모니터가 1분마다 TCP 연결을 시도하며, 라운드트립을 기록하고 포트가 닫힌 즉시 — 이메일, 텔레그램, 슬랙, 디스코드 또는 SMS로 실시간 알림이 전송됩니다. 동일한 임계치 확정 및 야간 정숙 규칙이 적용됩니다.

자주 묻는 질문

• 어떤 포트를 모니터링할 수 있나요?

  모든 TCP 포트(1~65535)가 가능합니다. 일반적인 예시: SMTP(25/587/465), POP3(110/995), IMAP(143/993), 데이터베이스 리스너(PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH(22), FTP(21), 맞춤형 애플리케이션 포트 등.

• 모니터가 서비스의 정상 여부까지 점검하나요, 아니면 접근성만 확인하나요?

  접근성만 점검합니다 — 모니터는 TCP 연결이 열리는지만 확인하며, 데몬이 요청을 수락하는지 봅니다. 프로토콜 수준의 핸드셰이크는 없습니다. 프로토콜 인식 체크(예: SMTP 배너 확인, 데이터베이스 쿼리 응답)가 필요하다면 HTTP 체크(HTTP 서비스 대상) 또는 자체 호스팅 heartbeat 에이전트를 사용하세요.

• 포트 체크의 타임아웃은 얼마인가요?

  기본값은 10초입니다. 모니터별로 조절할 수 있습니다. 만약 TCP 연결이 타임아웃 내 확립되지 않으면 체크는 "connection timeout"과 함께 실패 처리됩니다. 장거리 연결(예: 유럽에서 아시아 서버 점검)은 더 긴 타임아웃이 필요할 수 있습니다.

• UDP 포트도 모니터링할 수 있나요?

  현재는 불가능합니다. UDP는 연결이 없기 때문에 "connection accepted"에 해당하는 상태를 점검할 수 없습니다. UDP 기반 서비스는 대개 프로토콜별 프루브가 필요합니다(예: 53번 포트 DNS 쿼리, 161번 SNMP get 등). 이 경우 heartbeat 모니터링을 사용하세요.

• 포트 모니터링이 TLS/SSL 경고 체크에도 해당되나요?

  아니요 — 포트 체크는 순수 TCP 접근성만 확인합니다. 포트에서 TLS 인증서 유효성 검사를 하고 싶다면, URL에 포트를 포함한 HTTPS 체크(예: https://api.example.com:8443/)를 사용하세요. 이 방식은 접근성과 함께 인증서 확인도 합니다.