Amazon CloudWatch
- CloudWatch 지표(Metrics)
- AWS의 모든 서비스에 대한 지표 제공
- 지표는 namespaces에 속하므로 각기 다른 이름 공간에 저장된다.
서비스당 이름공간은 하나
- 측정 기준은 지표의 속성
CPU 사용률 지표는 인스턴스의 id, 환경등과 관련됨
- 지표당 최대 측정 기준은 30개
- 지표는 시간을 기반으로 하기 때문에 타임 스탬프가 꼭 있어야 한다.
- 대시보드 기능
- 사용자 지정 지표 생성 가능 (ex: 램 사용량) - CloudWatch 메트릭 스트리밍
- 외부로 CloudWatch 스트리밍 가능
거의 실시간으로 전송되고, 지연 시간이 짧아진다.
대상: Kinesis Data Firehose을 통해 원하는 곳으로 전송 가능
서드파티: Datadog, Dynatrace, New Relic, Splunkm, Sumo Logic 등 으로 전송 가능
CloudWatch Logs
- CloudWatch Logs: AWS에서 애플리케이션 로그를 저장할 수 있는 곳
- 사용 방법
- 로그 그룹 정의
- 로그 그룹 안에 다수의 로그 스트림: 애플리케이션 안의 로그 인스턴스나 로그 파일, 컨테이너등을 나타냄
- 로그 만료 정책을 정의: 영구보관, 1일~10년까지 만료 설정 가능
- CloudWatch Logs를 다양한 대상으로 전송 가능
ex) 배치 형태로 S3에서 내보내기,
또는 그걸 Kinesis Data Streams, Kinesis Data Firehose, AWS Lambda, OpenSearch에 스트리밍 가능
- 로그는 기본적으로 암호화되어 있다.
원한다면 자신의 키를 사용해 자체적인 KMS 기반 암호화 설정 가능 - CloudWatch Logs- 데이터 소스
- SDK, CloudWatch Logs Agent, CloueWatch Unified Agent를 사용해 로그 전송
현재 CloudWatch Unified Agent가 로그를 CloudWatch에 전송
CloudWatch Logs Agent는 도태중
- Elastic Beanstalk을 사용해 애플리케이션에서 로그를 수집하고 직접 CloudWatch로 전송
- ECS는 로그를 컨테이너에서 CloudWatch로 바로 전송
- Lambda 자체에서 로그를 전송
- VPC Flow Logs는 VPC 메타데이터네트워크 트래픽의 특정한 로그를 전송
- API Gateway는 API Gateway로 오는 모든 요청을 CloudWatch Logs로 보냄
- CloudTrail based on filter: 직접 필터에 기반한 로그를 전송
- Route 53은 서비스에 대한 모든 DNS 쿼리를 로깅 - CloudWatch Logs Insights
로그를 쿼리하기 위해 CloudWatch Logs Insights를 이용
- CloudWatch Logs안에서 로그 데이터를 검색하고 분석
- CloudWatch Logs Insights 콘솔의 일부로서 많은 샘플 쿼리가 제공되어 있다.
ex) 25개의 최신 이벤트를 검색, 얼마나 많은 이벤트에 예외나 오류가 있는가를 로그에서 확인
, 특정한 IP를 검색 등등..
- 특별한 목적으로 제작된 쿼리 언어 제공
쿼리를 제작하도록 해주는 모든 필드를 자동으로 CloudWatch Logs가 자동으로 탐지
그러면 조건을 기준으로 필터링할 수 있다.
또 집계 통계를 계산하고 이벤트를 정렬하거나 이벤트 개수를 제한하는 등의 작업 가능
쿼리를 저장하고 CloudWatch 대시보드에 추가 가능
- 다른 계정에 있어도 한 번에 다수의 고르 그룹을 쿼리할 수 있다.
- CloudWatch Logs Insights는 실시간 엔진이 아닌 쿼리 엔진이다.
과거 데이터만 쿼리한다. - CloudWatch Logs - S3 Export
- 모든 로그를 S3로 전송하는 배치 내보내기에 사용
- 로그 데이터가 생성되는 데 최장 12시간까지 걸릴 수 있다.
- 내보내기를 시작하기 위한 API 호출을 CreateExportTask라고 부른다.
- 배치 내보내기이기 때문에 실시간이나 근 실시간이 아님. - CloudWatch Logs Subscriptions
- 로그 이벤트들의 실시간 스트림을 얻을 수 있고, 그걸 처리하고 분석할 수 있다.
- Kinesis Data Streams, Kinesis Data Firehose, Lambda 등의 다양한 곳에 전송 가능
- Subscription Filter를 써서 전송 대상으로 전달하려는 로그 이벤트 종류를 지정할 수 있다.
- 즉, Subscription Filter는 데이터를 Kinesis Data Streams에 전송할 수 있다.
예를 들어 Kinesis Data Firehose, Kinesis Data Analytices, EC2, Lambda와의 통합을 이용하려고 할 경우 사용하기 좋다.
또 직접적으로 데이터를 Kinesis Data Firehose로 전송할 수 있다. 그럼 거기서 근 실시간으로 S3나 OpenSearch 서비스에 전송 할 수 있다.
또는 Lambda를 작성하거나 실시간으로 OpenSearch서비스로 데이터를 전송하는 관리형 람다 함수를 사용할 수 있다.- CloueWatch Logs Aggregation Multi-Account & Multi Region
- Subscription Filter 덕분에 다양한 계정과 리전에서 온 CloudWatch Logs 데이터를 하나의 특정 계정에서 Kinesis Data STreams 등에 집계할 수 있다.
- 그리고 그걸 Kinesis Data Firehose로 보내고 다시 근 실시간으로 S3로 보내게 된다. - CloudWatch Logs Subscriptions 작동 방식
- 반드시 전송 대상을 사용해야 한다.
- 발신자 계정과 수신자 계정이 있다면 CloudWatch Logs Subscription Filter를 만든다.
- 그게 수신자 계정에서 Kinesis Data Stream을 가상으로 표시하는 Subscription Destination으로 전송된다.
- 그리고 전송 대상 액세스 정책을 첨부해 첫 번째 계정이 실제로 데이터를 전송 대상에 전송하도록 허용한다.
- 그리고 수신자 계정에서 레코드를 Kinesis Data Stream에 전송할 권한을 가진 IAM 역할을 생성
- 그리고 이 역할을 첫 번째 계정이 맡을 수 있는지 확인- 이런 게 모두 설정되면 CloudWatch Logs에서 나온 데이터를 한 계정에서 다른 계정의 전송 대상으로 전송할 수 있다.
- CloueWatch Logs Aggregation Multi-Account & Multi Region
CloudWatchLogs - LiveTail
- CloudWatchLogs로 이벤트가 올라오면서 Live Tail에 나타남
디버깅할때 유용
- 하루의 1시간은 무료
- 비용이 부과되지 않게 세션을 꼭 닫자.
CloudWatch Logs Agent
CloudWatch 에이전트를 이용해 EC2에서 로그와 지표를 받아 CloudWatch에서 표시가 가능하다.
- EC2에서 CloudWatch로는 기본적으로 로그를 보내지 않는다.
- 로그를 보내기 위해서는 에이전트를 실행해 로그를 푸시해야한다.
- IAM역할을 EC2에 부여해 로그를 보낼 수 있도록 해줘야 한다.
- 이 에이전트는 온프레미스 환경에서도 셋업될 수 있다.
ex) VMWare같은 가상서버에서 온프레미스 환경으로 서비스를 제공할 수 있다. - 같은 에이전트를 설치하면 CloudWatch Logs로 로그를 보낼 수도 있다.
2개의 Agent
- CloudWatch Logs Agent(과거)
- CloudWatch Logs로 로그만 보냄 - Unified CloudWatch Agent(최근)
- 프로세스나 RAM 같은 추가적인 시스템 단계 지표를 수집
- CloudWatch Logs로 로그를 보냄
- SSM Parameter Store를 이용해 에이전트를 쉽게 구성할 수 있다.
모든 통합 에이전트를 대상으로 중앙 집중식 환경 구성을 할 수 있다.
CloudWatch Unified Agent - Metrics
- 에이전트를 EC2 인스턴스나 Linux서버에 설치하면 더 세분화된 수준의 지표를 가져올 수 있다.
- CPU 메트릭
- active, guest, idle, system, user, steal 등.. - Disk 메트릭
- free, use, total
- writes, reads, bytes, iops - RAM 메트릭
- free, inactive, used, total, cached - Netstat
- TCP/UDP연결, 패킷, bytes - Processes
- total, dead, bloqued, idle, running, sleep - Swap Space
- free, used, used %
- CPU 메트릭
- EC2에서 디스크,CPU 스왑, 메모리가 아닌 네트워크에 대한 지표를 얻을 수 있긴 하지만 상당히 포괄적인 지표만 얻을 수 있다.
- 세부 지표를 얻고 싶다면 통합 CloudWatch 에이전트를 이용하자.
CloudWatch Alarms
- 메트릭에서 나오는 알림을 트리거 하는데 사용
- 샘플링, %, 최대, 최소 등등 다양한 옵션으로 복잡한 알람을 정의 - 알람 상태
- OK: 알람 트리거 X
- INSUFFICIENT_DATA: 충분한 데이터가 없음
- ALARM: 값을 초과해 알람이 트리거 O - 기간(Period)
- 알람이 얼마나 오랫동안 메트릭을 평가할지를 나타냄.
- 10초, 30초, 등등 설정
CloudWatch Alarm Tergets
- EC2에 대한 액션(종료,재부팅,정지,복구)
- 오토 스케일링 트리거(Scali in/out)
- SNS: 람다와 연결해 어떤 알람인지에 따라 원하는 동작 수행
CloudWatch Alarm - 복합 알람
- CloudWatch Alarms는 하나의 메트릭에 적용된다.
- 다수의 메트릭을 사용하고 싶으면 복합 알람을 사용
- 이는 다수의 다른 알람들의 상태를 모니터링하고, 각각 하나의 다른 메트릭에 의존할 수 있다.
즉, 모든 알람들을 결합하는 것
그리고 AND, OR 조건을 사용해 유영하게 다룰 수 있다. - 복합 알람은 '알람 노이즈'를 줄이는 데 유용하다.
ex: CPU가 High이고 네트워크가 Low일 때만 알림을 울려라.
CPU-High, NET-High -> alarm X
CPU-High, NET-Low -> alarm O
EC2 인스턴스 복구
- 상태 검사
- 인스턴스 상태 = EC2 VM 검사
- 시스템 상태 = 기본 하드웨어를 검사
- 위 두 가지 검사에 CloudWatch Alarm을 정의할 수 있다.
- 그럼 특정한 EC2 인스턴스를 모니터링하게 되고 만일 알림이 발생하면 EC2를 복구를 시작해 EC2 인스턴스를 한 호스트에서 다른 호스트로 옮길 수 있다.
- 복구를 할때는 인스턴스에 대해 동일한 프라이빗 IP, 퍼블릭 IP, 탄력적 IP를 얻게 되고, 동일한 메타데이터 동일한 배치 그룹을 얻게 된다.
- 또 알람을 SNS 토픽에 전송해 EC2 인스턴스가 복구되었다는 걸 알 수 있다.
CloudWatch Alarm에 대해 알아두면 좋은 점
- CloudWatch Logs 메트릭 필터를 기초로 알람을 생성할 수 있다.
ex: error 같은 단어를 너무 많이 받은 경우 경보를 발생해 메시지를 SNS에 전송
- 알람 알림을 테스트하고 싶으면 set-alarm-state라는 CLI 호출을 사용할 수 있다.
특정 한도 값에 도달하지 않아도 알람을 트리거할때 유용$ aws cloudwatch set-alarm-state
--alarm-name
--alarm-value // ALARM, OK ...
--state-reason "Testing"
CloudWatch Container Insights
- 컨테이너로부터 지표와 로그를 수집,집계,요약하는 서비스
- ECS(Elastic Container Service)
- EKS(Elastic Kubernetes Service)
- EC2의 쿠버네티스 플랫폼에 직접 실행하는 컨테이너
- ECS와 EKS의 Fargate에 배포된 컨테이너
- CloudWatch Container Insights를 사용하면 컨테이너로부터 지표와 로그를 쉽게 추출해 CloudWatch에 세분화된 대시보드를 만들 수 있다.
- CloudWatch Container Insights를 EKS나 EC2에서 실행되는 Kubernetes에서 사용할 경우 컨테이너화된 버전의 CloudWatch 에이전트를 사용해야 컨테이너를 찾을 수 있다.
CloudWatch Lambda Insights
- Lambda에서 실행되는 서버리스 애플리케이션을 위한 모니터링과 트러블 슈팅 솔루션
- CPU 시간, 메모리, 디스크, 네트워크, 콜드 스타트, Lambda 작업자 종료 등의 정보와 시스템 수준의 지표를 수집,집계,요약 한다.
- Lambda 함수를 위해 Lambda 계층으로 제공된다.
Lambda 함수 옆에서 실행되고 Lambda Insights라는 대시보드를 생성해 Lambda 함수의 성능을 모니터링한다. - 이 서비스는 Lambda에서 실행되는 서버리스 애플리케이션의 세부 모니터링이 필요할 때 사용한다.
CloudWatch Contributor Insights
- 기고자(원고) 데이터를 표시하는 시계열 데이터를 생성하고, 로그를 분석하는 서비스
ex) 상위 N개의 기고자나 총 고유 기고자 수 및 사용량을 볼 수 있다. - 이 서비스는 네트워크의 상위 대화자를 찾고, 시스템 성능에 영향을 미치는 대상을 파악할 수 있다.
VPC 로그, DNS 로그 등 AWS가 생성한 모든 로그에서 작동한다.
ex) 불량 호스트를 식별해 낼 수 있다.
- 네트워크 로그나 VPC 로그를 확인해 사용량이 가장 많은 네틍퉈크 사용자를 찾을 수 있다.
- 모든 네트워크 요청에 대해 VPC 내에서 생성되는 로그인 VPC 플로우 로그가 CloudWatch Logs로 전달되고, VPC 플로우 로그가 CloudWatch Logs로 전달되고 CloudWatch Contributor Insights가 분석한다.
- 이를 통해 VPC에 트래픽을 생성하는 상위 10개의 IP 주소를 찾고, 좋은 사용자인지 나쁜 사용자인지 판단한다.
- 상위 10개의 기고자 또는 비슷한 걸 본다면 Contributor Insights이다. - DNS 로그에서는 오류를 가장 많이 생성하는 URL을 찾을 수 있다.
- 규칙은 직접 생성하거나 AWS가 생성한 간단한 규칙을 활용할 수 있다.
- 백그라운드에서는 CloudWatch Logs가 활용된다.
- 내장된 규칙이 있어 다른 AWS 서비스에서 가져온 지표도 분석할 수 있다.
CloudWatch Application Insights
- 모니터링하는 애플리케이션의 잠재적인 문제와 진행 중인 문제를 분리할 수 있도록 자동화된 대시보드를 제공
- Java, .NET, IIS 웹 서버나, 특정 데이터베이스를 선택해 선택한 기술로만 애플리케이션을 실행할 수 있다.
- EBS, RDC, ELB, ASG, Lambda, SQS, DynamoDB, S3과 같은 AWS 리소스에 연결된다.
+ ECS, EKS, SNS, API Gateway, ... - 애플리케이션에 문제가 있는 경우 CloudWatch Application Insights는 자동으로 대시보드를 생성해 서비스의 잠재적인 문제를 보여 준다.
- 자동화된 대시보드를 생성할 때 백그라운드에서는 내부에서 SageMaker 머신 러닝 서비스가 사용된다.
- 애플리케이션 상태 가시성을 더 높여 트러블 슈팅이나 애플리케이션을 보수하는 시간을 줄일 수 있다.
- 즉, AWS의 다른 리소스나 서비스를 사용하는 애플리케이션에 문제가 발생하면 자동으로 CloudWatch Applications Insights 대시보드에 표시함.
- 발견된 문제와 알림은 모두 EventBridge와 SSM OpsCenter로 전달 된다.
요약
- CloudWatch Container Insights
- ECS, EKS, EC2의 kubernetes, Fargate 로부터 오는 로그와 지표를 위한 것.
- kubernetes를 사용한다면 실행할 에이전트가 필요
- CloudWatch Lambda Insights
- Lambda에서 실행되는 서버리스 애플리케이션의 트러블 슈팅을 위한 세부 지표를 제공
- CloudWatch Contributors Insights
- CloudWatch Logs를 통해 상위 N개의 기고자를 찾는다.
- CloudWathch Application Insights
- 자동화된 대시보드를 생성해 사용하는 애플리케이션과 관련된 AWS 서비스나 애플리케이션의 트러블 슈팅을 돕는다.
