CloudWatch

CloudWatch 는 아마존 웹 서비스에서 도는 것들이 보내오는 숫자를 받아 시간 순으로 쌓아 두는 서비스입니다. 값을 긁으러 가지 않고 보내 오는 것만 받습니다. 쌓인 값이 정해 둔 선을 넘으면 알람이 그 사실을 다른 서비스에 넘깁니다.

상세

CloudWatch 가 하는 일은 메트릭과 로그와 트레이스를 모아 쌓아 두는 것입니다. 보내는 쪽은 아마존 웹 서비스, 줄여서 AWS(Amazon Web Services)의 자원과 그 위에서 도는 애플리케이션입니다. 트레이스는 요청 하나가 서비스 여럿을 지나간 흔적입니다. 값을 만든 기계 안에 두면 그 기계가 없어질 때 값도 같이 없어집니다.

값이 들어오는 길은 둘입니다. AWS 서비스가 스스로 보내는 메트릭 하나, 내 애플리케이션이 올리는 커스텀 메트릭 하나입니다.

시간 순으로 늘어놓은 값의 줄 하나가 메트릭입니다. 그 줄에 찍히는 값 하나가 데이터 포인트입니다. 데이터 포인트마다 타임스탬프가 붙습니다. 단위는 붙을 수도 있고 안 붙을 수도 있습니다.

메트릭 하나를 다른 메트릭과 구별하는 것은 이름과 네임스페이스와 차원 조합입니다. 네임스페이스는 메트릭을 담는 통입니다. 기본 네임스페이스가 없습니다. 값을 올릴 때마다 어느 통에 담을지 반드시 지정해야 합니다.

차원은 메트릭에 붙는 이름과 값의 쌍입니다. 메트릭 하나에 최대 30개까지 붙습니다. 이름이 Buffers, 담기는 통이 MyNamespace 인 메트릭이 그런 꼴입니다. 차원은 InstanceId=1-23456789 와 InstanceType=m1.small 둘입니다.

차원이 메트릭의 정체에 들어간다는 점이 뒤의 절을 전부 좌우합니다. 이름과 값의 쌍을 하나 더 붙이면 그 메트릭의 새 변종이 하나 생깁니다. 차원 조합이 다르면 이름이 같아도 서로 다른 메트릭입니다.

flowchart TD
    subgraph NS["네임스페이스 MyNamespace"]
        subgraph M1["메트릭 · Buffers · InstanceId=1-23456789 · InstanceType=m1.small"]
            D1["데이터 포인트 · 타임스탬프 · 값 231434333"]
            D2["데이터 포인트 · 그다음 타임스탬프 · 그때의 값"]
        end
        subgraph M2["메트릭 · Buffers · InstanceId 가 다른 인스턴스"]
            D3["데이터 포인트 · 타임스탬프 · 그 인스턴스의 값"]
        end
    end

같은 이름 Buffers 라도 차원 조합이 다르면 통 안에서 별개의 줄로 갈립니다. 줄 하나하나에 데이터 포인트가 시간 순으로 찍힙니다.

값은 CloudWatch 가 가지러 가지 않습니다. 보내는 쪽이 올립니다. AWS 서비스가 만드는 메트릭은 그 서비스가 알아서 보냅니다. 내가 만든 숫자는 PutMetricData 호출이나 AWS CLI(Command Line Interface, 명령줄 도구)로 올립니다.

반대쪽 설계가 Prometheus 입니다. Prometheus 는 감시할 대상의 주소를 들고 있다가 주기적으로 찾아가 값을 긁어 옵니다. 긁는 쪽이 덤으로 얻는 것은 셋입니다.

밀어 넣는 쪽은 이 셋을 못 얻습니다. 대신 무엇을 치르는지는 다음 절에 있습니다.

