15. Zabbix 알람등록방법

Zabbix 알람 등록 방법

• 본 문서는 Zabbix에서 장애 알림을 등록하고 전송하는 기본 절차를 설명한다.
• Zabbix의 알림 기능은 Media type, User, Action, Trigger를 조합해 구성한다.
• 가장 일반적인 방식은 Email 또는 Webhook 기반 알림이며, Zabbix는 기본적으로 Email, SMS, Webhook, Script 같은 다양한 전달 수단을 지원한다.

구성 개요

• Media type: 알림 전달 수단을 정의하는 구성 요소이다.
• User / User group: 실제 알림을 수신할 사용자 또는 그룹이다.
• Action: 어떤 이벤트가 발생했을 때 누구에게 어떤 방식으로 알릴지 정의하는 규칙이다.
• Trigger: 장애 여부를 판단하는 조건이다.
• 전체 흐름은 다음과 같다.
  • Trigger 발생
  • Event 생성
  • Action 조건 평가
  • User 또는 User group에 Media type으로 알림 전송

권장 방식

• 운영 초기에는 Email 기반 알림부터 구성하는 것이 가장 단순하다.
• 협업 환경에서는 Slack, Teams, Telegram 같은 Webhook 기반 알림을 병행하는 구성이 일반적이다.
• 개인 계정에 직접 연결하기보다 운영팀, DBA, 개발팀 같은 User group 중심으로 구성하는 것이 유지보수에 유리하다.

사전 준비

• Host, Item, Trigger가 이미 구성되어 있어야 한다.
• Zabbix Server가 메일 서버 또는 외부 Webhook endpoint에 접근 가능해야 한다.
• 수신 대상 User 또는 User group이 준비되어 있어야 한다.
• Email 사용 시 SMTP 서버 정보가 필요하다.

Media type 설정

• 알림 설정의 첫 단계는 Alerts -> Media types에서 전달 수단을 구성하는 것이다.
• 기본 Email media type을 수정해서 사용할 수 있고, 새로운 media type을 직접 생성할 수도 있다.
• Media type 설정 화면에서는 SMTP server, SMTP helo, 발신자 이메일, 인증 방식, 메시지 템플릿 등을 지정할 수 있다.

Email 예시

Name: SMTP-Alarm
Type: Email
SMTP server: smtp.example.com
SMTP server port: 587
SMTP helo: smtp.example.com
SMTP email: zabbix@example.com
Authentication: Username and password
Username: zabbix@example.com
Password: StrongPassword

• 설정 후 Media type의 Test 기능으로 발송 테스트를 수행할 수 있다.

User 등록

• 알림을 수신할 사용자는 Users -> Users에서 등록한다.
• 신규 사용자 생성 후 Media 탭에서 어떤 전달 수단으로 받을지 추가해야 한다.
• 기본적으로 새 사용자는 media가 연결되어 있지 않으므로, User만 생성해도 알림은 전송되지 않는다.

User media 예시

Type: Email
Send to: admin@example.com
When active: 1-7,00:00-24:00
Use if severity: Not classified, Information, Warning, Average, High, Disaster
Enabled: Yes

• 심각도별 필터를 설정하면 특정 Severity 이상의 이벤트만 받도록 조정할 수 있다.

User group 구성

• 실제 운영에서는 개인 사용자보다 User group 단위로 알람을 보내는 방식이 더 일반적이다.
• 예를 들어 Infra-Team, DB-Team, App-Team 같은 그룹으로 나누면 역할별 알람 분리가 쉬워진다.
• Action에서 User group을 수신 대상으로 지정하면 신규 인력 추가 시에도 운영이 단순해진다.

Action 생성

• 알림 전송 규칙은 Alerts -> Actions -> Trigger actions에서 생성한다.
• Action은 조건(Conditions)과 동작(Operations)으로 구성된다.
• 예를 들어 특정 Host group에서 High 이상 Severity가 발생하면 운영팀 메일로 보내도록 설정할 수 있다.

Action 예시

