[AWS] CloudWatch

1. CloudWatch ?

  AWS 서비스 및 리소스에서 발생하는 로그를 수집, 전달, 모니터링, 경보 발생등의 기능을 갖춘 AWS 서비스이다. AWS에 존재하는 대부분의 서비스, 리소스 로그를 보려면 CloudWatch 를 사용해야 한다.

CloudWatch 는 여러가지 기능이 있고 자주 사용하는 몇가지를 들면,

- 로그 및 리소스 사용량 모니터링
- 특정 기준값에 대한 알람
- 알람 발생 시 특정 동작 수행
- 로그 통계, 디스플레이 (대시보드)
- 수집 로그 분석할 수 있도록 데이터 서비스와 연동 가능 (firehouse, kinesis 등)
- 수집 로그 저장할 수 있도록 스토리지 서비스 연동 가능 (S3 등)
- 타 리전 간 수집 로그 송수신 가능 (특정 리전에서 수집한 로그를 다른 리전으로 보낼 수 있음)

1) CloudWatch Log

  CloudWatch의 세부 기능으로 수집한 로그 모니터링 및 분석, 필터링, 이상행위 탐지 등 을 할 수 있다. 수집한 로그는 log groups 에 쌓이게 되며, log groups 의 로그 스트림을 통해 로그를 볼 수 있다. Log 메뉴에 대한 세부 기능은 아래와 같다.

- log groups : 연동 서비스, 리소스의 수집된 로그를 확인 모니터링 할 수 있는 기능
- log anomalies : 비정상 행위 탐지 기능, 탐지 시 알림 발생 가능하다.
비정상 탐지 기능은 머신러닝과 패턴 기반으로 나뉜다. 머신러닝 기능은 CloudWatch 스스로 수집한 로그를 분석하여 비정상 행위 탐지 기준을 찾는다. 최소 2주 이상의 수집한 로그를 15분 이상 학습해야 정상적인 기능을 수행할 수 있다. 패턴기반은 명시한 특정 패턴 또는 기준 값을 만족하면 비정상 행위로 탐지한다.

- live tail : 수집한 로그를 실시간으로 모니터링할 수 있는 기능, 실시간으로 필터링하고 별도의 강조 표시를 할 수 있다. (log insights 는 과거의 로그에 대해 필터링, 검색이 가능한 것과 차이가 있다.)
- log insights : 수집한 로그에 SQL 쿼리를 사용해 필터링(검색) 가능. live tail 은 실시간이지만, log insights 는 수집된 과거의 로그에 대해서만 필터링(검색)가능하다. (실시간 필터링, 검색 불가능)
- contributer insights : 말 그대로 contributer 에 대한 시각화를 제공하는 기능이다. contributer은 어느 특정 지표이며, 이 지표(contributer)가 어떤 영향을 얼마만큼 주는지 순위별로 나타낼 수 있다. 예를 들어 어플리케이션에 대해 어느 IP가 사용량이 많은지 순위를 매겨 나타내는 것이다. 이를 통해 서비스 또는 리소스에 영향을 주는 요소가 어떤 것인지, 같은 종류의 요소들 중 영향을 많이 주는 순서대로 시각화를 해서 상태 체크, 장애 예방 및 대응 등을 효율적으로 수행할 수 있다.

2) CloudWatch metric

  CloudWatch에서 사용하는 지표이며, 무엇에 대한 정보(로그)를 수집할 것인지 정의한다. 예를 들어 AWS에서 기본적으로 제공하는 metric에 EC2 CPU 사용량이 있다. 이 metric 을 활용해 EC2 의 CPU 정보를 수집하고, 필터링, 모니터링, alams(경고), event 트리거 등으로 활용할 수 있다.

- AWS에서 기본으로 제공하는 metric (무료 사용), 사용자가 직접 생성하는 metric 두 가지 존재
(사용자가 임의로 생성한 metric은 요금 청구됨)
- AWS에서 제공하는 metric 은, 관련 서비스가 활성화 되어 있어야 검색, 사용 가능
- AWS 서비스를 삭제하고 몇 주(약 2주) 후, 관련 metric 은 비활성화 되어 사라진다.
(실제 삭제 된 것은 아니고, AWS 서비스 활성화 시 관련 metric을 다시 쓸 수 있다.)

