계층별 상태 점검

한 칸짜리 정상 표시를 벗어납니다

학생이 학교 웹에 접속하지 못할 때 라우터 ping만 성공한다고 정상 처리하면 담당자가 같은 질문을 반복하게 됩니다. 점검 스크립트는 실패가 어디서 나타났는지 좁힐 단서를 남겨야 합니다. 이번 레슨에서는 이름 조회, 지정 IP의 TCP 연결, HTTP 상태, ICMP 표본, 인터페이스 오류를 별도 필드로 수집합니다. 모든 항목이 같은 요청의 내부 구간은 아닙니다. 각각 독립 요청으로 같은 시기에 찍은 관측 묶음이며 전체 점검 시간도 따로 정의합니다.

관측 위치를 먼저 고정합니다

probe.sh의 기본 출발지는 bcnet-s1입니다. 이 네임스페이스 안에서 dig와 curl을 실행해야 학생의 정책과 경로를 검사합니다. 라우터 자체에서 curl을 실행하면 forward 대신 output 경로를 사용할 수 있어 학생의 성공을 대신하지 않습니다. source 칸에 네임스페이스를 남겨 자료가 다른 역할과 섞이지 않게 합니다. 관리자 셸의 환경 프록시는 curl의 --noproxy 옵션으로 제외합니다. 같은 대상의 직접 접속 여부를 보는 과제이므로 프록시 경유 여부가 비교 조건을 바꾸지 않도록 합니다.

DNS 답과 명령 종료를 함께 읽습니다

dig는 지정 서버 10.20.10.1에 school.test의 A 값을 요청합니다. 프로그램 종료 코드가 0이어도 예상 주소가 없거나 다른 주소가 있으면 dns는 fail입니다. 조회는 +time=1과 +tries=1로 대기를 제한합니다. DNS 실패로 HTTP 검사를 생략하면 이름 문제와 IP 연결 문제를 구분할 자료가 사라집니다. 따라서 나머지 요청은 설계표의 웹 IP 10.20.30.11을 직접 사용합니다. 이름 기반 사용자 요청의 전체 성공 여부는 이 점검 묶음과 별도의 관측이라는 한계도 적습니다.

TCP 연결 검사는 짧게 끝냅니다

Python socket.create_connection으로 웹 포트 8080에 연결하고 즉시 닫습니다. timeout은 1초로 설정합니다. 소켓 연결이 되면 tcp는 ok이며 예외가 나면 subprocess 종료 상태에 따라 fail입니다. 이 검사는 HTTP 본문이나 로그인 성공을 확인하지 않습니다. ConnectionRefusedError는 상대가 거절했다는 단서이고 TimeoutError는 정해진 시간 내 연결이 끝나지 않았다는 뜻입니다. 둘 중 하나를 보자마자 정책 차단이라고 확정하지 않고 m08의 정상 대조 자료와 비교합니다.

HTTP 응답을 별도로 확인합니다

curl은 --connect-timeout 1과 --max-time 2를 사용하여 연결 대기와 총 대기를 제한합니다. 응답 본문은 버리고 -w의 http_code를 수집합니다. curl 종료가 성공이어도 HTTP 503이면 웹 연결의 업무 기준에 실패입니다. 이 과제는 정상 상태를 200으로 고정하며 실제 서비스에서는 기대 상태와 본문을 업무별로 정의합니다. 전송 실패는 000으로 저장합니다. 000은 서버가 보낸 HTTP 상태가 아니라 스크립트가 관측하지 못한 상태를 표현하는 약속입니다.

ICMP와 인터페이스를 나란히 봅니다

ping은 두 표본을 보내고 전송·수신 수를 수집합니다. 이 표본은 RTT 분포를 충분히 설명하지 않으며 즉시 확인용 단서입니다. ICMP 제한이 있는 망에서는 웹 결과와 다른 실패가 날 수 있습니다. 인터페이스는 ip -j -s link show dev eth0의 JSON에서 rx와 tx errors를 읽습니다. stats64와 stats 표현을 둘 다 처리합니다. errors는 누적 카운터이므로 숫자가 크다는 사실보다 연속 관측 사이 증가를 확인합니다. 초기화나 장치 재생성 뒤 감소하면 음수 오류율을 만들지 않습니다.

시간의 이름을 정확히 붙입니다

