Zabbix 정기 보고가 발행되지 않을 때 — HA 실행 노드와 PDF 생성 경로 점검
AI_Manager
Zabbix에서 보고 일정을 저장했다고 PDF가 바로 발행되는 것은 아니다. 실제 실행 중인 Server, 보고 생성 서비스, 내부 웹 주소, 수신 경로가 모두 연결되어야 한다. Rocky Linux와 VirtualBox 실습에서 정기 보고를 추가하면서 겪은 미발행과 화면 준비 대기 오류를 정리했다.
사용 환경은 Zabbix 7.0.30 LTS의 Server 두 대와 공유 DB, 중앙 2호기의 공식 Ubuntu web-service 이미지, 내부 수신 시험용 Mailpit이다. 외부 메일은 보내지 않았다.
일정은 있는데 발행 기록이 없었다
중앙 2호기에 보고 서비스를 만들고 Server에 보고 작성 프로세스를 활성화했다. 그런데 이 Server 컨테이너를 재생성하는 동안 Active 역할이 중앙 1호기로 넘어갔다. 1호기에는 아직 보고 작성 설정이 없었다. 웹 화면에서는 공유 DB의 보고 일정이 정상적으로 보였지만 예약 발행은 진행되지 않았다.
확인한 원인은 실행 노드와 보고 설정의 불일치였다. 이 구성에서 DB에 저장된 일정과 각 컨테이너의 실행 설정은 같은 방식으로 복제되지 않는다. 웹 서비스 컨테이너가 정상 실행 중이라는 사실만으로 보고를 생성할 Active Server까지 준비됐다고 판단하면 안 된다.
| 점검 항목 | 확인한 내용 | 의미 |
|---|---|---|
| HA 상태 | 중앙 1호기가 Active | 실제 보고 실행 주체 확인 |
| 보고 설정 | 중앙 2호기에만 작성 프로세스 활성화 | 일정이 보이는 것과 실행 가능 여부는 다름 |
| 보고 목록 | 시험 일정의 발행 기록 없음 | 단순 SMTP 수신 지연으로 단정할 수 없음 |
| 후속 조치 | 1호기를 정상 정지해 역할 전환 후 예비 노드로 복구 | 보고 설정이 있는 2호기에서 시험 재개 |
역할 전환 전후에는 Active가 하나인지, 예비 노드가 복귀했는지, 대상의 새로운 관제 값이 계속 들어오는지 확인했다. 이것은 보고 기능의 HA 완료를 뜻하지 않는다. 현재 보고 생성과 수신 시험 구성은 여전히 중앙 2호기에 의존한다.
Server와 web service의 연결을 따로 확인한다
이 실습의 Server는 host network를 사용한다. 다음 값은 같은 호스트의 loopback에만 공개한 보고 서비스를 가리킨다. 일반 bridge network 구성에서 그대로 복사하면 127.0.0.1이 다른 컨테이너 자신을 뜻할 수 있으므로 네트워크 방식을 먼저 확인한다.
ZBX_STARTREPORTWRITERS: '1'
ZBX_WEBSERVICEURL: 'http://127.0.0.1:10053/report'
TZ: Asia/Seoul/report 경로를 빠뜨리지 않는다. 허용 출발지는 실제 연결에서 관측한 주소로 제한하고, 보고 서비스 포트를 외부망에 열어 해결하지 않는다. 서버 사이를 건너는 호출로 바꾸면 TLS와 방화벽을 함께 설계한다.
Frontend URL은 운영자 PC에서 열리는 주소만으로 충분하지 않다. 보고 서비스 안의 브라우저가 그 주소를 해석하고 접속하며 인증서를 신뢰해야 한다. 이번에는 공식 이미지의 Chromium에 한글 폰트와 내부 CA 신뢰 자료를 추가했다. 인증서 오류 무시 옵션은 사용하지 않았다.
PDF 생성 요청은 들어왔지만 화면 준비가 끝나지 않았다
역할을 맞춘 뒤 첫 PDF 요청에서는 다음 오류가 남았다.
Cannot fetch data.: dashboard failed to get ready ... context canceled이 메시지만 보고 CA나 방화벽 문제라고 단정하지 않았다. 내부 HTTPS는 정상 응답했고, 웹 접근 로그에는 보고용 HeadlessChrome의 정적 파일 요청과 위젯 요청이 보였다. 일부 위젯 요청이 진행되는 동안 요청이 취소된 기록도 확인했다. 적어도 “웹 주소에 전혀 연결되지 않았다”는 상황과는 달랐다.
| 단계 | 점검할 내용 | 해석 |
|---|---|---|
| 생성 요청 | web service의 report request 로그 | Server가 생성 서비스를 호출했는지 |
| 웹 접속 | DNS·주소·CA 신뢰·HTTP 상태 | 보고 브라우저가 Frontend를 열 수 있는지 |
| 화면 준비 | 위젯 요청·오류·서버 자원 | 일부 위젯이 대기하는지 |
| 전달 | 보고 발행 상태와 SMTP 수신함 | PDF 생성과 전달을 나눠 확인 |
| 내용 | 실제 첨부 PDF의 한글·그래프·기간 | 파일 존재만으로 완료 처리하지 않음 |
같은 설정으로 다시 예약 발행했을 때에는 PDF 생성 응답과 내부 수신이 성공했다. 재시도 성공은 확인했지만, 최초 대기 오류의 근본 원인은 확정하지 못했다. 캐시나 자원 압박 때문이라고 입증 없이 결론 내리지 않는다. 반복 재현과 지속 발행 관찰이 필요한 항목으로 남겼다.
제한 시간을 무작정 늘리는 것도 해결이 아니다. 공식 7.0 문서에서 web service의 Timeout 허용 범위를 확인하고 실제 컨테이너 설정에 반영됐는지 대조한다. 이번 값은 허용 범위 안의 30이었다. Server·Frontend·보고 서비스의 서로 다른 제한 시간을 하나의 설정으로 혼동하지 않는다.
완료 판정은 실제 첨부 파일까지 본다
최종 시험에서는 보고 목록에 발행 기록이 생겼고 내부 SMTP 수신함에 PDF 한 개가 도착했다. 첨부 파일을 열어 한글 제목과 세 실습 대상의 CPU·메모리 그래프를 확인했다. 일회 시험 일정은 비활성화하고 수신 기록은 보존했다.
이 결과는 외부 메일 전달, 스팸 정책, 주간·월간 반복 발행이나 보고 서비스 장애 전환까지 검증한 결과는 아니다. 특히 현재 상태를 보여 주는 위젯과 보고 기간의 추세 그래프를 구분해야 한다. 현재 문제가 없다는 화면을 지난달 장애가 없었다는 통계로 해석하면 안 된다.
두 중앙 노드로 확장할 때에는 양쪽의 보고 작성 설정, 브라우저·CA·폰트, SMTP 접근 경로를 동일하게 준비한다. 그다음 Active 역할이 바뀐 뒤에도 실제 수신까지 이어지는지 시험한다. Zabbix Server의 HA와 PDF 보고 경로의 HA를 별도로 확인하는 것이 이번 작업에서 얻은 운영 기준이다.
참고 문서
Zabbix 7.0 보고 생성 서비스 설치, web service 설정과 Timeout, 정기 보고 구성, Mailpit Docker 구성.