AWS에서 제공되는 metric 은 관련된 AWS 서비스가 활성화되어야 metric을 검색하거나 사용할 수 있다. 즉 특정 metric을 AWS 콘솔에서 검색하려해도, 관련 서비스가 활성화 되어 있지 않으면 찾을 수 없다. 그리고 AWS 서비스를 삭제하고 몇 주(약 2주) 지나면 관련된 metric은 자동으로 비활성화되어 사라진다. (실제로 삭제된 것은 아니고, AWS 서비스 활성화 시, 관련 metric을 다시 쓸 수 있다.) 예를 들어 NETWORK FIREWALL 의 metric 을 보려면 NETWORK FIREWALL 서비스를 실행해야 한다. 그리고 NETWORK FIREWALL 을 삭제한 후 2주 정도 지나면 FIREWALL metric이 비활성화 되어 사라진다.

AWS에서 기본적으로 제공하는 metric은 다양하니 아래의 url 을 참고.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html

  metric 메뉴에는
- All metrics : AWS 서비스와 관련된 metric (지표)들을 검색, 선택하여 해당 metric 에 대한 모니터링, 통계(그래프), 알람, 이벤트 발생 등의 작업을 수행할 수 있게 한다.

- streams : metric stream (지표의 흐름) 을 다른곳으로 내보내는 것, 즉 지표에 대한 출력 값을 지정된 서비스에 지속적으로 보낸다. 보내는 곳은 S3, firehouse 등 AWS 서비스가 될 수도, 서드 파티가 될 수 도 있다.

- explorer : tag 가 설정된 여러 리소스의 metric을 시각화하는 기능이다. 하나의 대시보드에 여러개의 리소스 메트릭을 나타낼 수 있다. 그래서 여러 리소스의 상태를 동시에 점검(health check, troubleshooting) 할 수 있다.

3) CloudWatch alarms

  어떠한 트리거가 있을 때 알림(경보)를 발생하는 기능이다. 알림의 트리거(조건)는 metric 또는 다른 알림, log, 이상탐지 등이 될 수 있다. 특정 종류의 알림 여러개가 울리면, 이와 관련된 알림을 발생시키는 것을 예로 들 수 있다.

알림을 발생시킨 후 리소스, 서비스에 특정 행위를 하도록 설정할 수 있다. 예를 들면 알림 발생 후 EC2 를 종료하거나, 오토스케일링을 활성화하는 것이다.

CloudWatch 의 알림은 단순히 console 에서 뿐만 아니라, AWS SNS, EventBridge 등을 통해 사용자에게 문자, 이메일을 보낼 수 있고, application 들 끼리 메시지를 주고 받을 수 있다.

4) CloudWatch insights

  CloudWatch 에 연동된 AWS 인프라를 대상으로 한 모니터링 기능이다. 모든 서비스, 리소스를 다 모니터링 할 수 있는 것은 아니고, Container, DB, Lambda, Application, EC2 Resource 대해서만 모니터링 할 수 있다. 지표와 로그를 트리거로 하여 알림을 발생 시킬 수 있고, 대시보드를 통해 가시성을 높일 수 있다.

Insights 기능으로 AWS 주요 인프라서비스(상기 5개 서비스)의 장애 발생 징후를 파악하거나, 장애 발생 시 최대한 빨리 조치하는데 활용할 수 있다.

2. CloudWatch 구성 실습

  CloudWatch 를 사용 할 수 있는 예시는 다양하지만, 이미 구성해본 NetworkFirewall 로 연동해서 실습할 것이다. (구성하면서 CloudWatch 와의 연동도 했었고, 로그도 잘 올라온다.)

이번 실습은 요금이 발생하는 부분이어서 작업 후 요금이 발생되는 부분들을 모두 비활성화 또는 삭제 해야 한다. 요금이 발생할 수 있는 부분은

