단순히 “사이트가 열리냐?”만 확인하는 모니터링은 부족하다.
로그인 페이지 자체가 열리더라도 실제 로그인 과정에서 문제가 생기면 사용자는 서비스를 이용할 수 없기 때문이다.

Zabbix의 Web 시나리오(Web Scenario) 기능을 이용하면, 로그인 요청을 실제로 날려보고 응답을 검증하여 로그인 성공 여부를 모니터링할 수 있다.

단순히 HTTP에 대한 응답 모니터링은 설정도 어렵지 않을 뿐더러 조금만 검색을 하면 가이드를 해주는 사이트를 쉽게 찾아 볼 수 있다.
그러나, 로그인을 포함한 기능 모니터링을 위한 가이드를 해 주는 곳은 찾기 힘들다

아래에서는 실제 환경에 적용했던 과정을 정리해본다.

---

1. 로그인 URL 및 Payload 확인하기

먼저, 로그인 요청이 어떤 URL로 전송되는지와 어떤 값들이 넘어가는지를 확인해야 한다.
이건 **크롬 개발자 도구(F12)**로 쉽게 알 수 있다.

1. 로그인 페이지 접속 → F12 → Network 탭 열기
2. “Fetch/XHR” 필터를 켜고 로그인 버튼 클릭
3. 제일 처음 발생한 sign-in 요청 클릭
   • URL과 Method(POST) 확인
   • Request Headers에서 Content-Type 확인
   • Payload에서 실제 전송되는 필드 확인

예시 (임의 값):

• URL: https://example.com/member-user/auth/sign-in
• Method: POST
• Content-Type: multipart/form-data; boundary=----WebKitFormBoundary6x5o981HvBL2rDUC
• Payload: clientname: example username: test_user@example.com password: MySecurePassword123!

👉 여기서 중요한 점:

• clientname → 어떤 서비스인지 구분하는 값. 사이트마다 다르므로 반드시 확인 필요.
• username → 실제 로그인 계정 (운영자 계정이 아닌, 모니터링 전용 계정을 쓰는 게 안전하다).
• password → 해당 계정의 비밀번호.

---

2. curl로 직접 테스트하기

Zabbix에 적용하기 전에 먼저 서버에서 curl로 직접 요청을 보내 정상 응답이 오는지 확인한다.

curl -X POST https://example.com/member-user/auth/sign-in \
  -H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary6x5o981HvBL2rDUC" \
  -F "clientname=example" \
  -F "username=test_user@example.com" \
  -F "password=MySecurePassword123!"

• 결과로 200 OK가 떨어지면 정상.
• 만약 다른 코드(401/403/500 등)가 떨어지면 URL이나 payload, 헤더가 잘못된 것.

---

3. Zabbix Web 시나리오 설정하기

(1) 시나리오 기본 정보

• 이름: 로그인 체크
• URL: https://example.com/member-user/auth/sign-in
• 갱신 간격, 시도 횟수는 환경에 맞게 설정
• 에이전트: Zabbix server

(2) Step 추가

• 이름: 로그인 시도
• URL: 위에서 확인한 로그인 처리 URL
• 포스트 형식: 로우 데이터(raw data) 선택
• 로우 포스트 내용: (payload를 boundary 형식으로 감싼다)

------WebKitFormBoundaryTest123
Content-Disposition: form-data; name="clientname"

example
------WebKitFormBoundaryTest123
Content-Disposition: form-data; name="username"

test_user@example.com
------WebKitFormBoundaryTest123
Content-Disposition: form-data; name="password"

MySecurePassword123!
------WebKitFormBoundaryTest123--

👉 여기서 주의할 점:

• **Boundary 값(WebKitFormBoundaryTest123)**은 개발자 도구에서 보인 그대로 쓰거나, 임의로 지정해도 된다.
• 단, 반드시 헤더의 boundary 값과 Raw Data의 boundary 값이 동일해야 한다.
• example, test_user@example.com, MySecurePassword123!은 예시 값이며, 실제 환경에 맞는 값으로 변경해야 한다.

– 헤더 추가

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryTest123
user-agent: curl/7.68.0