메트릭만 있는 서비스는 아닙니다. CloudWatch Logs 가 같은 서비스 안에서 로그를 받습니다. 받은 로그에서 낱말을 찾는 필터나, 로그 안에 메트릭을 끼워 적는 임베디드 로그 포맷으로 메트릭을 뽑아낼 수 있습니다. 뽑아낸 메트릭은 다시 알람이 지켜보는 대상이 됩니다. 애플리케이션 코드는 안 고쳐도 됩니다. 찾는 낱말이 로그에 나타나면 지정해 둔 메트릭에 그 수가 올라갑니다.

flowchart TD
    A["AWS 서비스 — Amazon EC2 · Amazon S3"] -->|스스로 보낸다| M
    B["내 애플리케이션 · AWS CLI"] -->|PutMetricData| M
    L["애플리케이션 로그"] --> LG["CloudWatch Logs"]
    LG -->|메트릭 필터 · 임베디드 로그 포맷| M
    M["메트릭 저장소 — 네임스페이스 · 이름 · 차원"] --> AL["알람"]
    M --> Q["GetMetricData · 대시보드"]
    AL --> S["Amazon SNS · Auto Scaling"]

위쪽이 값을 밀어 넣는 쪽입니다. 아래쪽이 꺼내 쓰는 쪽입니다. 쌓인 값은 GetMetricData 호출로 읽거나 대시보드에 그립니다. 알람이 걸리면 그 사실은 Amazon SNS(Simple Notification Service) 주제나 Auto Scaling 정책으로 넘어갑니다. 로그도 같은 저장소로 흘러들어 메트릭이 됩니다. 그 뒤로는 다른 메트릭과 같은 길을 탑니다.

값을 넣는 규격은 하나가 아닙니다. 전통적인 CloudWatch 메트릭 말고도 OTLP(OpenTelemetry Protocol, 오픈텔레메트리 규약)로 보낸 메트릭을 받습니다. 두 규격은 데이터 모델이 다릅니다. 무엇이 다른지 다섯 줄로 견줍니다.

표에서 처음 나온 말이 셋입니다. 라벨은 OpenTelemetry 의 의미 규약을 따르는 이름과 값의 쌍입니다. 전통 메트릭에서 차원이 하던 일을 이쪽에서는 라벨이 합니다. Metrics Insights 와 PromQL(Prometheus Query Language, 프로메테우스 질의 언어)은 쌓인 메트릭에 질문을 던지는 질의 언어입니다. 롤업은 짧은 주기로 쌓인 값을 긴 주기로 묶어 두는 것입니다.

포기한 것

안 하기로 한 것이 넷입니다. 넷 다 그 대신 얻은 것과 짝입니다.

긁지 않고 받기만 하는 수집

CloudWatch 는 감시 대상의 목록을 들고 찾아다니지 않습니다. 얻은 것은 수집기입니다. 대상마다 긁어 갈 수집 서버를 세우지 않습니다. 그 목록을 관리하는 일도 없습니다. AWS 서비스가 만드는 메트릭은 계정 안에서 그냥 올라옵니다.

치르는 것은 시계열의 생명주기입니다. 같은 이름과 같은 차원 조합을 달고 이어지는 값의 줄이 시계열입니다.

Prometheus 는 긁을 때마다 대상이 응답했는지를 up 이라는 메트릭으로 만들어 남깁니다. 그리고 인스턴스가 사라지면, 일부러 내렸든 아니든, 그 인스턴스의 메트릭도 함께 사라집니다.

Prometheus 에 값을 밀어 넣는 통로인 Pushgateway 를 쓰면 둘 다 없어집니다. up 이 안 생깁니다. 한 번 밀어 넣은 시계열은 손수 지우기 전까지 남습니다. 지우는 길은 Pushgateway 의 API(Application Programming Interface, 프로그램이 다른 프로그램을 부르는 창구)뿐입니다. 여러 인스턴스를 하나의 Pushgateway 로 모으면 그 통로가 단일 장애점이 됩니다. 병목이 될 수도 있습니다. 단일 장애점은 그것 하나가 죽으면 전체가 멈추는 지점입니다.