* EC2, AWS NETWORK FIREWALL(로그 연동 설정 포함), metric filter (사용자가 생성한 필터), 이메일 알림 (AWS SNS 서비스) 이다.

실습 과정은
- AWS NetworkFirewall 구성 및 CloudWatch 연동 설정
- AWS CloudWatch log group 생성 및 설정
- log insights 로 수집된 로그 필터링
- 특정 로그에 대한 alarm (알림) 설정

AWS NetworkFirewall 에 대한 개념 및 구성(cloudwatch 연동 포함)은 아래의 글을 참고한다.

[AWS] NETWORK FIREWALL (AWS 방화벽)

1) log group 생성 및 연동

로그 수집을 위해 log group을 생성한다. log group name 이름을 입력하고
retention setting 을 하는데 이것을 수집한 로그의 보유기간을 설정하는 것이다.
하루 단위에서 12개월 이상까지 다양하게 선택가능하다. 잠깐의 테스트라면 몇 일 정도를, 장기간 로그를 남기고 싶다면 개월 단위로 설정하면 된다.

log class는 standard 를 선택한다. 우측 하단의 craete로 log group을 생성한다.

로그 그룹을 생성했으면, 연동할 서비스에 로그 연동 설정을 해야만 한다.
AWS 방화벽에 로그 연동 설정을 할 것이므로,
[AWS] NETWORK FIREWALL (AWS 방화벽) 게시글의 cloudwatch 연동 부분을 참고해서, 생성한 cloudwatch 로그 그룹에 연동 설정을 한다.

AWS 방화벽의 경우 연동 설정을 하자마자 바로 로그가 보이지 않는다. 일정량의 로그가 쌓여야 cloudwatch 로그 그룹에서 식별이 되며, 식별된 수집 로그는 log streams 으로 확인 할 수 있다.

log streams 에서 로그를 빨리 보고 싶다면, 로그를 많이 발생시키는 방법 밖에는 없고
AWS 방화벽에서 로그를 많이 생성하기 위해서는 방화벽과 연결된 EC2에 통신시도를 많이 해서, 인위적으로 로그를 많이 발생시켜야 한다. (AWS 방화벽 실습 때 EC2 를 통해 접속 테스트를 했으니, EC2 connect 또는 apache index 페이지에 접속시도를 많이 해서 로그를 발생시킨다.)

수집된 로그를 보면 allowed(pass, 허용) 패킷, BLOCK(차단) 패킷을 확인 할 수 있다.
사진에서는 수리카타 룰의 알림 메시지 "ALLOW TCP 22" 을 볼 수 있다.

2) log insights 필터링

log streams 에서 원하는 로그를 찾기엔 어려우므로, log insights 필터링 기능을 통해 특정 로그를 찾을 수 있다. 찾을 로그는 allow (허용, pass) 로그이며,

log insights 페이지 상단에서 select log group by 를 log group name 으로 하고
바로 우측의 선택창을 눌러, 필터링할 로그 그룹을 선택한다. (여기서는 AWS 방화벽에 연결된 FW 로그 그룹 선택)

그리고 쿼리문은

fields @timestamp, @message, @logStream, @log
| filter @message like /allow/
| sort @timestamp desc
| limit 10000

로 입력하고 Run query 해주면, 화면 아래에 allow 문자로 필터링된 로그들을 볼 수 있다.
(AWS 방화벽 로그 스트림이 새로 생성되어서, 새로 생성된 로그 스트림에서 필터링 적용)
필터링된 로그들을 보면 allow (허용)된 로그만 조회 되었음을 알 수 있다.

3) metric filter 를 통한 alarm(알림) 설정

  cloudwatch의 주요기능에는 알림 기능도 있어 유용하게 쓸 수 있다. 알림 설정 자체는 어렵지 않다. 알림 설정 전 먼저 metric filter 을 먼저 생성해야한다.

allow (pass, 허용) 패킷이 몇 번 이상 들어왔을 때 발생하는 알림을 설정한다.

log group 의 하단 메뉴 metric filter 에서, 우측 하단의 create metric filter 을 선택한다.

