우아한테크코스 레벨3 4차 스프린트 기간 필수 요구사항인 CloudWatch Logs 대시보드를 구성한다.
에 맞게 이를 구성한 내용을 정리한다.
CloudWatch는 다음의 설명에 따르면 DevOps 엔지니어, 개발자, SRE, IT 관리자 및 제품 소유자를 위해 구축된 모니터링 및 관찰 서비스
라고 한다. 즉 애플리에키션을 모니터링하고 시스템 전체 성능 변경에 대응하며 리소스 사용률을 최적화하는데 필요한 데이터와 실행 가능한 인사이트를 제공하는 것이다. 이외에도 EC2 등 AWS 인스턴스의 사용자 지정 로그 파일 모니터링 및 저장하는 기능을 제공한다.
우리는 CloudWatch를 이용하여 운영 상태를 통합적으로 보고 AWS 및 온프레미스에서 실행되는 AWS 리소스, 애플리케이션 및 서비스를 완벽하게 파악
할 수 있으며, 이상 동작을 감지하며, 경보를 설정하고, 로그와 지표를 나란히 시각화하며, 자동화된 작업을 수행
할 수 있다.
더 자세한 내용은 Amazon CloudWatch Logs란 무엇인가요? 에서 확인 가능할 것 같다.
현재 우아한테크코스에서 제공하는 AWS 계정의 경우 IAM 권한
이 없는 상태이다. 지표(metrics)를 수집할 권한을 유저에게 부여하고 설정 파일을 통해 수집을 원하는 지표를 설정하여 로그 데이터에 접근해 조회하기 위해서는 IAM 권한이 필요하며 역할을 부여하여야하는데, IAM 권한이 없으므로 시스템 수준의 metrics 수집(CPU, Memory, Network 관련 지표들)만 확인하도록 구성하였다.
가장 먼저 CloudWatch Logs 를 시작하려면 CloudWatch agent를 설치해야한다.
명령줄을 사용하여 CloudWatch 에이전트 다운로드 및 구성 을 참고하였다.
그런데 그 전에 CloudWatch 에이전트 패키지를 먼저 다운로드 해야하며 각 운영체제별로 그리고 아키텍쳐 별로 서로 다른 다운로드 링크를 제공한다. 우리가 사용하는 EC2는 Ubuntu 운영체제에 ARM64 아키텍쳐이므로 다음과 같은 다운로드 링크를 통해서 패키지를 다운로드 하였다.
다음으로 패키지를 우리 EC2에 다운로드하였으면 이제 해당 패키지를 설치해야한다. 이를 위해서 Linux 기반 서버에서는 DEB 패키지를 다운로드 한 경우 패키지가 있는 디렉토리로 변경하고 다음과 같은 명령어를 입력하면 설치가 된다.
sudo dpkg -i -E ./amazon-cloudwatch-agent.deb
만약 본인이 RPM 패키지를 다운로드 하였다고 하면 동일하게 패키지가 있는 디렉토리로 이동하고 다음 명령을 입력하면 된다.
sudo rpm -U ./amazon-cloudwatch-agent.rpm
다음으로 우리는 CloudWatch 에이전트 실행으로 바로 넘어갔다. CloudWatch 에이전트와 함께 사용하기 위한 IAM 역할 및 사용자 생성 이라는 챕터가 있는데, 현재 우리는 IAM 권한을 부여받지 못한 상태이므로 넘어갔다.
CLI를 사용해서 서버에서 CloudWatch 에이전트를 시작하려면 사용하려는 에이전트 구성파일을 에이전트를 실행할 서버에 복사하고 해당 파일을 복사할 경로 이름을 기억해주어야한다.
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
위의 명령에서 -a fetch-config
는 에이전트가 최신 버전의 CloudWatch 에이전트 구성 파일을 로드하도록 하며 -s
옵션은 에이전트를 실행시키는 것이다.
다음으로 CloudWatch 에이전트의 구성(설정) 파일을 만들어야하는데, 마법사로 구성 파일을 생성하는 방법과 수동으로 구성파일을 생성 또는 편집하는 두 가지 방법이 있다. 우리는 마법사로 CloudWatch 에이전트 구성 파일 생성 을 참고하여 진행하였다.
만약 본인이 수동으로 구성하고 싶다면 다음 글을 참고하면 좋을 것 같다.
마법사를 이용한다면 다음과 같이 간단한 명령어를 통해서 시작할 수 있다.
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
위와 같이 현재 agent를 사용하려는 OS를 선택하고, 우리가 현재 EC2 를 사용하고 있는지 혹은 On-Premises 서버를 사용하고 있는지를 묻는다. 이렇게 몇가지 질문들을 하는데 여기서 중요한 것은 Do you want to turn on StatsD daemon?
이라는 질문이다. StatsD
라는 데몬을 실행시키겠냐는 것인데, StatsD를 사용하여 사용자 지정 지표 검색 글을 참고해볼 수 있다. 우리는 StatsD 클라이언트를 사용하여 지표(metric value)를 모아서 CloudWatch 에이전트에 전송할 수 있습니다.
그리고 StatsD daemon의 collect 주기를 설정하는데 우리는 10초로 설정해주었다.
(스크린샷을 함께 페어로 진행하였던 베루스에게 받은 것이라 순서가 뒤죽박죽일 수 있다.)
앞서 우리가 10초 단위로 collect 했던 것을 어느정도의 주기로 aggregation 할 것이냐 묻는데 우리는 1분으로 설정해주었다. 다음으로는 CollectD 라는 것을 통해서 지표를 모니터링하길 원하냐는 문구가 나오는데 옆에 WARNING 으로 CollectD 가 설치되지 않은 경우 실패할 것이라고 이야기한다. 그런데 우리는 CollectD 를 설치한 적이 없으므로 이를 생략해주었다.
다음으로는 기본적으로 수집할 데이터를 묻는다. CPU, Memory 등을 묻는다. 당연히 포함해주었다. 그리고는 세부사항에 대한 설정을 묻는다. 각 코어마다 CPU 를 모니터링 할 것이냐는 질문에는 yes 로 응답해주었다. 다음으로는 ec2의 imageId, instandId, 인스턴스 타입등을 모두 지표에 통합할 것이냐와 같은 질문이 오는데 yes로 응답해준다.
스크린샷의 마지막 질문은 고해상도로 지표를 수집하겠냐는 질문이다. 모든 지표를 분단위로 확인할 수 있지만 output json file 의 특정 지표에 대해 사용자 지정을 할 수 있다고 한다. 우선은 60초로 지정해주었다.
이어서 우리가 응답한 것을 기반으로 작성된 설정 파일에 추가할 것이 있는지 물어보고
설정파일에 만족하는지를 묻는다.
그리고 로그 파일을 모니터링 하길 원하냐는 질문이 오고, 우리의 로그 파일 경로를 입력해주었다. 하지만 아마 우리의 경우 IAM 권한 부여를 못하였기 때문에, 로그 그룹을 볼 권한이 없어 이를 확인하지는 못한다..
위와 같은 화면을 보면서 CloudWatch Agent 설정을 마치게 된다.
이렇게 설정을 마치고 나면 우리의 EC2 서버의 CPU 사용률과 네트워크 사용률을 다음과 같은 지표로 확인해볼 수 있게 된다.