Name: Send alert to Infra team
Conditions:
- Host group = Linux servers
- Trigger severity >= High

Operations:
- Send message to user group: Infra-Team
- Send only to media type: Email

• 필요 시 Recovery operations를 설정해 장애 복구 시점에도 별도 알림을 보낼 수 있다.

Trigger 조건과 연계

• Action은 Trigger 이벤트가 발생해야 실행된다.
• 따라서 Host 또는 Template에 실제 Trigger가 정의되어 있어야 한다.
• 예를 들어 CPU 과다 사용, Disk 사용량 초과, 서비스 응답 실패 같은 조건이 Trigger로 설정되어 있어야 한다.

Webhook 알림 구성

• Slack, Teams, Telegram 같은 협업 도구는 Webhook media type으로 구성할 수 있다.
• 공식 문서는 관련 YAML 파일을 import 한 뒤, 전용 User를 생성하고 Media 탭에서 webhook 정보를 연결하는 방식을 안내한다.
• Webhook도 결국 Media type -> User -> Action 흐름은 동일하다.

테스트 방법

• 설정 후에는 Media type 테스트와 실제 Trigger 발생 테스트를 모두 수행하는 것이 좋다.
• 가장 쉬운 방법은 임시 테스트 Trigger를 만들어 Action이 정상 작동하는지 확인하는 것이다.
• 알림이 오지 않을 경우 Media type 설정, User media 연결, Action 활성화 여부를 순서대로 점검한다.

방화벽 및 접근 제어

• Email 사용 시 Zabbix Server는 SMTP 서버로 접근 가능해야 한다.
• Webhook 사용 시 Zabbix Server는 대상 Webhook endpoint에 HTTPS 접근 가능해야 한다.
• 알림 계정의 인증 정보는 평문 문서화보다 Secret 관리 또는 제한된 접근 정책으로 관리하는 것이 좋다.
• 운영 계정과 테스트 계정을 분리하면 오발송을 줄일 수 있다.

대용량 운영 추천값

• 개인 단위보다 User group 중심으로 설계하는 것이 좋다.
• Severity별 Action을 나누면 알람 폭주를 줄이기 쉽다.
• 장애 알림과 복구 알림을 모두 활성화하면 운영 추적성이 좋아진다.
• 추천 시작 기준은 아래와 같다.

항목	추천값
기본 알림 방식	Email
협업 연동	Slack/Teams Webhook 병행
수신 대상	User group 중심
액션 기준	Host group + Severity 기반
복구 알림	활성화 권장
테스트 방식	Media test + Trigger test 병행

구방식 참고

• 과거에는 sendmail 또는 외부 스크립트 연동 중심으로 알람을 구성하는 사례가 많았다.
• 현재는 기본 Email media type과 공식 Webhook media type을 이용하는 편이 더 단순하고 유지보수도 쉽다.
• 기존 커스텀 스크립트 기반 알림은 즉시 제거하기보다 단계적으로 표준 media type 방식으로 전환하는 것이 현실적이다.

점검 항목

• Alerts -> Media types에서 media type이 정상 활성화되어 있는지 확인한다.
• User의 Media 탭에 실제 수신 주소가 등록되어 있는지 확인한다.
• Alerts -> Actions -> Trigger actions에서 Action이 활성화되어 있는지 확인한다.
• Trigger 자체가 실제로 발생 가능한 조건인지 확인한다.
• SMTP 인증 실패, User media 미등록, Action 비활성화는 가장 흔한 원인이므로 우선 점검한다.

운영 팁

• 운영팀, 개발팀, DBA처럼 역할별 User group을 먼저 설계하는 것이 좋다.
• Warning은 메신저, High 이상은 메일+메신저처럼 Severity별 채널을 분리하면 효과적이다.
• 유지보수 시간대에는 알람을 억제하거나 Escalation 규칙을 함께 설계하는 것이 좋다.
• 처음에는 Email 기반으로 단순하게 시작하고, 이후 Webhook, SMS, 자동 복구 워크플로우로 확장하는 방식이 안정적이다.