• Content-Type: Raw Data와 boundary 값이 동일해야 한다.
• user-agent: 임의 값 가능 (curl, Mozilla/... 등).

– 타임아웃 & 요구 상태 코드값 설정

• 타임아웃: 15s (환경에 맞게 조정)
• 요구 상태 코드: 200

---

4. 로그인 방식에 따른 주의사항

이 방식이 항상 통하는 건 아니다.
사이트의 로그인 체계에 따라 Web 시나리오 설정을 추가로 해줘야 할 수도 있다.

• 단순 폼 로그인 → ✅ 지금 설명한 방법 그대로 가능
• 세션 쿠키 기반 → Step을 2개 이상 만들어서 쿠키를 따라가야 한다
• CSRF 토큰 필요 → 로그인 페이지에서 토큰 값을 추출해 같이 보내야 한다
• JS 암호화/캡차(reCAPTCHA) → ❌ Web 시나리오만으로 불가능 (API나 별도 처리 필요)

---

5. 정리

1. **개발자 도구(F12)**로 URL/헤더/payload를 먼저 확인한다.
2. curl로 테스트해서 200 OK가 떨어지는지 검증한다.
3. Zabbix Web 시나리오에 Raw Data와 헤더를 그대로 넣는다.
4. Boundary 값은 임의 지정 가능하지만 반드시 헤더와 일치해야 한다.
5. 로그인 방식이 단순하지 않다면 Web 시나리오만으로는 안 될 수도 있다.

👉 이렇게 하면 단순 HTTP Alive 체크를 넘어,
“실제로 로그인 성공이 되는지”를 Zabbix에서 모니터링할 수 있다.

Zabbix Web 시나리오 로그인 체크 트리거 설정하기

앞에서 Web 시나리오로 로그인 모니터링을 설정했다면, 이제는 **트리거(Trigger)**를 걸어 알람을 받을 차례다.
Web 시나리오의 핵심 지표는 web.test.fail 아이템이다.

• 0 → 정상 (로그인 성공)
• 1 → 장애 (로그인 실패)

따라서 이 값을 기준으로 트리거를 만들면 된다.

---

1. 트리거 생성 화면 설정

(1) 이름

portal.example.com 포털웹 로그인에 문제가 있습니다.

• 알람 메시지에 그대로 쓰이는 부분.
• 서비스명 + 장애 설명 형식으로 작성하면 한눈에 알아보기 쉽다.

---

(2) 장애의 조건식

last(/Host/web.test.fail[portal web 모니터링])=1

• 의미: 최근 값이 1이면 장애 발생.
• 즉, 로그인 체크가 실패한 경우 트리거 발동.

---

(3) 복구 조건식

last(/Host/web.test.fail[portal web 모니터링])=0

• 의미: 최근 값이 0이면 정상으로 복구.
• 즉, 로그인 체크가 다시 성공하면 트리거 해제.

---

(4) 심각도

• 로그인 실패는 사용자 서비스 전체 장애로 이어질 수 있으므로 심각한 장애(Critical) 또는 최소 **중증 장애(High)**로 설정 권장.

---

2. 기타 옵션

• 정상 이벤트 생성: 복구 조건식 기반으로 정상 이벤트 생성
• 장애 이벤트 생성 모드: 단일(Single)
• 정상 이벤트 닫기: 모든 장애
• 수동으로 클로즈 허가: 필요 시 체크

---

3. 최종 설정 예시

• 트리거 이름:
  portal.example.com 포털웹 로그인에 문제가 있습니다.
• 장애 조건:
  last(/Host/web.test.fail[portal web 모니터링])=1
• 복구 조건:
  last(/Host/web.test.fail[portal web 모니터링])=0
• 심각도:
  심각한 장애 (Critical)

---

4. 정리

• web.test.fail 값 → 0 정상 / 1 장애
• 트리거 조건식: =1 장애 발생, =0 복구

👉 이렇게 설정하면 단순 “HTTP 응답만 체크”하는 수준을 넘어서,
“실제로 로그인 시도가 성공하는지”를 트리거 알람으로 받을 수 있다.

🛠 마지막 수정일: 2025.09.18