Dev Diary
[ 살펴보기 ] AWS - CloudWatch

[ 살펴보기 ] AWS - CloudWatch

Chan's photo
Chan
·

6 min read

Cloudwatch를 통해 AWS에서 사용하고 있는 다양한 resource를 mornitoring할 수 있다. 예를 들어 cloudwatch를 통해 AWS에 배포된 application을 운영중인 EC2의 CPU 사용량, Network traffic과 같은 다양한 지표를 모니터링할 수 있다. 해당 포스트에선 CloudWatch를 통해 EC2를 monitor하는 법을 살펴본다.

EC2 통해 application을 실행하면 EC2는 default로 5분 단위로 metric data를 cloud watch에 전달한다. 만약 1분 단위로 metric data를 전달하고 싶으면 detailed monitoring을 활성화 할 수 있지만 추가 요금이 발생할 수 있으니 주의한다.

CloudWatch 기본 metrics

EC2 instance에서 기본적으로 제공하는 metrics data는 다음과 같다. ( CloudWatch → Dashbarods → Automatic dashboards ( Tab ) → EC2 )

  • CPUUtilization : EC2 instance가 사용한 CPU resource의 percentage를 측정

  • DiskReadOps : Instance store volume에서 발생한 read operation을 측정

  • DiskWriteOps : Instance store volumn에 발생한 write operation 측정

  • DiskReadBytes : Instance store volume의 read operation으로 발생한 bytes를 측정

  • DiskWriteBytes : Instance store volume의 write operation으로 발생한 bytes를 측정

  • NetworkIn: Instance가 network interface를 통해 받은 traffic bytes를 측정

  • NetworkOut: Instance에서 network interface를 통해 나간 traffic bytes를 측정

  • NetworkPacketsIn : Instance가 network interface를 통해 받은 packet의 개수를 측정

  • NetworkPacketsOut : Instance에서 network interface를 통해 나간 packet의 개수를 측정

  • StatusCheckFailed : Instance의 모든 status check결과를 측정한다 status check가 정상이면 0이고 비정상일 때는 1이다.

  • StatusCheckFailed_Instance : Instance status check 결과를 측정한다. status check가 정상이면 0이고 비정상일 때는 1이다.

  • StatusCheckFailed_System : System status check 결과를 측정한다. status check가 정상이면 0이고 비정상일 때는 1이다.

CloudWatch Agent

CloudWatch에서 기본적으로 제공하는 metrics에는 메모리 사용량이나 디스크 사용량은 포함되지 않는다. 만약 메모리 사용량이나 디스크 사용량까지 측정하고 싶다면 Instance에 CloudWatch Agent를 설치하여 metrics 데이터를 추가해 줘야 한다.

Agent를 통해 custom metics를 추가하면 추가 요금이 발생할 수 있으니 주의하자. ( additional metrics that you add during this process are billed as custom metrics. For more information about CloudWatch metrics pricing, see Amazon CloudWatch Pricing )

아래 예제는 Ubuntu 22.04 ( x86-64 ) 환경에서 진행되었다

Instance에서 cloudWatch agent가 정상적으로 작동하기 위해서 instance에 CloudWatchAgentServicePolicy가 적용된 role을 부여해야 한다.

IAM에서 CloudWatchAgentServicePolicy를 가진 role을 생성하고 cloudWatch agent를 설치할 instance에 적용 시켜준다. ( EC2 instance 선택 → Action → Security → Modify IAM Role )

이제 instance에 접속해 agent download link를 통해 agent를 download한다. download link 형식은 다음과 같으며 region은 instance를 배포한 region으로 대체 해준다.

Download link는 instance를 배포한 os와 architecture에 따라 다를 수 있으므로 Ubuntu 22.04 ( x86-64 ) 환경이 아니라면 자세한 사항은 documentation을 참고하자. ( Reference - Download the CloudWatch agent package )

https://amazoncloudwatch-agent-(region).s3.(region).amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

ex)
https://amazoncloudwatch-agent-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

우선 위의 download link를 통해 agent를 download 받는다.

wget https://amazoncloudwatch-agent-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

