Category: Amazon CloudWatch*


AWS Tools for PowerShell을 통한 Amazon CloudWatch 맞춤형 통계 구성 및 저장하기

이 글은 PowerShell용 AWS 도구를 사용하여 Amazon CloudWatch에서 지표 데이터를 작성하고 내보내는 절차를 안내합니다. Amazon CloudWatch 서비스는 로깅, 지표, 차트, 대시보드, 경보, 이벤트 등 주요 영역을 포괄하는 서비스입니다.

우선 CloudWatch 지표 영역, 특히 PowerShell 지표와의 관계를 짚고 넘어가겠습니다. 먼저 CloudWatch에서 지표 데이터를 작성하는 방법을 데모와 함께 살펴본 다음, CloudWatch에서 기존 지표를 찾는 방법을 소개하고, 마지막으로 특정 지표에서 지표 데이터 요소를 검색하는 방법을 알려 드리겠습니다.

Amazon CloudWatch는 최대 15개월 동안 지표 데이터를 저장합니다. 그러나 지표 데이터 보존 요건과 필요한 지표 세부 수준에 따라 Amazon CloudWatch의 데이터를 원하는 장기 보관 도구로 내보낼 수 있습니다. 내보낸 기록 데이터를 CloudWatch에서 사용하지 못할 수도 있지만, 시간이 경과한 이후에 Amazon QuickSight 및 Amazon Athena 등 다른 AWS 데이터 분석 도구를 사용하여 기록 데이터에 대한 보고서를 작성할 수 있습니다.

가정

이 기사에서는 AWS 계정이 있다고 가정합니다. 또한 PowerShell에 대한 기초적인 지식이 있고, PowerShell과 PowerShell용 AWS 도구를 선택한 플랫폼에 설치하고, CloudWatch에 대한 액세스 권한을 부여하는 데 필요한 IAM 정책과 AWS 자격 증명 파일을 이미 설정했다고 가정합니다. PowerShell에서 다양한 CloudWatch API를 호출하는 방법을 논의하고 시연하겠으니 이 주제에 대해 미리 준비하시기 바랍니다.

자세한 내용은 Getting Started guide for AWS Tools for PowerShell을 참조하십시오.

CloudWatch에 지표 데이터 쓰기

먼저 CloudWatch에서 사용자 지정 지표를 저장하는 방법을 살펴보겠습니다.

PowerShell용 AWS 도구에는 다음과 같은 명령이 있습니다. Write-CWMetricData. 이 PowerShell 명령은 궁극적으로 CloudWatch에 지표를 쓰는 PutMetricData API를 호출합니다. 이 명령은 파라미터가 몇 개뿐이므로 매우 쉽게 호출할 수 있습니다. 하지만 이 명령을 사용하기 전에 CloudWatch가 어떻게 작동하는지 알고 있어야 합니다.

  • CloudWatch 지표는 네임스페이스 내에 저장됩니다.
  • 지표 데이터 요소:
    • 이름이 있어야 합니다.
    • 0개 이상의 차원을 포함할 수 있습니다.
    • 값, 타임스탬프 및 측정 단위(예: 바이트, BytesPerSecond, 개수 등)를 포함할 수 있습니다.
    • 사용자 지정 스토리지 분해능(예: 1초, 5초, 60초(기본값) 등)을 지정할 수 있습니다.
  • PowerShell용 AWS 도구에서 하나 이상의 MetricDatum .NET 개체를 생성한 다음 Write-CWMetricData로 전달합니다.

우선 개념 정보는 미루어 두고 사용자 지정 지표를 생성하는 가장 간단한 방법에 대해 살펴보겠습니다. CloudWatch에 지표 데이터 요소를 쓰는 것이 곧 지표를 생성하는 방법입니다. 지표를 생성한 다음 데이터 요소를 지표에 쓰는 것이 별도의 작업이 아닙니다.