CloudWatch 쪽은 그 대가를 이렇게 치릅니다. 메트릭은 지울 수 없습니다. 새 값이 안 올라오면 15개월 뒤에 저절로 만료됩니다. 15개월보다 오래된 데이터 포인트는 새 값이 들어오는 대로 뒤에서 빠집니다. 메트릭은 만들어진 리전 안에만 있습니다. 다른 리전에서는 안 보입니다. 리전은 AWS 가 자원을 나눠 두는 지리적 구역입니다.

올린 조합만 물을 수 있는 질의

CloudWatch 는 차원 조합 하나하나를 별개의 메트릭으로 다룹니다. 이름이 같아도 그렇습니다. 그래서 통계를 꺼낼 때 쓸 수 있는 조합은 값을 올릴 때 함께 올린 조합뿐입니다. 차원 둘을 달아 올렸으면 꺼낼 때도 그 둘을 다 대야 합니다. Server=Prod 처럼 조합의 한쪽만으로는 못 묻습니다. 무엇을 물을 수 있는지가 값을 올리는 때에 정해집니다.

얻은 것은 섞이지 않는다는 점입니다. 서로 다른 네임스페이스의 메트릭은 격리되어 있습니다. 다른 애플리케이션의 값이 같은 통계로 잘못 합쳐지지 않습니다.

빠져나갈 길이 둘 있습니다. 여러 메트릭을 식으로 엮는 메트릭 수식이 그 하나입니다. 그중 SEARCH 함수는 여러 메트릭의 통계를 한 번에 가져옵니다. 다른 하나는 AWS 서비스 쪽입니다. Amazon EC2(Elastic Compute Cloud)처럼 일부 AWS 서비스가 만드는 메트릭은 CloudWatch 가 차원을 넘어 집계해 줍니다. 커스텀 메트릭에는 그 집계가 없습니다.

같은 문제를 옆에서는 이렇게 둡니다. Google Cloud Monitoring 도 메트릭 라벨과 자원 라벨의 값 조합마다 시계열을 하나씩 만듭니다. 그 조합의 수를 카디널리티라고 부릅니다. 대신 데이터가 생긴 조합만 시계열로 만듭니다. 빈 시계열은 기록하지 않습니다. 값이 한 번도 안 들어온 메트릭 종류는 목록에 아예 나타나지 않습니다.

메트릭 하나만 보는 알람

알람 하나는 메트릭 하나를 정해진 기간 동안 지켜봅니다. 그 값이 문턱을 넘으면 하나 이상의 동작을 겁니다. 동작은 Amazon SNS 주제로 보내는 알림이거나 Auto Scaling 정책입니다. 메트릭 둘을 함께 보는 조건은 알람 하나로 못 적습니다.

알람은 상태가 이어질 때만 움직입니다. 어떤 상태에 있다는 이유만으로는 동작을 걸지 않습니다. 상태가 바뀐 뒤 지정한 주기 수만큼 유지되어야 합니다. 주기는 데이터 포인트를 묶어 한 점으로 보는 시간 간격입니다. 얻은 것은 한 번 튄 값으로 동작이 걸리지 않는다는 점입니다. 치르는 것은 반응이 그 주기 수만큼 늦는다는 점입니다.

해상도와 조회에 붙는 요금

해상도는 값을 얼마나 촘촘히 찍느냐입니다. 표준 해상도는 1분에 한 점, 고해상도는 1초에 한 점입니다. 값을 더 촘촘히 올리고 더 자주 읽는 일은 그대로 요금이 됩니다. 커스텀 메트릭에 대한 PutMetricData 는 호출마다 요금이 붙습니다. 고해상도 메트릭에 대고 더 자주 부를수록 요금이 올라갈 수 있습니다. 고해상도 메트릭에 거는 고해상도 알람도 요금이 더 높습니다.

얻은 것은 메트릭마다 따로 고를 수 있다는 점입니다. 어느 메트릭을 1초 간격으로 보고 어느 메트릭을 1분 간격으로 볼지를 하나씩 정합니다.

옆에서는 요금을 다르게 매깁니다. Azure Monitor 의 플랫폼 메트릭은 Azure 자원에서 설정 없이 수집됩니다. 비용이 없습니다. 보존은 몇 가지 예외를 빼면 플랫폼 메트릭과 커스텀 메트릭 모두 93일입니다.

