소개
Northline Library는 독자가 책을 찾고 대출 가능 여부와 예약 미리보기를 확인하도록 돕습니다. 홈페이지가 정상으로 보여도 검색은 실패할 수 있습니다. 고객의 실제 결과를 감시하고 장애가 지속될 때만 팀에 알리는 것이 목표입니다.
기본 터미널 사용만 알면 됩니다. 도서관, Prometheus(수집 및 규칙), Blackbox Exporter(실제 HTTP 프로브), Alertmanager(알림 전달), 로컬 수신함이 준비되어 있습니다. 짧은 YAML 설정 파일 두 개를 편집하며 앱 개발, 설치, 이메일 계정이나 외부 메시지는 필요 없습니다. 가상 도서와 읽기 전용 예약 미리보기를 사용하는 단일 실습 인스턴스입니다.
독자 작업은 Library, 명령은 Workstation, 실제 관측과 webhook 수신은 Monitoring에서 수행합니다. 사이트와 화면 레이블은 영어로 유지됩니다. 각 단원은 독립적으로 시작합니다.
독자의 검색 감시하기
이 단계에서는 고객 프로브를 선택합니다. Library에서 시작하여 정상 업무를 먼저 사용한 다음 독자가 실제로 필요한 결과를 확인하는 프로브를 선택합니다.
독자 경로 체험하기
Search the catalog의 moon을 그대로 두고 Find a book을 선택합니다. 결과에 Moon Atlas, Available, 서가 위치가 표시되어야 합니다. Moon Atlas, Check reservation 순서로 열면 읽기 전용 미리보기에 Ready to collect: Moon Atlas가 표시됩니다. 실제 예약은 생성되지 않습니다. Back to book, NORTHLINE LIBRARY를 선택합니다. Visit에서 운영 시간을 읽고 브랜드 링크로 돌아옵니다.
프로브 이해하기
Workstation으로 전환합니다. 이미 /home/labex/project/library-watch에 있습니다. 경로는 파일이나 디렉터리를 가리키며 이 절대 경로는 시스템 루트에서 시작합니다. pwd는 현재 위치, ls는 이름 목록, cat은 파일 내용을 출력합니다.
pwd
ls
cat prometheus.yml
prometheus.yml, alerts.yml, watch.sh가 있습니다. 설정은 프로그램의 동작을 기술합니다. YAML은 공백 들여쓰기, key: value 쌍, 목록 항목 앞의 하이픈을 사용합니다. 아래 공백을 유지하세요. 편집기는 필요 없으며 작은 설정 전체를 한 블록으로 교체합니다.
HTTP는 브라우저의 요청과 응답 프로토콜입니다. URL은 주소, 서비스를 구분하는 포트, 경로로 구성됩니다. Workstation에서 127.0.0.1은 이 실습 인스턴스를 뜻합니다. 8081 포트는 도서관을 제공하고 /search?q=moon은 쿼리 매개변수 q가 moon인 검색입니다. 터미널 명령에서 URL의 따옴표를 유지하여 셸이 하나의 인수로 처리하도록 합니다.
준비된 library job은 현재 홈페이지만 검사합니다. job은 이름이 붙은 수집 대상 그룹입니다. 9115 포트의 익스포터는 실제 요청을 보내 probe_success를 반환합니다. 성공은 1, 실패는 0입니다. search 모듈은 HTTP 200뿐 아니라 Moon Atlas와 Available 내용도 요구합니다. Prometheus는 2초마다 이 결과를 수집합니다. 별도의 up 지표는 익스포터에서 수집할 수 있었는지만 나타내며 독자의 성공을 증명하지 않습니다.
고객 경로 선택하기
cat > prometheus.yml은 파일을 교체합니다. <<'YAML'은 내용을 그대로 보존하는 here-document를 시작합니다. 마지막에 단독 행으로 놓는 YAML까지 전체 블록을 붙여 넣습니다. global은 시간 간격, rule_files는 규칙 위치, alerting은 준비된 전달 서비스 연결을 정의합니다. 이 지원 설정은 유지하고 모듈과 대상을 검색 경로로 바꿉니다. journey: search 레이블이 업무 범위를 표시합니다.
cat > prometheus.yml <<'YAML'
global:
scrape_interval: 2s
evaluation_interval: 2s
rule_files:
- /home/labex/project/library-watch/alerts.yml
alerting:
alertmanagers:
- static_configs:
- targets: ['127.0.0.1:9093']
scrape_configs:
- job_name: library
metrics_path: /probe
params:
module: [search]
target: ['http://127.0.0.1:8081/search?q=moon']
static_configs:
- targets: ['127.0.0.1:9115']
labels:
journey: search
YAML
bash watch.sh reload는 제공된 도우미를 실행합니다. 구문을 검사한 뒤 Prometheus에 다시 로드를 요청합니다. 도서관을 바꾸거나 관측을 꾸며 내지 않습니다.
bash watch.sh reload
Configuration accepted가 나와야 합니다. 약 4초 뒤 Monitoring으로 전환하면 Business probes에 search: healthy가 표시되어야 합니다. YAML 오류가 나면 Workstation에서 파일을 전체 블록으로 교체하고 다시 로드합니다. 샘플이 unavailable이면 기다린 후 재시도하세요. 사용할 수 없다는 것은 정상이라는 뜻이 아닙니다. 대상을 Monitoring 자체로 지정하지 마세요.
접근 가능성과 업무 성공 비교하기
Workstation으로 전환합니다. fault search seconds 6은 검색만 실제 6초 동안 실패시킨 후 자동으로 복구합니다. 알림 상태를 설정하지 않습니다. curl은 HTTP 요청을 보내며 -sS는 진행 표시를 숨기고 연결 오류를 보여 줍니다. 실행합니다.
bash watch.sh fault search seconds 6
curl -sS 'http://127.0.0.1:8081/search?q=moon'
본문에 **Search is taking a break.**가 나옵니다. 서버는 일부러 HTTP 200을 반환하므로 상태 코드만 검사하면 업무 장애를 놓칩니다. 즉시 Monitoring으로 전환하면 한 수집 간격 안에 검색이 failed, 복구 후 healthy가 되어야 합니다. 짧은 순간을 놓치면 같은 6초 연습을 반복합니다. 아직 알림은 설정되지 않았습니다. 정상 상태가 된 뒤 단계 검사를 실행하세요.
장애가 지속될 때만 알림 보내기
이 단계에서는 앞서 본 짧은 장애를 무시할 만큼 기다리는 고객 알림을 설정합니다. Workstation에서 시작합니다.
조건 읽기
Prometheus는 2초마다 규칙을 평가합니다. probe_success{job="library",journey="search"} == 0은 library job의 실패한 검색 샘플을 선택합니다. 중괄호 안은 레이블 필터이며 == 0은 성공 대신 실패를 선택합니다. up만 선택하면 독자가 아니라 수집을 감시합니다. 레이블을 빼면 무관한 서비스가 포함될 수 있습니다.
for: 20s는 조건이 20초 동안 계속 성립해야 한다는 뜻입니다. pending은 조건이 존재하지만 대기 중, firing은 필요한 시간 충족, inactive는 조건이 없음을 뜻합니다. 20초는 실습용의 짧은 값이며 보편적인 운영 권장값이 아닙니다. 프로브 데이터 누락은 Monitoring에 unavailable로 표시됩니다. 이는 정상 증거도 실제 업무 실패 샘플도 아닙니다.
alert는 규칙 이름입니다. severity는 라우팅 레이블이고 annotations.summary는 고객 영향을 설명합니다. 전체 규칙을 씁니다.
cat > alerts.yml <<'YAML'
groups:
- name: readers
rules:
- alert: CustomerJourneyFailed
expr: probe_success{job="library",journey="search"} == 0
for: 20s
labels:
severity: page
annotations:
summary: Readers cannot complete search
YAML
bash watch.sh reload
Configuration accepted가 나와야 합니다. 검증이 실패하면 공백이나 문장 부호를 수정하고 다시 로드합니다. 새 설정이 수락될 때까지 마지막 유효 설정이 계속 사용됩니다.
Monitoring으로 전환합니다. 검색이 정상일 때 **CustomerJourneyFailed: inactive (20 seconds)**가 보여야 합니다. 로컬 수신함은 아직 비어 있어야 합니다.
짧은 장애가 조용히 끝남을 증명하기
Workstation으로 전환하여 같은 짧은 업무 장애를 반복합니다.
bash watch.sh fault search seconds 6
즉시 Monitoring으로 전환합니다. 검색이 실패하고 규칙이 잠시 pending일 수 있습니다. 자동 복구 후 프로브와 규칙은 healthy/inactive로 돌아가며 수신함은 비어 있습니다. 전체 과정에 약 12초를 기다립니다. 이전에 긴 장애를 실행했다면 기존 알림은 남습니다. 증거를 삭제하지 말고 새 이벤트를 비교하세요.
firing 규칙과 전달된 알림은 서로 다른 사실입니다. Alertmanager는 firing 알림을 받아 그룹화하고 새 그룹에 대해 1초 기다린 다음 로컬 webhook 수신함으로 보냅니다. 수집, 평가, 전달마다 작은 지연이 생깁니다. 알림이 즉시 오지 않는다는 이유로 for를 없애거나 모든 임계값을 낮추지 마세요.
장애와 복구 알림 받기
이 단계에서는 지속 장애를 발생시키고 실제 알림 전달을 관찰합니다. Workstation에서 시작합니다.
지속 장애 관찰하기
다음 장애는 실제 60초 동안 지속되어 각 상태를 볼 시간이 있습니다. 검색만 실패하고 홈페이지는 계속 작동합니다.
bash watch.sh fault search seconds 60
Library로 전환하고 브랜드 링크로 홈페이지에 돌아갑니다. 정상처럼 보입니다. moon을 다시 검색하면 오류 메시지가 독자가 목록을 사용할 수 없음을 증명합니다. Monitoring으로 전환합니다. 검색은 failed이고 규칙은 먼저 pending이 됩니다. 첫 실패 샘플에서 약 20초 후 firing이 되며 수신함에 FIRING · CustomerJourneyFailed · search가 추가되어야 합니다. 장애 시작부터 수집, 평가, 전달에 최대 35초를 허용합니다. 진행 애니메이션이 아니라 실제 관측입니다.
35초 후에도 수신함이 비어 있으면 Workstation으로 전환하여 읽기 전용 상태 명령을 사용합니다.
bash watch.sh status
checks와 alerts를 봅니다. unavailable은 수집 누락, pending은 지속 시간 미충족, firing인데 수신함 이벤트가 없으면 전달 문제를 살펴봅니다. 설정을 다시 읽고 수정했다면 다시 로드합니다. 60초 장애가 만료되면 반복할 수 있습니다. 가짜 메시지를 만들거나 모니터링을 중지하지 마세요.
복구하고 해제 확인하기
Workstation으로 전환합니다. 0초는 자동 만료 전이라도 검색을 즉시 복구합니다.
bash watch.sh fault search seconds 0
Library로 전환하여 홈페이지에서 moon 검색을 반복합니다. Moon Atlas와 Available이 돌아와야 합니다. 책과 예약 미리보기를 다시 열고 Visit도 계속 사용할 수 있어야 합니다.
Monitoring으로 전환합니다. 약 10초 안에 검색이 healthy, 알림이 inactive가 되고 수신함에 RESOLVED · CustomerJourneyFailed · search가 추가됩니다. 원래 firing 알림은 남습니다. resolved는 이번 장애가 끝났다는 뜻이지 도서관이 다시는 실패하지 않는다는 뜻이 아닙니다.
이 단계는 실제 전달된 firing/resolved 쌍과 현재 사용 가능한 도서관을 검사합니다. 또한 로드된 규칙을 정상, 짧은 장애, 지속 장애, 복구, 데이터 누락, 무관한 실패의 격리 샘플로 시험합니다. 채점은 장애를 주입하거나 서비스를 복구하거나 설정을 바꾸지 않습니다. 도서관을 정상으로 두고 앞으로의 장애를 감지할 규칙을 유지하세요.
요약
실제 고객 검색과 내용 검사 프로브를 선택하고 레이블로 알림 범위를 제한했으며 짧은 장애를 무시하고 실제 장애 및 복구 webhook을 받았습니다. 익스포터 가용성과 업무 가용성, 데이터 누락과 성공을 구분했습니다. 독립 도전 과제는 예약 확인에 같은 방법을 적용하고 무관한 장애 서비스를 제외합니다.