### First, we create one or more MetricDatum objects
$Metric = [Amazon.CloudWatch.Model.MetricDatum]::new()
$Metric.MetricName = 'UserCount'
$Metric.Value = 98

### Second, we write the metric data points to a CloudWatch metrics namespace
Write-CWMetricData -MetricData $Metric -Namespace trevortest/tsulli.loc

많은 지표를 추적해야 하는 경우 최상위 지표 네임스페이스가 복잡해지는 것을 방지하려면 지표 차원이 유용합니다. 예를 들어, 100개 이상의 Active Directory 도메인에 대해 “UserCount” 지표를 추적한다고 가정합시다. 모든 지표를 한 네임스페이스에 저장할 수 있지만, 이때 지표마다 “DomainName” 차원을 하나씩 생성해야 합니다. 차원의 값은 각 Active Directory 도메인의 이름입니다. 다음 스크린샷은 진행 중인 이 작업을 보여줍니다.

다음은 차원과 함께 CloudWatch에 지표를 쓰는 방법을 보여주는 PowerShell 코드 예제입니다. 이 문서에서 살펴본 샘플에서는 지표 하나를 작성하는 방법을 보여 주지만, 애플리케이션 코드에서 개별 AWS API를 호출하는 횟수를 줄이고자 노력해야 합니다. 동일한 PutMetricData API 호출에서 여러 지표 데이터 요소를 수집하고 작성하는 절차를 MetricDatum 객체 어레이로 통합해 보십시오. HTTP 연결 횟수와 연결 해제 횟수가 줄어들면 애플리케이션 성능이 향상되며, 그렇게 해도 지표를 원하는 수만큼 수집할 수 있습니다.

$Metric = [Amazon.CloudWatch.Model.MetricDatum]::new()
### Create a metric dimension, and set its name and value
$Dimension = [Amazon.CloudWatch.Model.Dimension]::new()
$Dimension.Name = 'DomainName'
$Dimension.Value = 'awstrevor.loc'

$Metric.MetricName = 'UserCount'
$Metric.Value = 76
### NOTE: Be sure you assign the Dimension object to the Dimensions property of the MetricDatum object
$Metric.Dimensions = $Dimension
Write-CWMetricData -MetricData $Metric -Namespace trevortest

CloudWatch에서 지표 목록 검색

지금까지 CloudWatch에 사용자 지정 지표를 작성했으므로 이제 지표를 검색하는 방법을 살펴보겠습니다. 시간이 지나면 다양한 리전에 걸쳐 AWS 계정에 수천 또는 수만 개의 지표가 생성됩니다. 따라서 분석 프로젝트와 관련한 지표를 찾는 방법을 알고 있어야 합니다.

물론, AWS Management Console을 사용하여 지표 네임스페이스를 보고, 각 네임스페이스에 포함된 지표와 지표 차원을 탐색할 수 있습니다. 이 방법은 초기에 플랫폼을 익히는 데 유용하지만 자동화를 사용하여 플랫폼에서 관련 데이터를 찾을 수 있다면 가장 좋을 것입니다. 자동화는 여러 AWS 리전과 여러 AWS 계정에 걸쳐 지표를 도입하여 그래픽 인터페이스를 통해 지표를 찾기 어려울 때 특히 유용합니다.

PowerShell용 AWS 도구에서 Get-CWMetricList 명령은 AWS ListMetrics API에 매핑됩니다. 이 명령은 CloudWatch에 저장된 지표에 대한 상위 수준의 정보 목록을 반환합니다. 계정에 많은 정보가 저장되어 있는 경우 매우 큰 목록이 반환될 수 있습니다. 고맙게도 PowerShell에는 원하는 지표를 찾는 데 도움이 되는 몇 가지 일반 정렬 및 필터링 명령이 있으며, Get-CWMetricList 명령의 일부 유용한 필터링 파라미터를 사용할 수 있습니다.

