AWS 서비스에 대한 지표다.
지표는 모니터링 할 변수이다.
지표는 Timestamps 가 있다.
CloudWatch 사용자 지정 지표를 생성할수 있다.
Cloudwatch 외부로 Streaming 가능하다.
필요한 지표의 subset 만 kinesis data firehose 로 보낼수 있다.
AWS 에서 Application log를 저장할수 있는 완벽한 곳이다.
로그 그룹 (Log groups): 로그 그룹은 동일한 보존 기간, 모니터링 및 액세스 제어 설정을 공유하는 로그 스트림 그룹을 정의합니다. 각 로그 스트림은 하나의 로그 그룹에 속해야 한다. 일반적으로 애플리케이션을 나타내는 임의의 이름이다.
로그 스트림 (Log stream): 로그 스트림은 동일한 소스를 공유하는 로그 이벤트 시퀀스이다. 애플리케이션 내의 인스턴스, 로그 파일, 컨테이너 등을 나타낸다.
로그의 유효 기간을 지정할 수 있으며, 로그를 영원히 유지하거나 30일 등으로 설정할 수 있다.
CloudWatch Logs는 다양한 대상으로 로그를 전송할 수 있다.
Amazon S3 (exports)
Kinesis Data Streams
Kinesis Data Firehose
AWS Lambda
OpenSearch
SDK: SDK를 사용하여 로그를 직접 CloudWatch에 전송할 수 있다.
CloudWatch Logs Agent: EC2 인스턴스에서 실행되는 로그 에이전트를 사용하여 로그를 수집할 수 있다.
CloudWatch Unified Agent: 로그 파일 및 메트릭 데이터를 수집하기 위해 설치된 에이전트. EC2 인스턴스, 온프레미스 서버 및 컨테이너에 사용할 수 있다. (사장되는 추세)
Elastic Beanstalk: 애플리케이션에서 생성되는 로그를 수집할 수 있다.
ECS: 컨테이너화된 애플리케이션에서 생성되는 로그를 수집할 수 있다.
AWS Lambda: Lambda 함수의 로그를 수집할 수 있다.
VPC Flow Logs: 가상 사설 클라우드 (VPC)에서 생성되는 네트워크 흐름 로그를 수집할 수 있다.
API Gateway
CloudTrail based on filter: 지정된 필터에 따라 CloudTrail 이벤트 로그를 수집할 수 있다.
Route 53: DNS 쿼리 로그를 수집할 수 있다.
로그 데이터는 내보내지기까지 최대 12시간이 걸린다.
하지만 실시간 시간으로 걸리는건 아님.
log event 의 실시간 stream 을 얻게 된다.
처리,분석이 가능하다.
Ec2 에서 로그와 지표를 받아서 cloudWatch 에서 표시할수 있는 방법이다.
원래는 Ec2 Instance 로그는 CloudWatch 로 전송되지 않는데 Ec2 에 CloudWatch Log Agent 를 달아서 실행하면 된다.
가상 서버 (EC2 인스턴스, 온프레미스 서버 등) 용
CloudWatch Logs Agent
오래된 버전의 에이전트
CloudWatch Logs로만 전송할 수 있음
CloudWatch Unified Agent
RAM, 프로세스 등과 같은 추가적인 시스템 단계 지표 수집
CloudWatch Logs로 전송할 로그 수집
SSM Parameter Store를 사용하여 중앙 집중식 환경 구성
지표와 로그를 둘 다 사용하기 때문에 통합 에이전트임!
CloudWatch Unified Agent – Metrics
Linux 서버 또는 EC2 인스턴스에서 직접 수집
어떤 지표를 수집?
CPU (active, guest, idle, system, user, steal)
디스크 지표 (free, used, total), 디스크 IO (writes, reads, bytes, iops)
RAM (free, inactive, used, total, cached)
넷 상태(Netstat) (number of TCP and UDP connections, net packets, bytes)
프로세스 (total, dead, bloqued, idle, running, sleep)
스와프 공간(Swap Space) (free, used, used %)
CloudWatch 통합 에이전트가 EC2 인스턴스 모니터링보다 더 세부적이고 많은 지표를 수집한다.
Metric 에서 나오는 Alarm 을 Trigger 하는데 사용한다고 한다.
OK 는 Trigger 되지 않음을 뜻하고
Insufficient_Data 는 정보 부족
Alarm 은 한도 값을 초과 한것을 뜻한다.
Ec2 시작,중지,재시작,복구 가 가능하고
ASG trigger 가능
SNS로 알림 보낼수있다.
Lambda에 연결해서 어떤 알람인지에 따라서 원하는 모든걸 할수있다.
복합 알람이다.
알람 노이즈 줄이기에 유용하다, 복잡한 복합 알람 만들수 있기 떄문이다.
상태확인을 하고 그거에 따라서 Recovery 가 가능하다.
Alarm 은 CloudWatch Logs Metrics Filter에 근거해서 생성이 된다.
이전에 이름은 CloudWatch Events 라고 한다.
이걸로 CRON 작업할수있고
Event Pattern 을 만들어서 특정 작업을 수행하는 서비스에 반응하는 이벤트 규칙또한 만들수있다.
S3에 있는 특정 Bucket의 이벤트만 Filtering 한다.
event 가 어떻게 생겼는지 파악해야한다.
스키마 레지스트리를 사용하면 애플리케이션에서 미리 데이터가 이벤트 버스에 어떻게 구조화되어 있는지 알 수 있는 코드를 생성할 수 있다.
특정 Event Bus 의 권한을 관리할수있다.
예를 들어, 다른 AWS 계정이나 다른 지런에서의 이벤트 수신을 허용 또는 거부할 수 있다.
Container 로 부터 지표를 집계한다,.
Serverless application을 위한 모니터링과 트러블 슈팅 솔루션이다.
데이터를 표현하는 시계열 데이터를 생성하고 로그를 분석하는 서비스이다.
Monitoring 하는 Application의 잠재적인 문제와 진행중인 문제를 분리한다.
CloudWatch Container Insights
ECS, EKS, EC2 상의 Kubernetes, Fargate와 같은 환경에서 사용됨
Kubernetes를 사용한다면 실행할 에이전트가 필요
컨테이너의 지표와 로그를 수집
CloudWatch Lambda Insights
서버리스 애플리케이션의 트러블 슈팅을 위한 세부 지표를 제공
서버리스 애플리케이션의 성능 및 동작을 분석
CloudWatch Contributors Insights
"Top-N" 기고자를 찾는 기능을 제공
로그 데이터에서 가장 많이 기여한 사용자 또는 리소스를 식별
CloudWatch Application Insights
자동화된 대시보드를 제공하여 애플리케이션 및 관련된 AWS 서비스의 문제를 해결하는데 도움을 줌
애플리케이션과 연관된 여러 서비스의 운영 상태를 모니터링하고 문제를 해결할 수 있음
AWS 계정의 거버넌스,컴플라이언스,감시를 제공하는 서비스이다.
AWS 계정 내에서 이루어진 이벤트의 호출 및 API 호출의 이력을 얻을 수 있음
AWS 안에서 일어나는 모든 이벤트와 API 호출 이력을 AWS 서비스로 부터 얻는다.
그리고 CloudWatch Logs or S3 에 Log 를 저장할수 있다.
그래서 만약 AWS 에서 리소스가 삭제 됐을떄는 CloudTrail 을 사용해서 보면 된다고 한다.
AWS 계정 내의 리소스에서 수행되는 작업들을 의미한다.
예시:
보안 구성 (IAM AttachRolePolicy)
데이터 라우팅 규칙 설정 (Amazon EC2 CreateSubnet)
로깅 설정 (AWS CloudTrail CreateTrail)
트레일은 기본적으로 관리 이벤트를 로깅하도록 설정되어 있다.
Read 이벤트(리소스를 수정하지 않는 작업)와 Write 이벤트(리소스를 수정할 수 있는 작업)를 분리할 수 있다.
기본적으로 데이터 이벤트는 로깅되지 않는다 (높은 볼륨의 작업으로 인해).
Amazon S3 객체 수준의 활동 (GetObject, DeleteObject, PutObject 등): Read와 Write 이벤트를 분리할 수 있다.
AWS Lambda 함수 실행 활동 (Invoke API)
계정에서 비정상적인 활동을 감지할 수 있다.
부정확한 리소스 프로비저닝
서비스 한도 도달
AWS IAM 작업의 급격한 증가
주기적인 유지보수 활동의 중단
CloudTrail Insights는 정상적인 관리 이벤트를 분석하여 기준선을 생성한 다음, 지속적으로 쓰기 이벤트를 분석하여 비정상적인 패턴을 감지한다.
이상 상황, 즉 인사이트 이벤트는 CloudTrail 콘솔에 표시된다.
이벤트는 Amazon S3로 전송할 수 있다.
EventBridge 이벤트가 생성되어 자동화 요구에 대응할 수 있다
90일 동안 저장되고 그 이후엔 삭제된다.
그 이상 사용할려면 S3 버킷 사용해서 저장하고 Athena 를 사용해서 분석하며 ㄴ된다고 한다.
Aws 내의 Resource 에 대한 감사와 규정 준수 여부를 기록 할수 있게 해주는 서비스
간에 따른 구성 및 변경 사항 기록을 지원
AWS Config로 해결할 수 있는 문제:
보안 그룹에 무제한 SSH 액세스가 있는지 여부
내 버킷에 공개 액세스가 있는지 여부
시간이 지나면서 ALB 구성이 어떻게 변경되었는지 등
변경 사항에 대한 알림 (SNS 알림)을 받을 수 있다.
AWS Config는 리전별 서비스이기 때문에 모든 리전별로 구성해야 한다.
리전과 계정 간 데이터를 통합할 수 있다.
구성 데이터를 S3에 저장하여 Athena로 분석할 수 있다.
AWS에서 제공하는 사전 정의된 Config 규칙 (75개 이상의 규칙 제공)
AWS Lambda 함수를 사용하여 사용자 지정 규칙을 만들 수 있다.
ex. 각 EBS 디스크가 gp2 규칙인지
ex. 각 EC2 인스턴스가 t2.micro 규칙인지
규칙은 다음과 같은 방식으로 평가 / 트리거될 수 있다.
각 구성 변경 이벤트마다
정기적으로, 혹은 일정 시간 간격으로
AWS Config Rules는 동작을 미리 예방하지는 못하며, 준수 여부를 평가하고 보고하는 역할만 한다. (거부 기능이 없음)
가격:
AWS Config에는 프리 티어가 없다.
리전당 기록된 각 구성 항목 당 $0.003 비용 청구
리전 당 Config 규칙 평가 당 $0.001 비용 청구
규정 준수 시간 여부,리소스 구성,리소스에 대한 API 호출을 시간별로 가능하다 한다.
SSM 자동화 문서를 사용하여 규정을 준수하지 않는 리소스를 수정할 수 있다.
AWS에서 제공하는 관리형 자동화 문서를 사동하거나 사용자 정의 자동화 문서를 생성할 수 있다.
팁: Lambda 함수를 호출하는 사용자 정의 자동화 문서를 생성할 수 있다.
자동 보완 후에도 여전히 규정을 미준수한다면 보완 재시도 (Remediataion Retries)를 설정할 수 있다.
AWS 리소스가 규정을 미준수했을 때마다 EventBridge를 사용하여 알림을 트리거할 수 있다.
구성 변경 및 규정 준수 상태 알림을 SNS로 전송할 수 있다. (모든 이벤트 - SNS 필터링 또는 클라이언트 측에서 필터링)
성능 모니터링 (지표, CPU, 네트워크 등) & 대시보드
이벤트 및 알림
로그 집계 및 분석
모든 사용자에 의해 계정 내에서 수행된 API 호출 기록
특정 리소스에 대한 트레일 정의 가능
글로벌 서비스
구성 변경 기록
규정 준수 규칙에 따라 리소스 평가
변경 내용 및 규정 준수에 대한 타임라인 정보 제공
들어오는 연결 수 모니터링
시간에 따른 오류 코드 비율 시각화
로드 밸런서 성능 파악을 위한 대시보드 생성
API 호출로 로드 밸런서에 대한 변경 사항을 수행한 사용자 추적
로드 밸런서의 보안 그룹 규칙 추적
로드 밸런서의 구성 변경 추적
SSL 인증서가 로드 밸런서에 항상 할당되어 있어야 한다는 규칙을 만들어 암호화되지 않은 트래픽이 로드 밸런서에 접근하지 못하게 할 수 도 있음