서비스 감시와 장애 알림 기본

작은 팀이 실제로 감시해야 하는 것은 여섯 가지입니다. 외부에서 보이는 HTTP 상태와 응답 시간, 인증서 만료, 도메인 만료, DNS 응답, 디스크와 메모리, 로그 오류율입니다. 이 여섯 개만 알림으로 연결해 두면 장애를 사용자보다 먼저 알게 되고, 나머지 지표는 원인을 찾을 때 들여다보는 자료로 두면 충분합니다.

감시 체계에서 가장 자주 실패하는 부분은 도구 선택이 아니라 알림의 도착입니다. 아무도 읽지 않는 채널로 가는 알림은 없는 것과 같고, 너무 많이 오는 알림은 읽지 않는 알림이 됩니다. 그래서 이 문서는 항목과 임계값, 그리고 받는 사람을 정하는 방법을 같이 다룹니다. 특정 제품에 의존하지 않는 방식으로 적었습니다.

최소 구성

외부 상태 점검 1개 + 서버 자원 알림 1개

감시의 기준점

IP가 아니라 사용자가 실제로 쓰는 도메인 이름

알림 설계 원칙

즉시 조치가 필요한 것만 즉시 알림, 나머지는 일일 요약

무엇을 감시하는가

항목마다 감시 위치와 신호의 의미가 다릅니다. 아래 표가 전체 그림입니다.

우선순위를 하나만 정하라면 첫 번째입니다. 사용자가 겪는 상태를 가장 직접적으로 대신 보여 주기 때문입니다.

외형 감시부터 세웁니다

외형 감시는 서버 바깥에서 도메인 이름으로 접속해 응답을 확인하는 점검입니다. 서버 내부 감시와 역할이 다릅니다. 서버가 멈추면 내부 감시도 같이 멈추지만, 외형 감시는 그 사실 자체를 알려 줍니다.

• 점검 대상은 IP가 아니라 도메인 이름으로 둡니다 (DNS 문제까지 같이 잡힙니다)
• 단순 연결 확인이 아니라 상태 코드와 본문 일부까지 확인합니다
• 로그인이 필요 없는 전용 점검 경로를 만들어 두고 그 경로를 봅니다
• 점검 주기는 1분에서 5분 사이, 연속 실패 2회 이상일 때 알림을 보냅니다
• HTTPS 로 점검하고 인증서 검증도 함께 수행합니다
• 가능하면 두 곳 이상에서 점검해 점검 지점 쪽 문제와 구분합니다

점검 경로는 애플리케이션이 실제로 동작하는지까지 확인하게 만드는 편이 좋습니다. 정적 파일 하나를 보면 웹서버는 살아 있고 애플리케이션은 죽은 상태를 놓칩니다. 데이터베이스 연결까지 확인하는 간단한 응답을 돌려주는 경로를 두고, 본문에 고정 문자열을 포함시켜 그 문자열이 있는지 확인하게 합니다.

curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/healthz

응답 시간 임계값은 처음부터 정하지 말고 일주일 정도 기록해 평소 분포를 본 뒤 잡습니다. 평소보다 느린 것과 장애는 다른 신호이므로, 느려짐은 경고로, 실패는 즉시 알림으로 구분하세요.

만료되는 것들

만료는 예고가 있는 장애입니다. 그런데도 사고가 반복되는 이유는 알림이 아무도 읽지 않는 곳으로 가기 때문입니다.

인증서는 남은 일수를 직접 읽어 확인할 수 있습니다.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

TLS 인증서를 자동 갱신으로 쓰고 있어도 감시는 필요합니다. 갱신 작업이 조용히 실패하는 경우가 있고, 갱신에 쓰이는 검증 경로가 막혀 있으면 만료일까지 아무 신호가 없습니다. 갱신 타이머의 실행 결과와 만료 남은 일수를 둘 다 보세요. 인증서 종류와 갱신 방식은 SSL 인증서에 정리되어 있습니다.