package를 download한 경로로 이동해 다음 command를 통해 package를 설치한다.

sudo dpkg -i -E ./amazon-cloudwatch-agent.deb

pacakge가 설치되면 다음 command를 통해 configuration wizard를 실행한다.

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

위의 command를 실행하면 agent configuration을 위한 여러 질문을 하며 모든 질문을 마치면 agent configuration file이 생성된다. wizard를 통해 configuration을 설정할 때 configuration file을 local에 저장 했다면 agent configuration file은 다음 경로에 저장된다.

 /opt/aws/amazon-cloudwatch-agent/bin/config.json

configuration 설정 질문 중 metrics config 선택 질문이 있는데 해당 질문에서 선택하는 값에 따라 agent가 수집하는 metrics data가 달라진다. Linux instance 기준 선택할 수 있는 option과 수집 metrics data는 다음과 같다 ( Renference - CloudWatch agent predefined metric sets )

  • Basic : mem_used_percent, disk_used_eprcent

  • Standard : cpu_usage_idle, cpu_usage_iowait, cpu_usage_user, cpu_usage_system, disk_used_percent, disk_inodes_free, diskio_io_time, mem_used_percent, swap_used_percent

  • Advanced : cpu_usage_idle, cpu_usage_iowait, cpu_usage_user, cpu_usage_system, disk_used_percent, disk_inodes_free, diskio_io_time, diskio_write_bytes, diskio_read_bytes, diskio_writes, diskio_reads, mem_used_percent, netstat_tcp_established, netstat_tcp_time_wait, swap_used_percent

configuration 파일 생성이 완료되었으면 다음 명령어를 통해 agent를 실행할 수 있다.

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

위의 command를 통해 agent를 실행한 다음 다음 command를 실행하여 올바르게 실행되고 있는지 확인할 수 있다.

sudo systemctl status amazon-cloudwatch-agent

CloudWatch Alarm

CloudWatch Alarm을 통해 Cloudwatch를 통해 monitor하는 EC2 instance의 metrics를 대상으로 특정 조건을 설정하고 해당 조건이 초과되면 email을 보내거나 혹은 EC2 instance를 종료하는 등 특정 작업을 수행할 수 있다.

EC2 instance의 NetworkPacketsIn metric 데이터를 기준으로 특정 수치를 초과하면 지정한 email로 message를 보낼 수 있도록 alarm을 설정해보자.

CloudWatch → All alarms 페이지로 이동하면 새로운 alarm을 생성한다. Select metric 버튼을 통해 테스트하는 EC2 instance의 NetworkPacketsIn metric을 선택한다. ( select metric → EC2 → Per-Instance Metrics → 나오는 List 중에서 테스트하는 instance 의 NetworkPacketsin metric을 선택 후 선택 완료 )

그런 다음 instance를 검사하는 기간과 NetworkPacketsin의 임계값을 설정한다. 해당 예제에선 검사 기간은 1분, 임계값은 10으로 설정하고 있다. Addtional configuration의 datapoints to alarm은 1분 기간 동안 2번 검사를 하고 2번 모두 임계값인 10을 초과하면 alarm 상태를 변경하도록 설정하고 있다.

그리고 다음 버튼을 누르면 다음과 같이 alarm 상태에 따라 어떤 action을 할지 설정할 수 있는 페이지가 나온다. Add nofigication 버튼을 통해 in alarm, OK, insufficient data 각각 상태에 따라 다른 action을 설정할 수 있으며 Notification 뿐만 아니라 lambda, EC2, Auto Scailing등을 대상으로 특정 action을 설정할 수도 있다.

현재 포스트는 설정한 alarm 임계값이 초과되면 email로 message를 보내는 것이 목적이므로 Notification section의 in alarm 상태에 대한 설정만 추가한다.

Notification section에 Alarm state trigger이 위의 이미지와 같이 in alarm으로 설정하고 notification을 보낼 SNS topic을 설정한다. 사용할 수 있는 topic이 생성한 상태라면 해당 topic을 사용하고 아니라면 create new topic을 선택해 새로운 topic과 notification을 전달할 email을 설정한다.