필터링할 문자열을 입력한다. allow 패킷에 대한 알림 설정이므로, allow 를 필터 패턴으로 입력한다. 하단의 test pattern 이 있는데 필터링할 로그 스트림을 선택하고 test pattern 선택하면, 아래의 show test result 에 실제 필터링 되는 로그를 볼 수 있다.

필터링된 로그를 기준으로 알림을 발생시키는 것이다.
필터 문자열 설정, 테스트 후 우측 하단의 NEXT 선택

metric filter 의 필터 이름과 namespace , metric name, metric value 등을 입력한다. 임의로 입력해도 상관 없으니 식별할 수 있는 문자열, 숫자를 입력하면 된다.

입력 후 우측 하단의 NEXT 선택

생성된 metric filter 를 확인하고 create metrci filter 으로 생성한다.

metric filter 를 생성했으니, 화면 우측 상단의 create alarm 을 선택해서 알림을 생성단계로 진행한다.

Metric 설정
- statistic : maximum (특정 시간당 최대 횟수 기준)
- period : 5분, 5분 동안 metric filter 를 만족하는 로그의 갯수를 측정(counting)

Condition 설정
- threshold type : static (metric filter 만족하는 로그 갯수 기준으로 설정)
- Whenever ~ : greater (metric filter 만족하는 로그 갯수의 범위를 초과로 설정)
- than ... : 2 (metric filter 만족하는 로그의 갯수 기준을 2회로 설정)

위 설정의 의미를 설명하면, metric filter를 만족하는 로그의 갯수가 5분 동안 최대 2개 초과할 경우 알림의 상태를 변경한다는 뜻이다.

우측 상단의 statistic 에는 maximum 으로 한다. (시간 당 최대치에 대해서 통계 기록)
period 는 알림의 근거가 되는 로그 갯수를 몇 분동안 측정할 것인지인데, 5분으로 설정한다.

우측 상단의 Metric 설정은 5분 동안 metric filter 조건에 만족하는 로그가 최대 몇개인지를 조건으로 잡는 것이다. (풀어서 설명하면 5분동안 allow 패킷이 최대 몇개 들어오는지를 조건으로 설정하는 것이다. metric filter 의 조건은 allow 문자열을 가진 패킷을 찾는 것이므로.)

하단의 condition은 metric filter을 만족하는 로그 갯수 또는 이상행위 탐지 횟수를 기준으로 알림 상태를 변하게 하는 설정이다. static 은 metric filter로 필터링된 로그 갯수를 기준으로, anomaly detection은 이상행위 탐지 갯수를 기준으로 조건을 설정하는 것이다. 이상행위 탐지를 설정하지 않았으므로 threshold type을 static 으로 설정한다.

바로 아래 Whenever ~ 설정은 알림 조건이 되는 로그 횟수의 범위를 정한다. 보면 알겠지만,
greater 은 초과 , greater/equal 은 이상, lower/equal 은 이하, lower 은 미만 일 때 알림의 상태를 변경한다는 것이다.

테스트를 위한 설정은 greater 로 설정한다. 다음 설정의 than... 은 알림 기준이 되는 횟수를 정하는 것이고 2회로 설정했다.

전 단계가 알림의 기준 설정이었다면, 현 단계는 어떤 방식으로 알림을 수행할 것인지 설정하는 것이다. alarm state trigger 은 조건을 만족할 시 알림의 상태를 어떻게 바꿀 것인지 정하는 것이다. 조건을 만족 시 알림을 발생해야 하므로, In alarm 으로 설정한다. metric and condition 설정의 조건을 만족하면 알림 상태는 in alarm 으로 변경되고 알림이 발생한다.

만약 OK, Insufficient data 로 설정하면 조건을 만족시켜도 알림이 발생되지 않는다.
(OK, Insufficient data 는 알림을 발생시키는 설정이 아니기 때문)

alarm state 의 상태는 3 가지이며, 의미는 아래와 같다.

- In alarm : 경보 발생 상태
- OK : 정상 상태
- Insufficient data : 경보 발생 조건에 만족하는 로그가 없음