도메인 만료는 서버 감시 도구가 알려 주지 않습니다. 보유 도메인 목록과 만료일을 대장으로 관리하고, 담당자 캘린더에 만료 60일, 30일, 7일 전 일정을 걸어 두는 방식이 확실합니다. 자동 연장을 켜 두었더라도 결제수단이 만료되면 실패하므로 결제수단 유효기간도 같은 대장에 적어 둡니다. 전체 예방 절차는 도메인 만료 사고 예방에 있습니다.

DNS 응답도 감시 대상입니다. 레코드가 사라지거나 값이 바뀌면 서버는 정상인데 서비스는 닿지 않습니다. 기대하는 값을 기록해 두고 주기적으로 비교합니다.

dig +short example.com A
dig +short @1.1.1.1 example.com A

A 레코드와 MX 값이 기준과 다르면 즉시 알리게 둡니다. 값이 바뀌지 않았는데 응답이 느리거나 실패한다면 DNS 쪽 문제로 범위가 좁혀집니다. 반영이 늦는 경우는 TTL과 캐시 문제일 수 있어서 DNS 변경이 반영되지 않을 때를 같이 보세요.

서버 자원과 로그 오류율

서버 내부는 추세를 보는 용도와 임계값 알림 용도를 나눠 생각합니다. 알림으로 연결할 것은 많지 않습니다.

• 디스크 사용률 80% 경고, 90% 즉시 알림 (루트 파티션과 로그 파티션을 따로 봅니다)
• 메모리 여유 부족이 일정 시간 이상 지속되거나 스왑 사용이 급증할 때
• 프로세스가 죽었다가 반복 재시작될 때 (재시작 횟수 자체를 지표로 둡니다)
• CPU 는 순간 최고치보다 지속 시간을 봅니다 (5분 이상 높게 유지될 때)
• 로드 평균과 디스크 입출력 대기는 추세 자료로 두고 알림은 걸지 않습니다

디스크는 가장 흔한 원인이면서 가장 예방하기 쉬운 항목입니다. 로그 로테이션과 저널 상한을 걸어 두면 대부분 해결되고, 설정 방법은 VPS 첫 세팅에 있습니다.

df -h /
free -m
journalctl --disk-usage

서버에 직접 붙지 않는 구성이라면 기준점이 달라집니다. Plesk 기반 웹호스팅을 쓰는 경우에는 콘솔의 호스팅 상세에서 디스크와 대역폭 사용량을 주기적으로 확인하고, 로그와 백업 상태는 제어판에서 봅니다. 설정 위치는 웹호스팅 첫 세팅에 정리했습니다.

로그 오류율은 절대 숫자보다 변화를 봅니다. 평소 분당 몇 건이 나오던 애플리케이션에서 갑자기 수십 배로 늘어나는 순간이 신호입니다. 구현은 단순해도 됩니다. 오류 수준 로그를 분 단위로 세고 기준을 넘으면 알리는 방식이면 충분합니다. 중요한 것은 오류 메시지가 한 곳에 모여 검색 가능한 상태로 있는 것입니다. 배포할 때마다 오류율을 확인하는 습관을 두면 문제 있는 배포를 빠르게 되돌릴 수 있습니다.

알림 채널, 담당자, 임계값

감시 항목을 정하는 것보다 이 단계에서 더 많은 체계가 무너집니다.

1. 채널을 두 단계로 나눕니다

   즉시 대응이 필요한 알림과 알아만 두면 되는 알림을 다른 경로로 보냅니다. 즉시 알림은 사람이 반드시 보는 경로(전화나 호출)로, 참고 알림은 업무 메신저 채널이나 일일 요약 메일로 보냅니다. 같은 채널에 섞이면 즉시 알림이 묻힙니다.

2. 각 항목의 담당자를 이름으로 적습니다

   "인프라팀"이 아니라 사람 이름으로 1차 담당과 2차 담당을 정합니다. 담당자가 한 명이면 그 사람의 휴가가 곧 공백이므로 최소 두 명을 둡니다.

3. 야간과 주말 규칙을 미리 정합니다

   밤에도 깨워야 하는 항목이 무엇인지 목록으로 정합니다. 목록에 없는 항목은 아침에 확인합니다. 이 구분이 없으면 모든 알림이 밤에 울리고, 결국 알림을 끄게 됩니다.