예시

실물 둘입니다. 값을 올리는 명령 한 줄과, 올린 조합이 그대로 물을 수 있는 범위가 되는 표입니다.

값 하나를 올리는 명령

aws cloudwatch put-metric-data \
  --metric-name Buffers \
  --namespace MyNamespace \
  --unit Bytes \
  --value 231434333 \
  --dimensions InstanceId=1-23456789,InstanceType=m1.small

메트릭 이름은 Buffers, 담기는 네임스페이스는 MyNamespace, 단위는 바이트, 값은 231434333 입니다. 차원은 InstanceId 와 InstanceType 둘입니다. 이 두 쌍까지가 이 메트릭의 정체입니다. 같은 Buffers 라도 InstanceId 값이 다르면 다른 메트릭이 됩니다.

차원을 여럿 가진 메트릭은 꺼낼 때도 전부 대야 합니다. Amazon S3(Simple Storage Service)의 BucketSizeBytes 메트릭이 그렇습니다. 차원이 BucketName 과 StorageType 둘입니다. get-metric-statistics 로 읽을 때 두 차원을 다 지정해야 합니다.

네 조합으로 올린 ServerStats

네임스페이스 DataCenterMetric 에 ServerStats 라는 이름으로 데이터 포인트 넷을 올린 예입니다.

이 넷을 올렸으면 통계를 꺼낼 수 있는 조합도 이 넷입니다. Server=Prod 하나만으로는 못 묻습니다. Domain=Frankfurt 하나만으로도, 차원을 아예 안 대고도 못 묻습니다. 프랑크푸르트 전체를 보고 싶었다면 그 조합을 올릴 때 함께 올렸어야 합니다.

사용처

밖에서 이 저장소를 읽어 가는 제품이 Grafana 입니다. Grafana 의 CloudWatch 데이터 소스는 쌓인 메트릭과 로그를 질의해 대시보드에 그립니다.

고른 까닭은 나란히 놓기입니다. 다른 시스템에서 온 값과 CloudWatch 의 값을 한 대시보드에 함께 올려 견줄 수 있습니다. 메트릭과 로그, 알림은 지원합니다. 트레이스는 지원하지 않습니다.

읽는 쪽이 무엇을 치르는지가 이 데이터 소스에 드러납니다. 메트릭 목록과 값을 가져오려고 ListMetrics 와 GetMetricData 를 부릅니다. 질의 편집기에서 차원을 고를 때마다 ListMetrics 요청이 한 번 나갑니다. 질의를 바꿀 때마다 GetMetricData 요청이 새로 나갑니다. GetMetricData 요청은 CloudWatch API 무료 티어에 들지 않습니다.

할당량은 계정마다 따로 걸립니다. 리전마다도 따로 걸립니다. 여러 리전을 쓰거나 데이터 소스를 여럿 두고 여러 계정에 질의하면, 한도에 닿는 계정과 리전마다 따로 증액을 신청해야 합니다.

운영

굴릴 때 걸리는 것은 숫자로 못 박혀 있습니다. 해상도와 주기, 보존, 타임스탬프, 호출 상한, 요금 순입니다.

해상도와 주기

메트릭은 표준 해상도와 고해상도 둘 중 하나입니다. 표준 해상도는 1분 단위, 고해상도는 1초 단위입니다. AWS 서비스가 만드는 메트릭은 기본이 표준 해상도입니다.

주기는 데이터 포인트를 묶어 한 점으로 보는 시간 간격입니다. 초 단위로 정합니다. 쓸 수 있는 값은 1 · 5 · 10 · 30 또는 60의 배수입니다. 기본값은 60초입니다. 알람을 만들 때는 메트릭 해상도보다 크거나 같은 주기를 고릅니다. 고해상도 메트릭에는 10초나 30초 주기의 고해상도 알람을 걸 수 있습니다. 60의 배수 주기로 보통 알람을 걸 수도 있습니다.