그리고 send a notification ~ 설정이 있는데 이 부분은 알림 메시지를 어떻게 보낼지 지정하는 것이다. 알림을 메일로 보낼 것이므로, create new topic (select an existing sns topic 으로 디폴트 알림을 선택하고 이메일을 입력해도 된다.)을 선택하고 topic name , 알림 받을 메일 주소를 입력한다. 그리고 create topic 으로 AWS SNS TOPIC 을 생성한다.

사진의 send a notification ~ 알림 설정은 디폴트 topic 으로 조금 다를 수 있으나
create new topic 으로 새로 topic을 만들어 설정해도 별 차이가 없다.

알림 설정 메뉴 아래를 보면 lambda, 오토 스케일링, EC2, system manager 의 Action 을 설정할 수 있다. 즉 알림 발생과 동시에 특정 AWS 서비스에 행위를 발생시킬(지시 할) 수도 있다. 이번 테스트에서는 사용하지 않으니, 설정하지 않는다.

alarm name 을 입력하고, 알림을 보낼 내용을 입력한다. (alarm description) 그리고 NEXT

알림 설정 값들을 확인 한 후 create alarm 으로 알림을 생성한다.

생성한 cloudwatch 알림이 목록에 조회된다.

cloudwatch 에서 이메일 알림 설정을 했으니, 입력한 이메일로 구독 승인 메일이 왔을 것이다.
승인 메일의 confirm subscription 을 선택하면 이메일로 알림을 보낼 수 있게 설정이 완료된다. (AWS 에서 입력한 이메일로 알림을 보낼 수 있게, 이메일 사용자가 승인하는 것이다.)

email 알림을 위한 AWS SNS REQUEST(요청) 메일을 볼 수 있고 Confirm subscription 을 눌러 confirm(승인) 해준다.

AWS SNS 서비스의 topic 메뉴, cloudwatch 에서 구성한 topic 선택 시, 이메일 알림 설정을 볼 수 있다. subscription 부분을 보면 이메일 주소와 status 가 confirmed(승인) 되었음을 알 수 있다.
만약 입력한 이메일에서 승인을 하지 않으면, status는 대기 중(진행 중)으로 되어있다. 승인 메일을 다시 보내고 싶다면 목록 바로 상단 우측의 request confirmation 을 선택하면 된다.

이메일 알림 설정까지 완료 했으면, cloudwatch 알림 설정은 완료된 것이다.

테스트를 위해 allow 로그를 발생시키기만 하면 된다. AWS 방화벽을 통해 EC2 로 들어오는 allow 패킷이 필요하므로 EC2 의 아파치 인덱스 페이지에 접속 후 F5 로 새로고침을 반복한다.

새로고침을 반복하며 패킷을 발생 시, alarm 메뉴의 알림 상태가 in alarm 으로 변하는 것을 볼 수 있다. 발생된 알림 확인은 cloudwatch alarm 의 in alarm 에서 확인 가능하지만, 발생 후 금방 사라진다. (위 사진은 알림 발생 직후 변경된 in alarm 상태가 아닌, 과거의 알람 상태 내역을 보여준다.)

과거에 발생한 알람 또는 알람 상태 변화를 보려면 alarm 의 all alarms 에서 생성한 alarm 을 선택하고, 하단 메뉴의 history 에 들어가면 확인 가능하다. 사진을 보면 알람의 상태가 변하며 알림을 발생시키는 것을 볼 수 있다.

이메일에도 알림을 설정했으니 입력한 이메일로가면, 알림 이메일을 확인 할 수 있다.

실습 완료 후 사용하지 않는다면, 요금이 발생되는 부분들을 모두 비활성화 또는 삭제해야 한다.

* EC2, AWS NETWORK FIREWALL(로그 연동 설정 포함), metric filter (사용자가 생성한 필터), 이메일 알림 (AWS SNS 서비스) 등을 확인 한 후 사용하지 않으면 비활성화, 삭제한다.

AWS NETWORK FIREWALL의 삭제는, 라우팅 테이블에 설정된 AWS FIREWALL 레코드들을 먼저 삭제 한 후 수행하면 된다.