4. 지속 시간 조건을 넣습니다

   한 번 임계값을 넘었다고 알리지 않고 일정 시간 이상 지속될 때 알립니다. 순간적인 변동으로 울리는 알림이 알림 피로의 주된 원인입니다.

5. 같은 원인의 알림을 묶습니다

   서버가 죽으면 외형 감시, 자원 감시, 오류율이 동시에 울립니다. 하나의 사건으로 묶어 보내고 복구되면 해제 알림까지 보내도록 둡니다.

6. 주기적으로 알림 목록을 줄입니다

   한 달 동안 아무도 조치하지 않은 알림은 끄거나 임계값을 올립니다. 반대로 사용자 문의로 먼저 알게 된 장애가 있었다면 그 상황을 잡아낼 항목을 추가합니다.

점검 주기는 이렇게 잡으면 무리가 없습니다. 외형 감시는 1분에서 5분, 서버 자원은 1분 수집에 5분 이상 지속 조건, 인증서와 도메인 만료는 하루 1회, 감시 항목과 담당자 명단 검토는 분기 1회입니다.

장애가 났을 때 확인 순서

알림을 받은 뒤 원인을 찾는 순서를 미리 정해 두면 혼자 대응해도 흔들리지 않습니다. 범위를 바깥에서 안으로 좁혀 갑니다.

1. 밖에서 정말 안 되는지 확인합니다

   회사 네트워크가 아닌 다른 회선이나 휴대 전화 데이터로 접속해 봅니다. 나만 안 되는 상황과 전체 장애를 먼저 구분합니다.

   curl -sI https://example.com | head -n 1
   

2. 이름이 IP로 풀리는지 확인합니다

   DNS 응답이 없거나 값이 달라졌다면 서버를 들여다볼 필요가 없습니다.

   dig +short example.com A
   

3. 서버까지 닿는지 확인합니다

   IP로 직접 접속해 보고, 해당 포트가 열려 있는지 확인합니다. 여기서 막히면 회선, 방화벽, 서버 상태 쪽입니다. 레토 클라우드 인스턴스라면 콘솔에서 인스턴스 상태를 먼저 보고, 상태가 정상인데도 닿지 않으면 콘솔의 VNC로 붙어 화면을 직접 확인합니다. 서버가 살아 있는지와 네트워크가 막혔는지를 여기서 가릅니다. 자체 장비를 데이터센터에 두었다면 원격 관리 포트(BMC)로 전원과 콘솔 상태를 먼저 보고, 그래도 닿지 않으면 리모트핸즈로 서버 전원 관리를 요청합니다.

   curl -sI --resolve example.com:443:203.0.113.50 https://example.com | head -n 1
   

4. 서버 안에서 자원과 프로세스를 봅니다

   디스크가 가득 찼는지, 메모리 부족으로 프로세스가 종료되었는지, 서비스가 실행 중인지 확인합니다.

   df -h / && free -m && systemctl status myapp --no-pager
   

5. 애플리케이션 로그에서 시작 시각을 찾습니다

   오류가 처음 나타난 시각을 찾고, 그 시각 전후에 있었던 배포나 설정 변경과 맞춰 봅니다. 대부분의 원인은 이 대조에서 드러납니다.

6. 복구 후 기록을 남깁니다

   증상, 발견 경로, 원인, 조치, 재발 방지 항목을 짧게 적습니다. 사용자 문의로 먼저 알게 되었다면 그 상황을 잡아낼 감시 항목을 바로 추가합니다.

증상별로 더 자세한 갈래는 웹사이트가 열리지 않을 때에 정리되어 있습니다. 최근에 서버를 옮겼다면 전환 과정에서 남은 항목이 원인인 경우가 많으니 서버를 옮길 때 도메인과 DNS 체크리스트의 정리 목록을 다시 확인해 보세요. 코로케이션을 쓴다면 리모트핸즈 요청 경로를 입고 단계에서 정해 두는 편이 좋고, 준비 항목은 코로케이션 입고 준비와 절차에 있습니다.