이 명령을 사용하는 방법에 대한 몇 가지 사례를 살펴보겠습니다.

가장 간단한 예부터 시작하여 현재 AWS 계정과 리전에서 모든 CloudWatch 지표의 목록을 검색해 보겠습니다.

Get-CWMetricList

이 명령의 결과가 약간 부담스럽게 느껴지더라도 상관 없습니다. -Namespace 파라미터를 사용하여 반환되는 지표를 특정 지표 네임스페이스로 필터링할 수 있습니다.

Get-CWMetricList -Namespace AWS/Lambda

어떤 지표 네임스페이스가 있는지 모른다면 어떻게 됩니까? PowerShell은 고유한 값을 필터링할 수 있는 유용한 명령을 제공합니다.

(Get-CWMetricList).Namespace | Select-Object -Unique

결과가 사전순으로 반환되지 않을 경우 눈으로 검색하기 어려울 수 있으므로 사전순으로 정렬하겠습니다.

(Get-CWMetricList).Namespace | Select-Object -Unique | Sort-Object

훨씬 좋아졌네요! 다른 옵션으로는 차원 키-값 페어를 기준으로 지표를 검색할 수 있습니다. 약간 길어졌지만 수천 개의 지표를 검색하는 데 유용한 구조입니다. 또한 간단한 래퍼 PowerShell 함수를 작성하여 다음 DimensionFilter 객체 중 하나를 쉽게 생성할 수 있습니다.

$Filter = [Amazon.CloudWatch.Model.DimensionFilter]::new()
$Filter.Name = 'DomainName'
$Filter.Value = 'tsulli.loc'
Get-CWMetricList -Dimension $Filter

특정 지표의 이름을 알고 있는 경우 해당 이름과 일치하는 지표 목록을 쿼리할 수 있습니다. 같은 이름을 가진 여러 지표가 있고 다른 차원이 동일한 네임스페이스에 존재할 경우 여러 개의 결과가 반환될 수 있습니다. 또한 차원의 유무에 상관없이 여러 네임스페이스에 유사한 이름을 가진 지표가 존재할 수 있습니다.

Get-CWMetricList -MetricName UserCount

PowerShell에 기본 제공되는 일반 Where-Object 명령은 전체 이름을 정확히 모를 때 지표 또는 네임스페이스를 찾는 데 매우 유용합니다.

이 예에서는 이름에 “User”가 들어가는 지표를 필터링하는 방법을 보여 줍니다.

Get-CWMetricList | Where-Object -FilterScript { $PSItem.Name -match 'User' }

네임스페이스를 기준으로 지표를 필터링하는 것은 매우 쉽습니다. 지표 네임스페이스에 저장된 지표 중 “EBS”로 끝나는 지표를 검색해 보겠습니다.

Get-CWMetricList | Where-Object -FilterScript { $PSItem.Namespace -match 'EBS$' }

이 예는 PowerShell을 사용하여 CloudWatch에서 지표를 찾는 방법을 보여주는 좋은 예입니다. 계속해서 PowerShell을 사용하여 CloudWatch에서 실제 지표 데이터 요소를 가져오는 방법을 알아보겠습니다.

CloudWatch에서 지표 데이터 가져오기

개념

지표 데이터는 CloudWatch에 한정된 시간 동안 저장됩니다. 지표가 CloudWatch에서 만료되기 이전에, 계층화된 시스템에 따라 지표 데이터 요소(“statistics” 지표)를 집계하고 더 큰 범주의 지표 데이터 요소로 저장합니다. 예를 들어, 분 단위로 수집된 지표는 15일이 지난 후 집계하여 5분 지표로 저장합니다. 집계 프로세스와 보관 기간에 대한 자세한 내용은 Amazon CloudWatch 지표 문서를 참조하십시오.