타임스탬프는 1000분의 1초까지 적을 수 있습니다. 다만 CloudWatch 는 최소 1초 단위로 모아 둡니다.

보존과 롤업

얼마나 남는지는 데이터 포인트의 주기가 정합니다.

짧은 주기로 올린 값은 오래 보관하려고 함께 묶입니다. 이렇게 묶는 것이 롤업입니다. 1분 주기로 모은 값은 15일 동안 1분 해상도로 남습니다. 15일이 지나도 값이 사라지지는 않습니다. 다만 5분 해상도로만 꺼낼 수 있습니다. 63일이 지나면 다시 묶여 1시간 해상도가 됩니다.

타임스탬프와 반영 지연

타임스탬프는 과거로 2주, 미래로 2시간까지 받습니다. 지금 협정 세계시와 다른 타임스탬프로 커스텀 메트릭을 보내면 알람이 INSUFFICIENT DATA 로 보이거나 늦게 울릴 수 있습니다.

메트릭을 새로 만들면 get-metric-statistics 로 통계를 꺼낼 수 있기까지 최대 2분이 걸립니다. list-metrics 가 주는 메트릭 목록에 뜨기까지는 최대 15분이 걸립니다. 방금 올린 메트릭이 목록에 안 보인다고 안 올라간 것은 아닙니다.

호출 상한

상한은 리전마다 따로 걸립니다. 자주 부딪히는 것 셋입니다.

앞의 둘은 초당 부를 수 있는 횟수입니다. 마지막은 만들어 둘 수 있는 개수입니다.

요금과 무료 티어

요금은 리전과 시점에 따라 바뀝니다. 적어 두는 것은 어디에 요금이 붙느냐입니다.

이 단가가 얼마로 불어나는지는 계산 예 하나로 드러납니다. 인스턴스 다섯 대에 1분 해상도로 값을 주는 상세 모니터링을 켜고 30일을 돌리면 메트릭은 인스턴스당 7개씩 35개가 됩니다. 커스텀 메트릭 한 개에 0.30달러가 붙는 구간이면 한 달에 10.50달러입니다. 메트릭이 1만 개를 넘으면 그때부터 구간별 요금이 적용됩니다. 메트릭 100개를 분석하는 질의는 0.001달러입니다.

공짜로 주는 몫인 무료 티어도 개수로 정해져 있습니다. 대시보드는 한 달에 3개까지, 대시보드마다 메트릭 50개까지입니다. 자동으로 만들어지는 대시보드는 전부 무료입니다. 알람은 표준 해상도 알람 10개까지입니다. 메트릭을 직접 나열하고 Metrics Insights 질의를 쓰지 않는 알람만 셉니다.

로그 쪽 기본값

로그는 기본값이 메트릭과 다릅니다. 로그는 기본으로 무기한 보관됩니다. 만료되지 않습니다. 로그 그룹마다 보존 정책을 하루에서 10년 사이로 바꿀 수 있습니다. 무기한으로 두는 선택도 그대로 남습니다.

관련 항목

메트릭 하나를 유일하게 만드는 구성 요소

네임스페이스 · 차원 · 데이터 포인트 · 타임스탬프 · 시계열 · 카디널리티

값을 올리고 꺼내는 API 호출

PutMetricData · GetMetricData · GetMetricStatistics · ListMetrics · Metrics Insights · AWS CLI

알람이 동작을 넘기는 대상 서비스

알람 · Amazon SNS · Auto Scaling

같은 서비스 안에 붙어 있는 로그 쪽 부품

CloudWatch Logs · 로그 그룹 · Logs Insights · 메트릭 필터 · EMF

메트릭을 스스로 올리는 AWS 서비스

AWS · Amazon EC2 · Amazon S3

옆에서 같은 값을 다루는 감시·시각화 제품

Prometheus · Pushgateway · Grafana · Grafana Loki · OpenSearch · Cloud Monitoring · Azure Monitor · Cloud Logging · 대시보드

벤더에 안 매인 수집 규격

OpenTelemetry · OTLP · PromQL

이것이 속하는 상위 분류

모니터링 · 관측성 · 메트릭 · 알림