Category: Amazon CloudWatch
AWS 청구서 단순화 – CloudWatch 비용 통합
오는 7 월에 AWS 청구서에는 Amazon CloudWatch가 청구하는 방식 변경을 포함합니다. CloudWatch 팀은 청구서를 더 간단하고 이해하기 쉽게 만들기 위해 이러한 변경 작업을 수행했습니다.
요금 항목 통합
과거 CloudWatch 사용료는 청구서의 두 부분으로 나누어 져있었습니다. CloudWatch Alarms, CloudWatch Metrics 및 CloudWatch API에 대한 청구는 Elastic Compute Cloud (EC2) 세부 정보 섹션에 포함되고, CloudWatch Logs 및 CloudWatch Dashboards에 대한 청구는 CloudWatch 세부 정보 섹션에 보고됩니다 :
청구서의 두 부분에 걸쳐 요금을 분할할 경우, 전체 모니터링 비용을 찾아 이해하기가 어렵다는 고객 의견을 받았습니다. 이 문제를 해결하기 위해 이전에 EC2 (Elastic Compute Cloud) 세부 정보 섹션에 나와 있던 요금을 CloudWatch 세부 정보 섹션으로 이동합니다. 세부 청구서 보고서를 수정하고 AmazonEC2 서비스 코드에서 Amazon CloudWatch 서비스 코드로 옮기고 Amazon CloudWatch 서비스 이름으로 변경합니다. 이 변경 사항은 전체 청구서에 영향을 미치지 않습니다. 하나의 섹션에서 CloudWatch 사용에 대한 모든 청구를 통합합니다.
청구 비용 측정 항목
예상 요금이라는 CloudWatch 결제 측정 항목은 총 예상 요금 또는 서비스 별 분류로 볼 수 있습니다.
총계는 변하지 않을 것입니다. 그러나 앞서 언급했듯이 이전에는 AmazonEC2에 ServiceName 차원으로 있던 요금에는 AmazonCloudWatch로 설정되어 있습니다.
결과적으로 결제 경고의 임계 값을 조정해야 할 수도 있습니다.
다시 말씀 드리지만, 여러분의 AWS 청구서는 변경되지 않습니다. 2017 년 7 월에 AWS 청구서에 CloudWatch의 통합 요금이 표시되기 시작합니다.
— Jeff;
이 글은 AWS Bill Simplification – Consolidated CloudWatch Charges의 한국어 번역입니다.
EC2 Run Command와 CloudWatch Events 함께 사용해 보기
오늘은 EC2 Run Command (대규모 원격 인스턴스 관리 )와 CloudWatch Events (AWS 자원 변경에 대한 실시간 추적 기능) 기능을 함께 사용하는 방법에 대해 알아보겠습니다.
- EC2 Run Command 은 EC2 Systems Manager의 일부입니다. EC2 인스턴스 및 기존 사내 서버를 함께 안정적으로 대량 통제 및 선택적으로 운용할 수 있습니다. Windows 및 Linux에서 스크립트 실행, 소프트웨어 설치, 통계 및 로그 파일 수집 및 패치 등의 관리 작업을 수행 할 수 있습니다.
- CloudWatch Events를 사용하면 거의 실시간으로 AWS 자원의 변경 사항을 추적 할 수 있습니다. AWS Lambda 함수, Amazon Kinesis 스트림, Amazon SNS 토픽, 내부 EC2 인스턴스 및 EBS를 포함하여 원하는 곳으로 변경 내역을 쉽게 보낼 수 있는 이벤트 스트림을 만들 수 있습니다.
함께 사용해 보기
두 가지 서비스를 함께 동작할 수 있는 아이디어를 생각해 보겠습니다. EC2 Run Command를 사용하여 EC2 인스턴스 또는 사내 서버에서 작업을 수행하는 CloudWatch 이벤트 규칙을 만들 수 있고, 다음과 같은 활용 사례가 있습니다.
- 최종 로그 수집 – 종료될 인스턴스에서 애플리케이션이나 시스템 로그를 수집합니다 (수동 또는 오토 스케일링을 통해 생성된 인스턴스를 종료하게 될때)
- 오류 로그 상태 수집 – 애플리케이션 충돌 또는 보안 문제 발생 후 로그를 수집합니다.
- 인스턴스 설정 – 인스턴스가 시작된 후, 애플리케이션을 다운로드 및 설치한 뒤에 파라미터 및 시스템 구성을 설정하고 프로세스를 시작할 수 있습니다.
- 구성 업데이트 – S3에서 구성 파일을 변경하면, 적용 가능한 인스턴스 (태그 설정)에 설치할 수 있습니다. 예를 들어, 특정 태깅을 한 인스턴스 그룹에 Apache 웹 서버 구성 파일을 업데이트 하여 설치 한 후, 웹 서버를 다시 시작하여 변경 사항을 적용 할 수 있습니다. 또는 AWS IP 주소 범위가 업데이트 될 때마다 인스턴스 방화벽을 업데이트 하는 것도 가능합니다.
- EBS 스냅샷 테스트 및 오류 확인 – 새로운 스냅샷을 만든 후 테스트 인스턴스에 마운트하고, 파일 시스템에서 오류를 확인할 수 있습니다.
- 인스턴스 부하 조정 – 인스턴스가 시작되거나 종료 될 때마다 내부 추적 정보를 업데이트하거나 작업 부하의 균형을 조정할 수 있도록 다른 사람에게 알릴 수 있습니다.
직접 해보기
오토 스케일링을 통해 새로운 인스턴스를 오토 스케일링 그룹에 추가 할 때마다 특정 PowerShell 스크립트를 실행하는 기능을 만들어 보겠습니다.
먼저 CloudWatch 이벤트 콘솔을 열고 Create rule를 클릭합니다.
내 이벤트 소스를 자동 자동 확장 그룹 (AS-Main-1)으로 구성하고 EC2 인스턴스가 성공적으로 시작될 때, 기능을 수행하겠다고 표시합니다.
이제 타겟을 설정합니다. SSM 실행 명령을 선택하고 AWS-RunShellScript 문서를 선택한 다음, 자동 확장 그룹에서 태그가 지정된 인스턴스에서 명령을 실행하도록 지정합니다.
그런 다음 Configure details을 클릭하고 내 규칙에 이름과 설명을 입력 한 다음 Create rule를 클릭합니다.
모든 것이 설정되면 스케일 아웃 작업의 결과로 시작된 각 인스턴스에서 명령 service httpd start이
실행됩니다.
정식 출시
본 새로운 기능은 현재 사용할 수 있으며 지금 바로 사용할 수 있습니다.
— Jeff;
이 글은 EC2 Run Command is Now a CloudWatch Events Target의 한국어 번역입니다.
AWS 가격 인하 – CloudWatch Metrics
2011년 CloudWatch 맞춤형 통계 기능을 공개하여 여러분의 애플리케이션과 스크립트를 통해 데이터를 원하는 데이터를 모을 수 있게 되었습니다. 첫 10개까지는 무료로 제공하고, 하나 추가하는 경우 데이터양과 상관 없이 월 0.5 달러의 요금 체계를 가지고 있습니다.
오늘 CloudWatch 맞춤형 통계 기능의 가격을 인하합니다. 사용중인 통계 개수를 기반해서 보실 때 기본 40%에서 최대 96%의 비용 절감 효과가 나올 것으로 생각합니다. (아래는 버지니아 리전의 요금표입니다. 10개까지는 계속 무료입니다.)
Tier | 시작 | 끝 | 월별 비용 |
가격 인하율 |
첫 10,000개 까지 | 0 | 10,000 | $0.30 | 40% |
240,000개 까지 | 10,001 | 250,000 | $0.10 | 80% |
750,000 개까지 | 250,001 | 1,000,000 | $0.05 | 90% |
그 이후 | 1,000,001 | – | $0.02 | 96% |
EC2 상세 모니터링의 경우, 인스턴스 당 월간 $3.50에서 $2.10 으로 인하합니다. 새로운 가격은 2016년 12월 1일 부터 유효하게 되며, 자세한 사항 CloudWatch 요금표 에 게재될 예정입니다.
CloudWatch 맞춤 통계 기능을 사용 하신다면, 통계 보유 기간 확대 및 사용자 인터페이스 개선, the CloudWatch collectd 플러그인, 맞춤형 통계 보기 기능 제공, 신규 로그 통합 기능 등을 활용해 보시기 바랍니다.
– Jeff;
이 글은 AWS Price Reduction – CloudWatch Metrics의 한국어 번역입니다.
Amazon CloudWatch 업데이트 – 백분율 통계 및 신규 대시보드 위젯 추가
최근에 Amazon CloudWatch에 많은 기능을 추가하고 있습니다. 로그 통합 기능, 통계 보유 기간 확대 및 사용자 인터페이스 개선 등이 있었습니다. 오늘은 백분율 기반의 통계 및 신규 대시보드 위젯 기능 추가에 대해 소개해드리고자 합니다.
백분율 기반 통계
대규모 웹 사이트 또는 클라우드 애플리케이션을 실행할 때, 대부분 고객에게 기대 수준의 성능을 제공해야 합니다. 통계 수치의 평균을 보는 것도 좋지만 전체 상황을 이해할 수 없을 수도 있습니다. 평균치는 일부 성능의 이상값을 감추게 되는데, 예를 들어 1% 고객의 안 좋은 경험을 알아낼 수 없을 수도 있습니다
백분율 통계는 고객 경험을 적절히 전달하는 방식으로 성능 및 동작을 이해하고 시각화 할 수 있는 유용한 도구입니다. 예를 들어, 백분위를 사용하면 웹 사이트에 대한 요청 중 99%가 1 초 이내에 처리되고 있음을 알 수 있습니다. 아마존에서 백분위 수를 광범위하게 사용하고 있습니다. 예를 들어, 우리는 “P”값으로 목표치를 표현하고, P90, P99의 관점에서 성능을 관찰하고, 사이트 및 서비스에 대한 P100 (최악의 경우) 응답 시간을 개선해 왔습니다. 수년에 걸쳐, 롱 테일 상 (P99)에서 오는 수치에서 데이터베이스 및 기타 문제점을 찾아낼 수 있었습니다
Amazon EC2, RDS 및 Kinesis 뿐만 아니라 새로 생성 된 Elastic Load Balancer 및 Application Load Balancer에 대한 백분율 통계를 지원합니다. 맞춤 측정 항목에도 사용할 수 있습니다. 이제 CloudWatch (사용자 정의 대시 보드 포함)에서 백분율 통계를 표시하고 알람을 설정할 수도 있습니다.
백분위 수를 다른 메트릭과 함께 표시 할 수 있습니다. 예를 들어, 아래 황색과 녹색 선은 P90과 P95의 CPU 사용률을 나타냅니다.
CloudWatch 콘솔에서 원하는 백분율 통계를 설정할 수 있습니다.
CloudWatch에서 백분위 통계에 대한 지원은 응용 프로그램의 성능에 추가 가시성을 확보하기 위한 것으로 새로운 백분위 통계를 사용하는 방법에 대한 자세한 내용은 Elastic Load Balancing: Support for CloudWatch Percentile Metrics를 참고하세요.
신규 대시보드 위젯
신규 Stacked Area 및 Number 위젯을 CloudWatch 사용자 정의 대시 보드에 추가 할 수 있습니다.
네트워크 트래픽이 있는 누적 영역 위젯은 다음과 같습니다.
다음은 EC2 및 EBS 측정 항목이 포함 된 Number 위젯입니다.
정식 출시
이들 신규 기능은 이제 모든 AWS 지역에서 오늘부터 사용할 수 있습니다!
— Jeff;
이 글은 Amazon CloudWatch Update – Percentile Statistics and New Dashboard Widgets의 한국어 번역입니다.
EBS 스냅샷을 위한 신규 CloudWatch Events: 백업 자동화 구현하기
클라우드 컴퓨팅을 통해 부족한 지식으로 만들어진 기존 IT 운영 매뉴얼(runbook)을 자동화함으로서 운영 방식을 개선할 수 있습니다. 이러한 작업 중 상당수는 백업 및 복구 작업이며, 특히 소규모 조직에서는 큰 부담이 되고 있습니다.
많은 AWS 고객들이 Amazon Elastic Block Store (EBS) 볼륨을 사용하면서, 스냅샷 백업 생성 및 관리를 하고 있습니다. 이들 스냅샷을 리전간 복제를 하여 운영 혹은 재난 복구에 대비하고 있습니다.
오늘 부터 EBS 스냅샷에 CloudWatch Events를 추가하여 EBS 자동화 작업에 도움이 되고자합니다. 향후 클라우드 기반 백업 작업을 진행할 때 사용할 수 있는 새로운 이벤트는 다음과 같습니다.
- createSnapshot – 새로운 EBS 스냅샷 생성이 Complete 됐을 때
- copySnapshot – 새로운 EBS 스냅샷 복제가 Complete 됐을 때
- shareSnapshot – EBS 스냅샷이 계정에 공유되었을 때
AWS 고객들은 DescribeSnapshots
함수를 호출하여 지속적으로 스냅샷을 모니터링을 하고, 나오는 결과 중 특정 스냅샷을 골라서 표시만 해주지만 앞으로 신규 이벤트를 통해 리전 간 복제 같은 기능을 자동으로 수행할 수 있게 됩니다.
스냅샷 이벤트 활용하기
데이터 백업 과정을 좀 더 쉽게 이해하기 위해, 다른 리전에 스냅샷을 복제하는 기능을 만들어 보겠습니다. 먼저 적절한 IAM 정책을 정해 권한을 설정하고, AWS Lambda 함수를 통해 createSnapshot 이벤트가 생성될 때 실행해 보겠습니다.
먼저 IAM 역할 (CopySnapshotToRegion)을 만듭니다.
Lambda 함수를 생성 합니다. (코드 샘플은 Amazon CloudWatch Events for EBS 문서에서 찾을 수 있습니다.)
CloudWatch Events 콘솔에 가서 Create rule을 누르고, createSnapshot 이벤트를 선택합니다. (타겟은 생성한 람다 함수입니다.)
두번째로 규칙 이름을 설정합니다.
테스트를 위해 자신의 리전에서 스냅샷을 만들어 보겠습니다.
스냅샷이 완성되면, 람다 함수를 실행하여 스냅샷을 해당 리전에 몇 초 안에(볼륨 크가에 따라 복사 시간의 차이가 있을 수 있음) 복사된 것을 볼 수 있습니다.
신규 이벤트를 활용하여, 회사 혹은 다른 동료 AWS 계정으로도 공유할 수 있습니다. 많은 고객들이 부서별, 프로젝트별로 별도 계정을 사용하고 있습니다. 좀 더 자세한 사항은 AWS 멀티 계정 보안 전략을 살펴 보시기 바랍니다.
아래 그림은 주요 AWS 계정 운영 전략을 보여 주고 있습니다.
정식 출시
본 기능은 US East (Northern Virginia), US East (Ohio), US West (Northern California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), EU (Frankfurt), EU (Ireland), South America (São Paulo) 리전에서 오늘 부터 사용 가능합니다.
— Jeff
이 글은 New – CloudWatch Events for EBS Snapshots의 한국어 번역입니다.
CloudWatch 업데이트 – 로그 통합 기능
몇 년전 Amazon CloudWatch OS 및 애플리케이션 로그 파일 모니터링 및 저장 기능을 추가하여, 많은 AWS 고객이 이를 활용하여 다양한 방식으로 로그를 이용하고 있습니다. 예를 들어, 웹 서버의 로그 파일 중 404 에러가 나는 경우나 504 에러 등을 통해 서버의 상태를 파악할 수 있습니다.
각종 로그 파일에 대한 모니터링 및 알람을 받는 것도, 수백 혹은 수천 대의 인스턴스라면 통계적으로 살피기가 어렵습니다. 그래서, CloudWatch의 새로운 옵션으로서 로그 통합을 통한 시각화 방법을 제공합니다.
아래는 오후 5시 부근의 ERROR를 보여주는 통합 로그 그래프입니다.
좀 더 자세히 시간을 줄여서 드래그를 해보면,
그런 다음, 각 로그 아이콘을 클릭해서 관심 있는 (ERROR) 로그 파일을 선택합니다.
CloudWatch는 두번째 탭을 열어서 원하는 로그 파일을 시간 순에 따라 볼 수 있습니다. 각각의 에러 로그 또한 더 자세히 볼 수 있습니다.
이 기능은 로그 파일을 게시하는 데 사용되는 필터를 사용하는 상황에 적합합니다. 그러나 특정 로그 파일과 관련되지 않은 몇 가지 하위 시스템 측정 지표를 살펴보면 어떨까요? 위의 단계를 수행할 수 있지만, 이 시점에서 View를 선택합니다.
그래프의 시간 범위에 대해 필터링 된 모든 CloudWatch 로그 그룹을 볼 수 있습니다.
이 시점에서 아키텍처에 대한 지식을 활용하여 의사 결정을 내릴 수 있고, LogGroup을 선택할 수 있도록 도와 줄 수 있습니다. 다시 말하자면, 로그 그룹의 이벤트는 관심 있는 사람들만 볼 수 있도록 필터링할 수 있습니다. 차트가 Lambda 네임 스페이스에 있는 측정 지표에 포함되어 있는 경우, 필터가 적용되지 않더라도 로그 그룹에 링크가 표시됩니다.
이 새로운 기능은 오늘 부터 제공하여, 지금 바로 사용하실 수 있습니다!
— Jeff;
이 글은 CloudWatch Update – Jump From Metrics to Associated Logs의 한국어 번역입니다.
Amazon CloudWatch 업데이트– 통계 보유 기간 확대 및 사용자 인터페이스 개선
Amazon CloudWatch는 AWS 자원 및 구동하는 애플리케이션에 대한 모니터링 서비스입니다. 각종 통계치, 로그 파일을 수집해서 알림을 만들거나 AWS 자원의 변화에 대응할 수 있습니다. 오늘 두 가지 중요한 기능을 새롭게 출시합니다.
- 통계 보유 기간 확대 – CloudWatch 통계치는 15개월까지 보관
- 쉬운 통계 선택 기능 – CloudWatch 콘솔에서 관심 통계 선택 방식을 쉽게 변경
- 향상된 통계 그래프 기능 – 선택한 통계에 대한 다양한 그래프 생성 기능
하나씩 살펴 보도록 합시다!
통계 보유 기간 확대
2009년에 처음 Amazon CloudWatch를 출시(New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch) 했을 때, 시스템 통계 데이터는 14일간만 저장되었습니다. 그 이후로 사용자 정의 통계 데이터 확대 후에도 같은 기간이 제공되었습니다. 많은 고객들이 계절별 요인, 월간 통계치 및 연간 분석 등을 위해 더 오랜 기간 로그 통계를 보유할 수 있도록 요청하였습니다.
이에 부응하기 위해 앞으로 모든 통계치는 추가 비용 없이 15개월간 보관합니다. 데이터를 합리적으로 보관 및 사용하기 위해 아래와 같은 세부적인 기준을 따릅니다.
- 1분 단위 데이터 기록은 15일간 사용 가능
- 5분 단위 데이터 기록은 63일간 사용 가능
- 1시간 단위 데이터 기록은 455일(15개월)간 사용 가능
본 신규 기능의 가치를 이해하기 위해서는 바로 지금 콘솔에서 이전 3개월치 데이터를 보실 수 있습니다. 앞으로 12개월동안 이 데이터는 누적해서 볼 수 있습니다.
통계 보유 기간이 늘어나면 AWS Lambda 함수의 최근 2주간의 호출 내용과 문제가 있었는지 여부를 확인하는데 큰 도움이 될 것 입니다.
쉬운 통계 선택 기능
원하는 통계치를 빠르게 살펴보거나 그래프로 생성하기 위해, 콘솔에서 좀 더 간편하고 빠른 카드 스타일의 보기 옵션을 제공합니다.
카드 보기에서 살펴보려는 통계치를 검색할 수 있습니다. 아래는 이름에 “CPU”가 있는 것들입니다.
좀 더 자세하게 보면서, 그래프까지 생성하기 위해 모든 EC2 인스턴스의 CPU Utilization 통계치를 선택합니다.
같은 그래프로 여러 가지 통계를 삽입할 수도 있습니다.
향상된 통계 그래프 기능
앞으로 15개월간 저장하는 데이터를 좀 더 쉽게 선택했으면, 그 다음 단계로 이해하기 쉽도록 만드는 방법이 필요합니다. 새로운 탭인 Graphed metrics와 Graph options는 이를 위한 신규 기능입니다.
각 통계 수치에 대해 자세한 사항을 볼 수 있습니다.
Actions 컬럼을 누르면, 알림을 만들 수 있고, 통계 데이터 복사 및 그래프 삭제 등의 기능이 가능합니다.
변경하고자 하는 값은 Statistic 컬럼에서 선택할 수 있습니다.
통계 복사 기능을 통해 서로 비교도 가능합니다. 예를 들어, 최대 혹은 평균 CPU Utilization을 살펴 볼 수 있습니다. (Period를 6시간으로 변경했습니다.)
이제 Graph options 탭의 Y 축을 살펴 보면, 동시에 7개의 EC2 통계치를 그래프로 만들 수 있습니다. 값의 구간을 조정을 계속함으로서 의미 있는 값들을 찾아 낼 수 있습니다.
클릭을 하면, 통계치에 대한 그래프 이름도 정할 수 있습니다.
왼쪽 및 오른쪽 Y 축에 대한 값도 설정 가능합니다.
시간 구간 별 통계치를 보기 위한 달력 표시기도 개선이 되었습니다. 날짜 선택 구간을 선택하여, 다양한 정보들을 만들어 낼 수 있습니다.
몇 가지 관련 내용을 설정합니다.
그래프 이름을 클릭해서, 필요한 그래프 이름 수정을 할 수 있습니다.
통계 그래프 부분에 보완을 한 다음, 기존 대시보드에 추가하거나 새로 만들 수 있습니다.
아래 그임은 새로운 그래프를 만드는 몇 가지 사례를 포함하고 있습니다.
정식 출시
통계 수치 관련 기능 및 사용자 경험 향상을 위해 US East (Northern Virginia), US West (Oregon), US West (Northern California), EU (Ireland), EU (Frankfurt), South America (Brazil), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Asia Pacific (Sydney) 리전에서오늘부터 사용 가능합니다.
다시 한번 강조하지만, 여기에 추가 비용은 없습니다.
— Jeff;
이 글은 Amazon CloudWatch Update – Extended Metrics Retention & User Interface Update의 한국어 번역입니다.
Amazon CloudWatch를 위한 collectd 플러그인 공개
대부분 고객들은 Amazon CloudWatch에 많은 애플리케이션 통계 데이터를 저장해 왔습니다. (자세한 내용은 New – Custom Metrics for Amazon CloudWatch 참고) 이 블로그에서 “사용자의 AWS 자원을 CloudWatch를 통해 통계 수치를 통해 그래프로 표시하거나 알림을 설정하거나, 자동화 작업을 할 수 있다.”라고 소개하였습니다.
오늘 부터 collectd 기반 새로운 CloudWatch 플러그인를 사용하여 사용자 시스템에서 통계를 수집하여, CloudWatch에 저장할 수 있습니다. 다양한 유형의 통계를 수집하는 collectd 기능과 저장 및 표시 그리고 경고를 알릴 수 있는 CloudWatch 기능을 결합하여 EC2 인스턴스의 상태와 성능, EC2에서 실행하는 온프레미스 하드웨어나 응용 프로그램에 대해 자세히 파악할 수 있습니다. 본 플러그인은 오픈 소스 프로젝트로 시작하였고, 여러분의 피드백을 기다리고 있습니다.
collectd 데몬은 성능을 위해 C로 작성되어 있습니다. 현재 100개 이상의 플러그인을 지원하고 Apache 및 Nginx 웹 서버 성능, 메모리 사용량, 가동 시간 통계를 수집 할 수 있습니다.
collectd 설치 및 설정
실제 동작을 살펴보기 위해 collectd과 새로운 플러그인을 EC2 인스턴스에 설치하고 구성해 보았습니다.
먼저 CloudWatch에 통계 데이터를 쓸 수 있는 권한을 제공하기 위한 IAM 정책(Policy)을 만듭니다.
이 정책을 활용하여 만들어진 EC2에 접근할 수 있는 IAM 역할(Role)을 만들었습니다.
기존 서버에서 통계를 수집하기 위해 플러그인을 사용하려는 경우, (이미 EC2 인스턴스를 실행하는 경우) 이러한 단계를 진행하지 않고 적절한 접근 권한을 사용하여 IAM 사용자를 생성 합니다.
이제 IAM 정책 및 역할이 준비 되면, EC2 인스턴스를 시작하고 관련 역할을 선택합니다.
로그인 후, collectd를 설치합니다.
$ sudo yum -y install collectd
플러그인을 설치할 스크립트의 실행 권한을 설정한 뒤 실행합니다.
Then I fetched the plugin and the install script, made the script executable, and ran it:
$ chmod a+x setup.py
$ sudo ./setup.py
몇 가지 질문에 응답한 후, 문제없이 설정을 수행 할 수 있습니다. collectd 설정 완료 후 시작합니다.
Installing dependencies ... OK
Installing python dependencies ... OK
Copying plugin tar file ... OK
Extracting plugin ... OK
Moving to collectd plugins directory ... OK
Copying CloudWatch plugin include file ... OK
Choose AWS region for published metrics:
1. Automatic [us-east-1]
2. Custom
Enter choice [1]: 1
Choose hostname for published metrics:
1. EC2 instance id [i-057d2ed2260c3e251]
2. Custom
Enter choice [1]: 1
Choose authentication method:
1. IAM Role [Collectd_PutMetricData]
2. IAM User
Enter choice [1]: 1
Choose how to install CloudWatch plugin in collectd:
1. Do not modify existing collectd configuration
2. Add plugin to the existing configuration
Enter choice [2]: 2
Plugin configuration written successfully.
Stopping collectd process ... NOT OK
Starting collectd process ... OK
$
collectd을 수행할 플러그인 설치와 설정이 완료되면, 다음 단계는 필요한 통계 항목을 결정하여 CloudWatch로 보내도록 플러그인을 설정하는 것입니다 (각 통계마다 요금이 발생할 수 있으므로, 이것은 중요한 단계입니다).
/opt/collectd-plugins/cloudwatch/config/blocked_metrics
는 수집한 통계 목록이 포함되어 있으나 CloudWatch에 보내지는 않습니다.
$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics
# This file is automatically generated - do not modify this file.
# Use this file to find metrics to be added to the whitelist file instead.
cpu-0-cpu-user
cpu-0-cpu-nice
cpu-0-cpu-system
cpu-0-cpu-idle
cpu-0-cpu-wait
cpu-0-cpu-interrupt
cpu-0-cpu-softirq
cpu-0-cpu-steal
interface-lo-if_octets-
interface-lo-if_packets-
interface-lo-if_errors-
interface-eth0-if_octets-
interface-eth0-if_packets-
interface-eth0-if_errors-
memory--memory-used
load--load-
memory--memory-buffered
memory--memory-cached
메모리 사용량에 대한 로그를 남기기 위해 /opt/collectd-plugins/cloudwatch/config/whitelist.conf
를 추가합니다.
memory--memory-.*
collectd 설정 파일 (/etc/collectd.conf
)는 collectd와 플러그인 설정을 포함하고 있습니다. 이번 경우는 변경할 필요는 없습니다.
전체 변경을 사항을 적용하기 위해, collectd를 다시 시작합니다.
$ sudo service collectd restart
메모리를 사용량을 높이기 위해, 인스턴스를 조금 사용하고 CloudWatch 콘솔을 열어 필요한 부분을 표시했습니다.
위의 스크린샷은 CloudWatch 콘솔에 탑재된 미리 보기 기능에 포함되어 있으므로 자신의 화면에 같은 것이 표시되지 않더라도 놀라지 마세요. (자세한 내용은 향후 알려드립니다).
정식 서비스 중인 인스턴스를 모니터링하는 경우, collected 플러그인을 하나이상 설치할 수 있습니다. Amazon Linux AMI에서 사용할 수 있는 목록은 아래를 참조하십시오.
$ sudo yum list | grep collectd
collectd.x86_64 5.4.1-1.11.amzn1 @amzn-main
collectd-amqp.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-apache.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-bind.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-curl.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-curl_xml.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-dbi.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-dns.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-email.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-generic-jmx.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-gmond.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-ipmi.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-iptables.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-ipvs.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-java.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-lvm.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-memcachec.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-mysql.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-netlink.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-nginx.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-notify_email.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-postgresql.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-rrdcached.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-rrdtool.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-snmp.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-varnish.x86_64 5.4.1-1.11.amzn1 amzn-main
collectd-web.x86_64 5.4.1-1.11.amzn1 amzn-main
알아 두실 점
collectd 버전 5.5 이상을 사용하는 경우, 아래 네개의 통계를 기본적으로 지원합니다.
- df-root-percent_bytes-used – 디스크 속도
- memory–percent-used – 메모리 사용량
- swap–percent-used – swap 사용량
- cpu–percent-active – cpu 사용량
원하지 않는 경우, whitelist.conf 파일에서 제거 할 수 있습니다.
현재 Amazon Linux AMI, Ubuntu, RHEL, CentOS 기본 저장소는 이전 버전의 collectd를 제공하고 있습니다. 사용자 저장소에서 설치하거나, 소스에서 직접 빌드한 경우 기본 설정이 다른 점을 유의하시기 바랍니다.
참고 사항
추가적인 collectd 플러그인도 whitelist.conf 파일을 설정하여, 더 많은 통계 데이터를 CloudWatch에 제공할 수 있습니다. CloudWatch 알람을 생성하고 사용자 정의 대시 보드 등을 할 수 있습니다.
시작은 GitHub의 AWS 연구소 를 방문하여 collectd의 CloudWatch 플러그인 을 다운로드하십시오.
더 자세한 사항은 GitHub에서 collectd CloudWatch 플러그인를 다운로드 하세요.
— Jeff;
이 글은 New – CloudWatch Plugin for collectd의 한국어 번역입니다.
Amazon CloudWatch 대시보드 사용성 개선
Amazon CloudWatch는 AWS 인프라에서 발생하는 문제 확인, 진단, 대응, 해결을 위해 로그 데이터를 확인하고 처리할 수 있는 API를 제공하고 있습니다. 이를 위해 로그 분석 (CloudWatch 운영 체제 및 애플리케이션 로그 저장 및 모니터링 기능) 및 대시 보드 (CloudWatch 대시 보드 – 맞춤형 통계 보기 기능 제공)에 이은 추가적인 사용성 개선 기능을 오늘 선보이게 되었습니다.
CloudWatch Logs 사용성 개선
CloudWatch Logs는 운영 체제 및 응용 프로그램 로그 파일을 관리하는 가용성과 확장성 및 내구성이 높은 안전한 서비스입니다. 로그 데이터 수집, 보관, 필터, 검색, 보관을 위한 작업 부하를 줄이고 애플리케이션과 비즈니스에 집중할 수 있도록합니다.
로그 건수나 크기가 늘어나도 효율성과 생산성을 유지할 수 있도록하기 위해 AWS에서는 CloudWatch Logs 콘솔에 사용성 개선 사항을 일부 추가했습니다.
- 로그 데이터의 포맷 처리 개선
- 긴 로그 파일에 대한 접근 단순화
- 로그 그룹 내에서 검색 용이
- 로그 파일의 공동 작업 간소화
- 특정 기간의 검색 개선
이번 기능 출시 전에 CloudWatch 대시 보드에도 개선점을 추가했습니다.
- 전체 화면 모드
- 어두운 테마
- 차트에서 Y 축 범위 지정
- 그래프 이름 변경 단순화
- 그래프 설정 영구 저장소
CloudWatch 로그 콘솔 사용해 보기
개선점들을 직접 살펴보도록 하겠습니다. 먼저 CloudWatch Logs Console을 열어, 로그 그룹을 클릭한 후 그룹내 로그 스트림에서 오른쪽의 View options를 선택합니다.
다음과 같이 여러 행으로 확대한 상태에서 로그 메시지를 표시하려면 Expand all을 클릭합니다.
일반 텍스트 로그를 표시하려면 텍스트 표시를 전환 할 수 있습니다.
이 밖에도 로그 그룹 내의 스트림 모든 로그 데이터 표시 방식을 개선했습니다. 로그 그룹을 선택하고, strong>Search Events을 클릭하면 해당 로그 그룹 내의 스트림의 모든 로그 데이터를 볼 수 있습니다. 예를 들어, 하나의 Lambda 함수의 여러 호출에 대한 과금 대상 기간을 쉽게 찾을 수 있습니다.
또한, 제한없이 볼 수 있도록 스크롤 막대가 도입되었습니다. 이제 원하는 만큼 로그 파일을 스크롤 할 수 있게 되었습니다.
다음과 같이 특정 기간을 지정하거나, 한 번의 클릭으로 날짜를 지정하는 등 검색 범위를 좁힐 수 있게 되었습니다.
팀원으로 작업을 하는 경우, 자신의 로그 분석 세션의 URL을 공유 할 수 있게 되었습니다. URL은 검색 매개 변수와 필터가 포함 된 다음과 같은 형식입니다.
group=<log_group_name>_log;stream=<log_stream_name>;filter=<filter_parameter>;start=PT<time_frame>
위의 CloudWatch Logs 콘솔 개선점은 지금 바로 이용하실 수 있습니다. 자세한 내용은 Getting Started with CloudWatch Logs를 참고하시기 바랍니다.
CloudWatch 대시 보드 추가 개선 사항
먼저 대시 보드에 새로운 전체 화면 모드를 추가했습니다. Actions 메뉴에서 Enter full screen로 전환할 수 있습니다.
전체 화면 모드 상태가되면 Dark을 클릭하여 어두운 테마로 전환 할 수 있습니다.
전체 화면 모드에서 다크 테마를 사용하는 Redis의 예를 보실 수 있습니다.
경우에 따라 대시 보드에 그래프를 어떻게 표시할지 섬세하게 관리하고 싶을 경우, 예를 들어 데이터 이상 값으로 그래프를 읽기 어려울 때, 대시 보드에서 Y축의 특정 범위에 집중하고 싶은 때가 있을 수 있습니다. 다음의 예는 그러한 경우의 그래프입니다. 이상 값이 급증한 후 일어나는 경향을 확인하고자 할 때,
Y축을 편집하려면 도구 선택자를 클릭하고 Edit를 클릭합니다.
Graph Options를 선택하고, 원하는 상태에 그래프가 표시 될 때까지 Y 축 값을 편집합니다. 그 후 Update widget를 클릭하십시오.
편집된 그래프는 다음과 같이 됩니다.
AWS 고객 중에는 대시 보드에서 그래프 이름 변경하기를 원하는 분들이 계셨습니다. 이제 한 번의 클릭으로 이름 변경이 가능하게되었습니다 (그래프 이름 옆에 마우스를 이동시켜 연필 아이콘을 클릭하면됩니다).
Finally, CloudWatch now remembers the time range, timezone preference, refresh interval, and auto-refresh setting for each chart!
Amazon CloudWatch 파트너 소개
마지막으로 AWS 파트너의 우수한 솔루션에 대해 소개합니다. 다음 파트너는 CloudWatch를 기반한 분석 솔루션도 구축하고 있습니다.
- Datadog 인프라 주요 항목과의 통합을 제공하고, 문제 발생 시 직접 고객 팀과 협력 제공
- Librato 인프라 통합을 제공하고 복합 메트릭스와 시계열 데이터 변환 지원
- SignalFx 통계에 따른 즉시성 데이터 제공 및 분석에 집중하고 서비스 규모 알림 가능
- Splunk 머신 데이터의 수집 및 인사이트 탐지를 가능하게하는 운영 인텔리전스 플랫폼 제공
- Sumo Logic 로그 관리 및 시계열 메트릭스 시스템 데이터 분석 서비스 응용 프로그램 구축 및 실행
AWS 파트너로서 CloudWatch를 활용하는 솔루션이 있다면 알려주시면, 업데이트하겠습니다.
— Jeff;
Amazon CloudWatch Events 서울 리전 서비스 개시 – AWS 자원 변경에 대한 실시간 추적 기능
지난 1월에 처음 소개된 Amazon CloudWatch Events 서비스를 오늘 부터 Asia Pacific (Seoul) 리전에서 사용하실 수 있습니다.
본 서비스를 활용하시면, EC2 인스턴스, RDS 인스턴스 및 CloudTrails를 통한 다양한 API 실행 등의 이벤트를 CloudWatch를 통해 스트림 방식으로 실시간으로 얻을 수 있고, 이를 통해 빠르게 대응할 수 있는 기능입니다.
이를 통해 EC2 인스턴스가 종료되었을 때, SNS 토픽을 통해 알림을 받을 수도 있고, EBS 볼륨을 분 단위로 스냅샷을 만들 수도 있습니다.
아래 글은 Amazon CloudWatch Events를 설명한 New CloudWatch Events – Track and Respond to Changes to Your AWS Resources의 한국어 편집본입니다.
AWS에서 실행되는 응용 프로그램에서는 많은 이벤트들이 일어나고 있습니다. 시스템 부하에 따라 자동 스케일링(Auto Scaling) 정책을 통해 EC2 인스턴스 생성 및 제거를 할 수도 있고, DynamoDB 테이블이나 SNS 토픽, SNS 큐가 삭제 될 수 있습니다. 기존 클라우드 자원에 관해 AWS 관리 콘솔, AWS API, AWS Command Line Interface (CLI) 에서 다양하게 각 속성이 변경 될 수 있습니다.
대부분 고객들은 직접 높은 수준의 도구를 개발하여, AWS 자원 환경 전체 상황을 추적 및 감시, 운용하고 있습니다. 그리고 이러한 도구들은 지금까지 폴링(Polling) 형식으로 운영하고 있습니다. 즉, 정기적으로 DescribeInstances
, DescribeVolumes
및 ListQueues
(여기에서는 EC2 인스턴스, EBS 볼륨 및 SQS 큐) 등 AWS 함수를 호출하여 다양한 종류의 AWS 자원 상태를 추적합니다. 각 목록을 얻을 다른 API를 호출해야만, 과거의 데이터와 비교하여 변화를 감지하고 조치를 취할 수 있습니다. 따라서, 시스템이 커지고 복잡한게 될때는 이 부분에 대한 상태 관리가 어려워지게 됩니다.
CloudWatch Events 신규 기능
AWS 자원의 상태 변화를 보다 쉽고 효율적으로 관리할 수 있는 CloudWatch Event를 출시합니다.
CloudWatch Event는 AWS 자원 변경 정보를 바로 스트리밍 방식으로 전달합니다. 간단한 전달 규칙을 몇 분 안에 쉽게 만들 수 있고, 여러 방식으로 이 기능을 연계할 수 있습니다. (AWS Lambda 함수, Amazon Kinesis 스트림, Amazon SNS 등과 연계 가능)
CloudWatch Event는 AWS 환경에서 주요 신경계와 같은 것이라고 생각하시면 됩니다. 각 자원 내 세부적인 환경 변화를 감지하도록 연결되어 있습니다. 특정 규칙에 따라 기능을 수행하여, 상태 확인 후 바로 조치를 취할 수 있도록 메시지를 전달합니다.
현재 대표적인 AWS 서비스에 대응하고 있으며, 추가적으로 나머지 서비스도 지원할 예정입니다.
CloudWatch Events 처리 방식
CloudWatch Events를 이용할 때, 이벤트(Events), 규칙(Rules), 대상(Targets) 등 세 가지 구성 요소에 대해 우선 이해하고 있어야합니다.
이벤트(Events): JSON 형식의 Blob으로 로 반환되는 blob으로 네 가지 방법으로 생성됩니다. 우선 첫 번째로 AWS 환경에서 상태가 변경되었을 때 생성됩니다. 예를 들어 EC2의 상태가 Pending에서 Running으로 변경되거나 AutoScaling 의해 EC2 인스턴스가 새로 만들어졌을 때와 같은 상황입니다. 두 번째는 API를 통해 호출되는 이벤트는 CloudTrial을 통해 CloudWatch Event에 전달됩니다. 세 번째로 여러분이 직접 개발한 코드를 통해 응용 프로그램 수준의 이벤트를 만들어 CloudWatch Event에 전달할 수 있습니다. 마지막으로 스케줄 기반에 일정 간격으로 Cron 형태 이벤트 작성도 가능합니다.
규칙(Rules): 생성된 이벤트와 규칙이 일치하는 경우 대상(Targets)에 대해 처리를 실행합니다. 규칙 적용에 특별히 정해진 순서가 있지 않습니다. 이벤트에 일치하는 모든 규칙이 적용됩니다 (이를 통해 독립적인 이벤트 처리가 가능합니다).
대상(Targets): 규칙을 통해 설정된 이벤트 처리 방식이 원하는 대상에 전달됩니다. 네 가지 타겟 타입을 준비하고 있습니다. 빌트인(Built-in), Lambda 함수, Kinesis 스트림과 SNS 토픽, SQS 큐 우선 해당되지만, 다른 방식 역시 계획 중입니다. (2016년 6월 현재 서울 리전에서는 Lambda 함수는 지원하지 않습니다.) 하나의 규칙에서 여러 대상을 설정할 수 있습니다. 모든 이벤트는 JSON 형식으로 대상에 전달되며 대상에 전달하거나 및 JSON으로 가공 할 수 있습니다. 또한, 이벤트를 그대로 전달할 수 있으며, 특정 Key (Value 값도 함께)를 전달하거나 문자열을 전달할 수 있습니다.
CloudWatch Events 직접 해보기
CloudWatch Events Console에 가서, Create rule을 누르고 이벤트 소스를 선택합니다. (여러 가지 선택 메뉴가 있습니다.)
일부 AWS 서비스는 이벤트를 직접 만들어 상단 메뉴에 표시됩니다. 그 외에는 CloudTrail 로그를 기반으로 작성되는 것도 있기 때문에 서비스는 CoudTrail를 활성화해야합니다. 이제 “EC2 Instances”를 선택하고 관련 규칙을 만듭니다.
위의 규칙은 새로 생성 된 인스턴스가 “running” 되는 것을 감시합니다. 현재 리전 전체 인스턴스에 적용 할 수 있으며, 특정 인스턴스에 적용 할 수 있습니다.
이제 무엇을 할 것인가를 설정합니다. 이번에는 대상을 선택합니다. 여기서는 SNS 토픽을 선택합니다.
규칙에 대해 간단하게 설명을 적고 Create rule을 선택합니다.
이제 설정이 완료되었습니다.
이제 테스트로 EC2 인스턴스 하나를 새로 시작해 보겠습니다. 인스턴스가 시작된 지 바로 SNS 토픽을 통해 메일을 통해 아래와 같이 알림을 받을 수 있습니다.
이벤트 내용에는 새로 시작된 인스턴스 정보 등 다양한 정보를 포함하고 있으며, 이를 통해 DescribeInstances
API 호출로 더 다양한 정보를 얻어 올 수 있습니다.
규칙 실행 주기 설정
앞서 설명드린 대로, 각 이벤트는 Cron 형식으로도 설정할 수 있습니다.
API 접근하기
다른 AWS 서비스 처럼 CloudWatch Events 역시 API를 통해 제공합니다.
PutRule
: 규칙 만들기PutTargets
및RemoveTargets
: 대상 만들기 및 제거하기ListRules
,ListTargetsByRule
및DescribeRule
: 기존 규칙 찾기PutEvents
: CloudWatch Events 만들기. 본 기능을 통해 CLI 기반으로 다양한 애플리케이션을 만들 수 있습니다.
이벤트 통계 보기
CloudWatch Events 역시 CloudWatch에 다양한 통계 수치를 제공합니다. AWS/Events 네임 스페이스를 살펴 보시면, 규칙에 따른 다양한 정보를 얻을 수 있습니다.
아래 수치를 보실 수 있습니다.
- Invocations – 대상이 실행된 횟수
- FailedInvocations – 대상에 대한 실행 실패 횟수
- MatchedEvents – 규칙에 해당되는 실행 횟수
- TriggeredRules – 규칙이 실행된 횟수
각 규칙에 대한 수치는 아래와 같습니다.
- Invocations – 대상에 대해 규칙이 실행된 횟수
- TriggeredRules – 규칙이 직접 실행된 횟수
다른 AWS 서비스 처럼 CloudWatch Events 서비스 역시 기본 기능으로 시작하지만, AWS CloudFormation 지원 및 리전 확대 등 다양한 기능을 제공할 예정입니다. 더 자세한 것은 기술 문서를 참고하시기 바랍니다.