지표 데이터 요소가 3시간이 경과하면 CloudWatch에서 데이터 집계가 시작됩니다(이 문서 작성 시점 기준). 지표 데이터 요소를 가장 세부적인 수준으로 유지하려면 데이터가 만료되기 이전에 지표 데이터를 내보내야 합니다. Amazon EC2 Container Service(ECS)에 배포된 PowerShell 애플리케이션 또는 AWS Lambda와 같은 서비스를 이용하여 이 내보내기 프로세스를 확장 가능한 방식으로 실행할 수 있습니다.

지표가 CloudWatch에 저장되는 최장 기간은 15개월입니다. 지표 데이터를 15개월을 초과하여 저장하려면 CloudWatch에서 지표에 대한 집계를 수행하여 Amazon DynamoDBAmazon S3, Amazon RDS 등과 같은 대체 리포지토리에 저장하기 전에 지표 데이터를 쿼리해야 합니다.

PowerShell 심층 분석

지금까지 CloudWatch 지표를 검색하고 보관하는 몇 가지 개념적 주제에 대해 살펴보았으므로 이제 데이터 요소를 검색하는 실제 PowerShell 명령에 대해 알아보겠습니다.

PowerShell용 AWS 도구에는 Get-CWMetricStatistic명령이 포함되어 있습니다. 이 명령은 AWS의 GetMetricStatistics API에 매핑됩니다. 이 명령을 사용하여 CloudWatch 지표에서 세부 데이터 요소를 검색할 수 있습니다.

대량일 수 있는 데이터 세트를 쿼리할 것이므로 이 명령에서는 몇 가지 파라미터만 지정하겠습니다. 검색하려는 지표 네임스페이스, 이름, 시작 시간, 종료 시간, 기간 및 통계를 매우 구체적으로 지정해야 합니다.

이전 60분에 해당하는 Active Directory UserCount 지표에 대한 지표 데이터 요소를 1분마다 찾아 보겠습니다. 자세히 알아볼 수 있도록 API 응답을 변수에 할당합니다. 여러분은 이 지표가 없을 수도 있지만, 저는 한 동안 이 지표를 수집하여 약 1주 분량의 데이터를 1분 단위로 확보했습니다. 물론, 이 지표는 기본 제공 집계 정책을 준수하므로 이 1분 데이터도 최대 15일 동안만 유효합니다.

$Data = Get-CWMetricStatistic -Namespace ActiveDirectory/tsulli.loc -ExtendedStatistic p0.0 -MetricName UserCount -StartTime ([DateTime]::UtcNow.AddHours(-1)) -EndTime ([DateTime]::UtcNow) -Period 60

보시다시피 명령이 다소 길지만 명령 및 파라미터 이름을 완성할 수 있도록 도와주는 PowerShell의 탭 완성을 사용하면 너무 힘들지 않게 명령을 입력할 수 있습니다.

여기서는 최근 1시간에 해당하는 데이터를 쿼리하고 있으므로 응답에 정확히 60개의 데이터 요소가 있어야 합니다. API 응답의 Datapoints 속성에서 PowerShell의 기본 제공 Count 속성을 검사하여 이를 확인할 수 있습니다.

$Data.Datapoints.Count

데이터 요소가 시간순으로 반환되지 않으므로 PowerShell을 사용하여 데이터 요소를 정렬하고 최신 데이터 요소를 가져오겠습니다.

$Data.Datapoints | Sort-Object -Property Timestamp | Select-Object -Last 1
Average            : 0
ExtendedStatistics : {[p0.0, 19]}
Maximum            : 0
Minimum            : 0
SampleCount        : 0
Sum                : 0
Timestamp          : 10/14/17 4:27:00 PM
Unit               : Count

이제 이 데이터를 가져와서 원하는 외부 스토어로 내보내 장기 보존할 수 있습니다. 이 API에 대한 자세한 내용은 직접 확인해 보시기 바랍니다.