monitor.py는 호출 시작부터 DNS·TCP·HTTP·ping·링크 조회를 마칠 때까지의 경과를 latency_ms에 적습니다. 단조 시계로 경과 시간을 재고 UTC 시각은 별도로 저장합니다. 이 값은 웹 응답 시간이나 ping RTT가 아닙니다. 앞 단계의 timeout이 길어지면 전체 점검 소요시간도 늘어납니다. CSV 필드 이름을 유지해야 이전 계약과 이어지지만 README에 경계를 명시합니다. HTTP만의 시간을 원하면 별도 필드를 추가해 시작과 끝을 새로 정의해야 합니다.

실패해도 나머지 항목을 보존합니다

셸에서 set -e를 사용한 상태로 dig 실패 직후 전체 점검을 멈추면 TCP와 HTTP 단서가 남지 않을 수 있습니다. 여기서는 probe.sh가 Python 수집기를 실행하고 Python이 각 명령의 종료 코드·stderr를 받아 상태를 분리합니다. 서비스 실패는 한 행으로 남고 도구 부재나 네임스페이스 부재 같은 환경 오류는 점검 실행 실패로 드러나야 합니다. JSON 파싱 오류를 정상 0으로 채우지 않습니다. 점검기가 고장 났다는 사실도 별도의 운영 정보입니다.

연속 세 번의 실패를 정의합니다

경보 함수 alert는 tcp가 ok가 아니거나 http가 200이 아닌 행을 웹 실패로 봅니다. 실패가 이어지면 streak를 증가시키고 성공이면 0으로 초기화합니다. 세 번째 실패에서 사건 하나를 내며 네 번째·다섯 번째에는 같은 사건을 반복 발행하지 않습니다. 성공 이후 다시 세 번 실패하면 새로운 사건입니다. DNS만 실패하고 IP 웹은 성공한 경우 이 웹 경보는 울리지 않지만 DNS 필드는 fail로 남습니다. 사용자 이름 경로에 대한 별도 DNS 경보를 추가할 수 있는 이유입니다.

총 세 번과 연속 세 번은 다릅니다

실패·성공·실패·실패의 네 행에서는 누적 실패가 세 번이어도 연속 최대 길이는 두 번입니다. starter의 결함은 성공에서 streak를 초기화하지 않는 것입니다. test_reset의 AssertionError가 나오면 실패 처리보다 성공 분기를 읽습니다. HTTP 503을 TCP 성공이라는 이유로 정상 처리하면 test_http가 실패합니다. 다섯 번 이어진 실패에서 다섯 사건을 내면 test_once가 실패합니다. 테스트 이름은 고칠 코드 줄 번호가 아니라 잘못된 운영 판단을 알려줍니다.

수집 간격도 탐지 시간에 포함됩니다

연속 세 번 기준은 고정된 탐지 시간을 보장하지 않습니다. 호출 사이 간격과 각 요청의 timeout이 더해지고, 실제 장애가 첫 측정 직전인지 직후인지에 따라 지연이 달라집니다. 이 실습은 상시 데몬 대신 한 번 실행하여 한 행을 추가하는 형태입니다. 스케줄러를 붙일 때 겹치는 실행과 수집 누락을 검토해야 합니다. 오래된 성공 자료로 현재 상태를 대신하지 않도록 마지막 수집 시각도 확인합니다. 경보는 담당자의 대체 경로 판단을 돕는 신호이지 자동 변경 승인은 아닙니다.

제출 자료를 읽는 기준

monitor.csv 헤더와 행의 열 수를 맞추고 UTC 시각·출발지·각 계층 상태를 읽습니다. probe-errors.json은 가장 최근 호출의 stderr이므로 장기 사건 기록을 남길 때는 실행별 이름으로 복사합니다. 순수 로직 여섯 테스트를 통과해도 실제 DNS와 HTTP 요청을 수행했다고 주장할 수 없습니다. Linux VM에서 live-check.sh로 구성·수집·정리를 실행해 얻은 행만 실제 관측 자료입니다. 더 읽기는 ip 명령의 세부 사용법을 보충하며 이 레슨 제출물은 상태 간 모순을 해석한 점검 기록입니다.

도구 옵션 참고: curl 공식 문서에서 종료 상태와 제한 시간 정의를 확인합니다.