Grafana를 통한 ELB 알림 설정
자빅스를 통해 모니터링 대상에 대한 메트릭을 수집하고 트리거 설정을 통해 두레이 메신져와 메일을 통해 알림을 받고 있습니다. 자빅스 에이전트를 설치 가능한 온프레미스의 서버나 AWS EC2 인스턴스, NHN클라우드 인스턴스의 경우 이러한 방법이 용이하지만, AWS ELB나 RDS와 같이 관리형으로 제공하는 서비스의 경우 대상에 에이전트를 설치하는 것이 불가하기 때문에 AWS Cloudwatch Metrics 에서 제공하는 메트릭을 받아오는 Python 스크립트를 통해 자빅스에서 메트릭을 수집하도록 구성하고 트리거 발생 시 알림을 수신하도록 설정하고 있습니다.
하지만 위의 방법의 경우 아래와 같은 단점이 있을 수 있습니다.
1) 이미 Cloudwatch Metrics 에서 수집한 메트릭을 다시 자빅스가 수집하는 것이기 때문에 메트릭 수집 작업이 중복(자빅스 DB 데이터 공간 낭비)되고,
2) 자빅스에 설정한 아이템 수집 간격에 따라 Cloudwatch Metrics 에 수집된 메트릭이 자빅스에서 수집되기까지 일정 시간의 지연이 발생하며,
3) 대상이 많아질수록 자빅스 서버에서 메트릭을 수집하는 Python 스크립트의 실행 횟수가 증가하기 때문에 자빅스 서버에 부하가 발생할 수 있습니다.(금년 7월 경 자빅스에 등록된 RDS 호스트 수가 많아짐에 따라 1분 간격으로 실행되는 Python 스크립트로 인해 부하가 발생하여 해당 템플릿의 아이템 수집 간격을 5분으로 늘렸던 내역이 있습니다.)때문에 이와 같은 단점을 보완하기 위해 Cloudwatch Metrics 에 수집된 메트릭을 자빅스로 다시 수집하는 것이 아닌, 메트릭 시각화 도구인 그라파나를 통해 Cloudwatch Metrics 에 수집된 메트릭을 직접 쿼리하고 메트릭의 임계값에 따라 경보 알림을 발생하도록 테스트를 진행해봤습니다.
테스트 환경
테스트를 위해 아래와 같이 AWS 리소스를 구성했습니다.
1) CentOS7 AMI를 사용한 EC2 인스턴스 -> 그라파나 서버
2) CentOS7 AMI를 사용한 EC2 인스턴스 -> 웹서버, 헬스 체크 대상
3) 1개 웹서버를 대상으로 가지는 ALB -> 모니터링 대상
4) 1개 웹서버를 대상으로 가지는 NLB -> 모니터링 대상헬스 체크 대상 웹서버 구성
헬스 체크 대상 웹서버의 경우 단순히 아파치 웹서버를 설치하고 index.html 파일만 구성하여 헬스 체크가 가능하도록 최대한 간단히 구성합니다.
yum install -y httpd
echo hi > /var/www/html/index.html
systemctl start httpd && systemctl enable httpdGrafana 설치
참고. 그라파나 설치
https://grafana.com/docs/grafana/latest/installation/rpm/
참고. 그라파나 다운로드
https://grafana.com/grafana/download그라파나 서버를 설치하도록 하겠습니다.
# 그라파나 yum 레포 추가
vim /etc/yum.repos.d/grafana.repo
[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
저장 후 닫기
# 그라파나 서버 설치
yum install -y grafana
# 서비스 실행/자동실행
systemctl start grafana-server && systemctl enable grafana-server
# 접속(기본 포트 3000)
http://서버_아이피:3000/
# 기본 계정
admin / admin
# AWS 인증을 위한 자격증명 파일 생성
mkdir -p /usr/share/grafana/.aws/
vim /usr/share/grafana/.aws/credentials
[default]
aws_access_key_id = ***********
aws_secret_access_key = **********************
저장 후 닫기위와 같이 설치를 완료하면 브라우저를 통해 "http://서버_아이피:3000/" 주소로 접속합니다. 기본 관리자 계정으로 로그인하면 최초 로그인 시 관리자 비밀번호를 변경하도록 화면이 보여집니다. 적절한 비밀번호로 설정 후 다시 로그인합니다.
Cloudwatch 연동(Data Source로 추가)
그라파나는 Prometheus, Zabbix, MySQL 등 다양항 데이터 소스(시각화할 데이터가 저장된 대상)를 지원합니다. 우리는 Cluodwatch 의 메트릭을 시각화하고 싶기 때문에 Cloudwatch 데이터 소스를 추가합니다.
다수의 AWS 계정을 사용하는 경우 AWS 계정마다 별도의 데이터 소스를 생성해줘야하기 때문에 데이터 소스의 이름은 AWS 계정을 식별할 수 있도록 지정했으며, 인증 방식은 다른 방법을 사용해도 관계 없으나 가급적 Accesskey 를 직접 입력하는 방식은 피해 Credentials file 로 선택했습니다.
설정이 완료된 후 Save & Test 버튼을 눌러 설정한 데이터 소스가 정상적으로 작동하는지 테스트합니다. 만약 에러가 발생한다면 이전 단계에서 구성한 AWS 인증 파일의 경로 및 내용을 확인합니다.
알림 수단 생성
경보 발생 시 알림을 받을 수 있도록 알림 수단을 생성하겠습니다.
그라파나의 경우 이메일 외에도 슬랙, 라인, 텔레그램 등 다양한 연락 수단을 제공하지만, 아쉽게도 두레이는 포함되어 있지 않습니다. 이런 경우 webhook을 선택하여 원하는 URL로 알림 API를 전송 가능합니다. 먼저 알림 수신을 원하는 두레이 채팅방에서 연동 서비스 추가 및 연동 URL을 확인합니다.
복사한 연동 URL을 아래와 같이 그라파나 알림 수단으로 입력해줍니다.
동일 그래프에서 쿼리하는 대상 중 여러 대상에 동시에 장애가 발생하는 경우 알림이 다시 발생하지 않기 때문에 장애가 해결되지 않으면 일정 시간 후 리마인드 알림이 발생하게 옵션을 추가해줄 수도 있습니다.
하단 Test 버튼을 눌러 정상적으로 그라파나 테스트 알림이 두레이로 수신되는지 확인합니다.
대시보드 그래프 및 경보 설정
다음 단계는 경보 알림 설정을 위한 대시보드 설정입니다. 이 단계에서는 공개되어 있는 대시보드 템플릿을 사용해도 관계 없으나 그라파나 경보의 경우 템플릿 변수를 지원하지 않기 때문에 기존 템플릿을 그대로 사용하기가 어렵습니다. 때문에 모니터링을 위한 대시보드는 별도로 세팅하고 여기서는 경보를 위한 대시보드만 따로 세팅해줍니다.
Cloudwatch 에서는 ALB와 NLB를 별도의 네임스페이스로 관리하기 때문에 아래와 같이 ALB/NLB 쿼리를 각각 추가해줍니다. A 쿼리 구성 후 하단의 "+ Query" 버튼을 누르면 B 쿼리를 추가 가능합니다.
이제 Alert 탭으로 이동하여 경보를 생성해줍니다. 만약 경보 생성 버튼이 보이지 않고 Template variables 관련 에러가 보여진다면 그래프 쿼리에 사용한 변수 중 템플릿 변수(${변수명} 형태)가 포함되어 있을 수 있으니 쿼리 부분을 다시 구성합니다.
구성이 완료되면 우측 상단의 Save 버튼을 눌러 대시보드를 저장해줍니다.
알림 발생 테스트
헬스 체크 대상 웹서버의 Apache 프로세스를 중지시켜 헬스 체크 실패 상황을 발생시켜 보겠습니다.
아래와 같이 두레이 메신저를 통해 알림이 수신된 것을 확인할 수 있습니다.
이제 서비스를 복구시켜 경보 해제 알림이 발생하는지 확인합니다. 경보 해제 알림의 경우 경보가 발생했던 대상에 대한 정보가 없는 점은 조금 아쉽습니다. (NLB의 경우 Cloudwatch Metrics 로 메트릭이 수집되는데에 2~3분 정도의 딜레이가 있어 복구가 조금 더 늦게 됩니다.)
결론
그라파나를 통해 Cloudwatch Metrics 에서 수집한 메트릭을 활용하여 경보 알림을 설정하는 방법을 알아보았습니다.
Grafana로 AWS 리소스 모니터링 구성 시 장점
1) Cloudwatch Metrics 서비스에서 원하는 메트릭을 검색해서 추가하는 방식이 간단하다.
반면 자빅스는 기존 스크립트에 없는 메트릭을 수집하고 싶은 경우 스크립트를 수정해야하는 부담이 발생한다.
(수정 중 구문 오류 시 기존 정상적으로 수집하고 있던 메트릭 수집에도 영향이 발생)
2) 자빅스를 통해 Cloudwatch Metrics 에서 수집한 메트릭을 중복 수집하는 방법보다 메트릭이 업데이트되는 지연 시간이 짧다.
3) Grafana의 경우 Grafana 자체가 메트릭을 저장하지 않으며 Cloudwatch Metrics 에 저장된 데이터를 불러와 보여주기만 하기 때문에, 자빅스에 Cloudwatch Metrics 에서 불러온 데이터를 중복 저장하는 방식에 비해 자빅스의 DB 데이터 저장 공간을 절약할 수 있다.
다만 테스트 진행 시 아래와 같은 단점도 확인하였습니다.
1) 동일 그래프에서 발생하는 다수 대상의 장애가 개별적으로 알림을 발생시키지 않는 점
-> AWS 계정별로 그래프/경보를 따로 생성하면 개별적으로 알림 수신 가능
-> 해당 단점은 아래 기술한 Grafana 8 Alert 에서 개선됨
2) 공개된 그라파나 대시보드 템플릿에 ALB에 대한 템플릿은 있지만 NLB에 대한 템플릿은 없어 NLB에 대한 템플릿은 사용자가 직접 만들어줘야하는 점
-> 이 부분은 자빅스도 동일
-> Grafana 공식 사이트에 업로드되어 있는 AWS 서비스 관련 대시보드의 종류가 다수 있어 활용이 용이
3) 경보 발생/복구 시 보여지는 정보가 조금 적은 점
-> 커스텀이 가능하니 필수적으로 경보 메시지에 포함할 내용을 정리할 필요가 있음
추가 내용 - Grafana 8 Alert
Grafana 8 버전에서 지원하는 새로운 경보 시스템
달라진 점
1) 대시보드의 그래프와 경보가 분리됨
-> 기존 그라파나 경보는 대시보드에 그래프를 추가하고 해당 그래프에서 경보가 발생하는 임계값을 설정하는 방식이었으나, Grafana 8 경보에서는 그래프와 경보가 분리되어 그래프는 추가하지 않아도 경보만 추가 가능
2) 하나의 그래프가 모니터링하는 여러 대상을 개별적으로 평가
-> 기본 그라파나 경보는 하나의 그래프가 여러 대상을 모니터링할 때 장애가 발생한 대상이 하나이든 다수이든 하나의 알림만 발생시켜 다수 장애 발생 시 확인이 어려웠으나, Grafana 8 경보에서는 하나의 경보가 모니터링하는 대상이 다수이더라도 대상을 개별적으로 평가하여 다수 장애 발생 시 다수의 알림의 발생
3) 두레이에서 Grafana 8 알림을 지원하지 않음
-> 두레이 대화방 메일 설정으로 알림 받을 수 있음
4) 그 외 경보 및 알림 관련 메뉴가 세분화됨