다음 버튼을 눌러 alarm의 이름을 설정하고 이 때 까지 설정한 설정값을 최종 확인하고 alarm 생성 버튼을 통해 alarm을 생성해보자.

그리고 나서 alarm을 생성할 때 입력했던 email을 확인하면 notification subscription confirm관련 email이 전달된 것을 확인할 수 있다. confirm link를 클릭해서 confirmation page로 넘어가면 subscription confirmation 과정이 완료된다.

그런 다음 테스트를 하는 instance에 설정한 임계값이 초과될 수 있도록 instance에 배포한 application에 계속해서 request를 발생시켜보자. 그리고 생성한 alarm 정보를 확인해보면 시간이 조금 지난 뒤 state가 in alarm으로 변하고 notification이 email로 전달된 것을 확인할 수 있다.

CloudWatch Alarm 역시 free tier를 초과해서 사용하면 추가 요금이 발생하므로 주의하자.

CloudWatch Log

EC2에서 실행되는 nginx의 log나 pm2의 log등을 위에서 살펴본 CloudWatch agent를 통해 AWS에서 제공하는 CloudWatch log로 전송할 수 있다.

테스트를 위해 nginx의 access log를 CloudWatch agent를 통해 CloudWatch Log로 전송해 nginx log를 CloudWatch Log에서도 확인할 수 있도록 구성해보자.

우선 CloudWatch → Log groups 페이지로 이동해 새로운 log group을 생성한다. group name을 설정하고 retention setting을 통해 log group에 추가된 각 log 정보를 얼마나 오래 저장하고 있을 것인가 설정하고 group을 생성해준다. CloudWatch Log 역시 free tier이상 사용하고 추가 요금이 발생할 수 있으므로 주의하자.

CloudWatch Agent가 nginx의 access log를 생성한 CloudWatch Log에 전송할 수 있도록 CloudWatch Agent configuration file을 수정해준다.

wizard를 통해 configuration을 설정할 때 configuration file을 local에 저장 했다면 agent configuration file은 다음 경로에 저장된다.

/opt/aws/amazon-cloudwatch-agent/bin/config.json

그리고 다음과 같이 logs와 같은 설정을 추가해준다. file_path에는 CloudWatch Log로 전송할 log 파일의 위치 log_group_name은 CloudWatch Log groups 페이지에서 생성한 log group의 이름을 설정하고 log_stream_name에 stream의 이름을 설정해준다. 여기서 stream은 현재 instance에서 전송하고 있는 log 정보를 모아서 다른 instance에서 전송하고 있는 log 정보를 구분하는 identifier라고 생각할 수 있다.

opt/aws/amazon-cloudwatch-agent/bin/config.json

{
        "agent": {
          ...
        },
        "logs": {
          "logs_collected": {
            "files": {
              "collect_list": [
                {
                  "file_path": ".../nginx/access.log",
                  "log_group_name": "log-group-test",
                  "log_stream_name": "{instance_id}_steam_nginx_log"
                }
              ]
            }
          }
        },
        "metrics": {
              ...
        }
}

configuration file 수정을 마치면 다음 command를 실행시켜준다. command에 사용된 경로는 실제 amazon-cloudwatch-agent-ctl과 config.json 파일이 존재하는 경로여야 한다.

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

nignx access log가 쌓일 수 있도록 nginx를 통해 접속하는 application에 reqeust를 여러 번 전달하자.

이제 CloudWatch의 Log groups 페이지에서 config 파일의 log_group_name property에 설정했던 log group 상세 페이지를 살펴보면 하단에 log_stream_name에 설정한 이름으로 stream이 생성된 것을 확인할 수 있다. 해당 stream을 통해 nginx의 access log를 확인할 수 있다.

위에서 CloudWatch Agent를 생성하는 예제를 살펴볼 때 기본적으로 CloudWatch Log의 write 권한을 포함하고 있는CloudWatchAgentServicePolicy를 EC2에 적용할 role에 추가했지만 만약 role의 policy를 개별적으로 구성하여 EC2에 적용하는 경우 CloudWatch Log에 write할 수 있는 policy가 포함되어 있어야 정상적으로 작동한다.

AWS