GetMetricStatistics API에서 세부 옵션을 사용할 수 있으므로 문서를 끝까지 읽어보고 API를 직접 시험해 보시기 바랍니다. 앞에서 설명한 대로 데이터 요소를 CloudWatch 지표에서 대체 데이터 원본으로 내보내려면 이 API를 광범위하게 사용해야 합니다.

마무리

이 글에서는 PowerShell용 AWS 도구를 사용하여 Amazon CloudWatch에 지표를 작성하고, 지표를 검색 또는 쿼리하고, 지표 데이터 요소를 검색하는 방법을 살펴보았습니다. Amazon CloudWatch를 다양한 다른 서비스와 통합하여 목표를 달성할 수 있는 방법을 생각해 보실 것을 권장합니다.

지표 데이터를 CloudWatch에 저장한 후 해당 데이터에 대한 대시보드를 작성하고, 인프라 및 애플리케이션 문제에 대해 알려주는 CloudWatch 경보를 연결하고, 자동화된 수정 작업을 수행할 수 있습니다. 한계가 없으므로 빌더의 마음으로 창작 활동을 시작해 보십시오.

이 글은 AWS 개발자 블로그의 Writing and Archiving Custom Metrics using Amazon CloudWatch and AWS Tools for PowerShell 의 한국어 번역으로 AWS 솔루션 아키텍트인 Trevor Sullivan가 작성해 주셨습니다.

 

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 CommandEC2 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 metricsGraph 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개 이상의 플러그인을 지원하고 ApacheNginx 웹 서버 성능, 메모리 사용량, 가동 시간 통계를 수집 할 수 있습니다.

collectd 설치 및 설정
실제 동작을 살펴보기 위해 collectd과 새로운 플러그인을 EC2 인스턴스에 설치하고 구성해 보았습니다.
먼저 CloudWatch에 통계 데이터를 쓸 수 있는 권한을 제공하기 위한 IAM 정책(Policy)을 만듭니다.

이 정책을 활용하여 만들어진 EC2에 접근할 수 있는 IAM 역할(Role)을 만들었습니다.

기존 서버에서 통계를 수집하기 위해 플러그인을 사용하려는 경우, (이미 EC2 인스턴스를 실행하는 경우) 이러한 단계를 진행하지 않고 적절한 접근 권한을 사용하여 IAM 사용자를 생성 합니다.

이제 IAM 정책 및 역할이 준비 되면, EC2 인스턴스를 시작하고 관련 역할을 선택합니다.

로그인 후, collectd를 설치합니다.

Bash
$ sudo yum -y install collectd

플러그인을 설치할 스크립트의 실행 권한을 설정한 뒤 실행합니다.
Then I fetched the plugin and the install script, made the script executable, and ran it:

Bash
$ chmod a+x setup.py
$ sudo ./setup.py

몇 가지 질문에 응답한 후, 문제없이 설정을 수행 할 수 있습니다. collectd 설정 완료 후 시작합니다.

Bash
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에 보내지는 않습니다.

Bash
$ 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를 추가합니다.

Bash
memory--memory-.*

collectd 설정 파일 (/etc/collectd.conf)는 collectd와 플러그인 설정을 포함하고 있습니다. 이번 경우는 변경할 필요는 없습니다.

전체 변경을 사항을 적용하기 위해, collectd를 다시 시작합니다.

Bash
$ sudo service collectd restart

메모리를 사용량을 높이기 위해, 인스턴스를 조금 사용하고 CloudWatch 콘솔을 열어 필요한 부분을 표시했습니다.

위의 스크린샷은 CloudWatch 콘솔에 탑재된 미리 보기 기능에 포함되어 있으므로 자신의 화면에 같은 것이 표시되지 않더라도 놀라지 마세요. (자세한 내용은 향후 알려드립니다).

정식 서비스 중인 인스턴스를 모니터링하는 경우, collected 플러그인을 하나이상 설치할 수 있습니다. Amazon Linux AMI에서 사용할 수 있는 목록은 아래를 참조하십시오.

Bash
$ 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;