AWS CloudWatch

: 모니터링을 위해 로그를 수집하고 로그 파일을 분석한다.

• Amazon CloudWatch는 애플리케이션을 모니터링하고, 시스템 전체의 성능 변화에 대응하고, 리소스 사용률을 최적화하고, 운영 상태에 대한 통합 보기를 얻을 수 있는 모니터링 서비스다. 애플리케이션의 성능과 메트릭을 모니터링하는 데 사용된다.
• CloudWatch 이벤트는 AWS 리소스의 변경 사항을 설명하는 시스템 이벤트 스트림을 제공하지만 "누가" 무엇을 했는지는 나타내지 않는다.

Metrics

: 지표는 이름공간에 속하며 지표의 특성인 배열을 갖는다.

• 지표당 최대 10개의 배열까지 선택할 수 있다.
• 타임스탬프를 가지며 CloudWatch 지표 대시보드를 생성할 수 있다.

Custom Metrics

: PutMetricData라는 API 호출을 사용하여 세그먼트 지표에 배열이나 특성을 추가할 수 있다.

• 사용자 지정 좌표는 푸시하는 방향이 과거든 미래든 상관없다.

Logs

• Log groups: 애플리케이션을 나타낸다.
• Log stream: 애플리케이션 내의 인스턴스 또는 다른 로그 파일 이름, 컨테이너 등을 나타낸다.

Sources

• SDK, CloudWatch Logs Agent, CloudWatch Unified Agent
• Elastic Beanstalk: 애플리케이션에서 CloudWatch로 직접 로그를 수집한다.
• ECS: 컨테이너에서 바로 CloudWatch로 로그를 전송한다.
• AWS Lambda: 함수 자체에서 로그를 전송한다.
• VPC Flow Logs: VPC 메타데이터 네트워크 트래픽과 관련된 로그를 전달한다.
• API Gateway: 들어온 모든 요청을 CloudWatch Logs에 전달한다.
• CloudTrail: 필터를 기반으로 로그를 전송한다.
• Route53: 해당 서비스에 수행된 모든 DNS 쿼리를 로그로 남긴다.

Metric Filter & Insights

Metric Filter

: CloudWatch Logs에서 필터 표현식을 사용하여 로그 내 모든 특정 IP를 찾아낼 수 있다.

Insights

: 로그를 쿼리하고 이 쿼리를 CloudWatch 대시보드에 추가할 수 있다.

CloudWatch Logs for EC2

: EC2 인스턴스에서 CloudWatch로 로그를 전송하기 위해서 CloudWatch Log Agent를 실행해야 한다.

• EC2 인스턴스에 IAM 역할이 있어야 한다.

CloudWatch Logs Agent & Unified Agent

: 모두 온프레미스 서버의 가상 서버 EC2 인스턴스용이다.

• CloudWatch Logs Agent는 이전 버전으로 CloudWatch Logs에 로그를 전송하기만 한다.
• Unified Agent는 최신 버전으로 추가 시스템 수준의 지표를 수집하고 로그 작업도 가능하다. EC2 인스턴스에 대하여 일반적인 모니터링보다 더 자세한 지표를 얻을 수 있다.

CloudWatch Logs Metric Filter

: 필터 표현식을 사용함으로써 로그 내부의 특정 IP를 검색하거나 지표 필터를 사용하여 로그에서 "ERROR"라는 단어가 발생한 횟수를 계산하는 등 고급 작업을 수행할 수 있다.

• 지표 필터는 경보를 트리거 할 때에 사용할 수 있다.

Alarms

: 모든 지표에 대해 알림을 트리거할 때 사용된다.

• OK: 경보가 트리거되지 않은 상태
• INSUFFICIENT_DATA: 데이터가 부족해 경보 상태를 결정할 수 없는 상태
• ALARM: 임곗값을 초과해 알림 전송이 예정된 상태
• set-alarm-state: 특정 임곗값을 초과하지 않은 상황이지만 일부러 경보를 트리거해서 경보 트리거 시 인프라에 올바른 작업이 수행되는지 확인할 때의 CLI 명령어
• 이론상 CloudWatch 경보가 EC2 인스턴스 종료를 트리거하더라도 ASG의 EC2 인스턴스 수는 최소 용량 아래로 내려갈 수 없다.
• 고해상도 매트릭에 알람을 설정하는 경우, 고해상도 알람을 10초 또는 30초로 지정하거나 정기 알람을 60초의 배수로 설정할 수 있다.

Target

= EC2 인스턴스에 중지, 종료, 재부팅, 복구 동작을 수행

• 오토 스케일링 동작을 트리거
• SNS 서비스에 알림을 전송

Composite Alarms

: 서로 다른 여러 경보를 통합하는 작업

EC2 Instance Recovery

• EC2 VM 점검
• 기본 하드웨어 점검

Synthetics Canary

: 스크립트를 정의하면 그 스크립트가 프로그램상에서 고객의 작업을 똑같이 재현한다.

• 일부의 흐름 뿐 아니라 가용성과 지연시간, 로드 시간 데이터, UI 스크린샷도 저장할 수 있다.

Blueprints

• Heartbeat Monitor: URL을 로드하고 스크린샷과 HTTP 아카이브 파일을 저장해 모든게 잘 작동하는지 점검
• API Canary: REST API의 기본 읽기 쓰기 함수를 테스트
• Broken Link Checker: 테스트 중인 URL 내부의 모든 링크를 검사해 잘못된 링크로 연결되지 않게 한다.
• Visual Monitor: Canary 실행 중 찍은 스크린샷을 이전에 찍은 기준 스크린샷과 비교
• Canary Recorder: CloudWatch Synthetics Recorder와 함께 쓰여 웹사이트에서의 동작을 기록하고 그에 대한 스크립트를 자동으로 생성
• GUI Workflow Builder: 로그인 양식등을 갖춘 웹페이지에서 수행한 동작이 올바르게 작동하는지를 검증

Amazon EventBridge

: CloudWatch Events의 차세대 버전으로 CloudWatch Events에 더해서 파트너 이벤트 버스를 통해 소프트웨어 서비스 공급자 또는 다양한 앱에서 이벤트를 받을 수 있다.

Schema Registry

: EvenvBridge에 이벤트가 전송되면 서비스 자체에서 버스 내 이벤트를 분석하고 스키마를 추론한다. 그러면 스키마 레지스트리에서 코드를 생성하고 앱은 코드를 통해 이벤트 버스 내 데이터 구조를 인식한다.

Resource-based Policy

: 리소스 기반 정책을 통해 특정 계정 또는 지역의 이벤트를 수락 또는 거절할 수 있다. 이를 통해 핵심 이벤트 버스로 모든 이벤트를 통합하여 기관이나 다른 지역의 이벤트를 한 곳에 종합할 수 있다.

Amazon EventBridge vs CloudWatch Events
EventBridge는 CloudWatch Events에 기반해 기능을 확장한 차세대 버전으로 백그라운드에서는 같은 서비스 API와 엔드 포인트 그리고 같은 서비스 인프라를 사용한다. 그러나 EventBridge에서는 이벤트 버스를 확장하여 사용자 지정 애플리케이션 또는 타사 SaaS 앱에서도 사용할 수 있고 스키마 레지스트리 기능과 더불어 이벤트 재생, 아카이빙 리소스 기반 정책도 갖고 있다.

Multi-account Aggregation

AWS X-Ray

: 애플리케이션 성능과 오류에 트러블 슈팅을 수행하는 데 지연 시간을 살펴보고 오류를 실시간으로 확인한다.(시각적 분석 제공)

• 애플리케이션에 대한 교차 계정 추적 및 시각화를 제공한다.

advantages

• 애플리케이션 성능 트러블슈팅이 가능하고 병목 현상을 식별화
• 마이크로서비스 아키텍처의 의존관계 파악
• 문제를 일으킨 서비스를 짚어내고 각요청이 어떻게 동작하는지 파악하며, 요청을 바탕으로 오류와 예외도 찾아낼 수 있다.

Leverages Tracing

: 엔드투엔드 방식으로 요청을 추적

• 보안 측면에서 인증에 IAM을 사용하고 미사용 데이터 암호화에는 KMS를 사용할 수 있다.

How to enable it?

1. 코드는 Java, python, Go, Node.js, .NET으로 작성할 수 있고 AWS X-Ray SDK를 임포트해야 한다.
2. X-Ray 데몬 설치 또는 X-Ray AWS 통합 활성화

Troubleshooting

: X-Ray가 EC2에서 작동하지 않으면 IAM 역할에 올바른 권한이 있는지 그리고 EC2 인스턴스가 X-Ray 데몬을 실행 중인지 확인해야 한다.

• AWS Lambda에서 실행하는 경우에는 Lambda에 올바른 정책이 연결된 IAM 실행 역할이 있는지, X-Ray 코드가 임포드됐는지, Lambda에서 X-Ray 활성 추적 옵션을 활성화했는지 확인한다.

Instrumentation in your code

: 코드로부터 X-Ray 서비스에 가는 추적 정보를 얻는다.

Concepts

• Segments
• Subsegments
• Trace
• Sampling
• Annotation: 추적을 인덱싱하고 필터와 함께 사용하기 위해 키-값 쌍 데이터를 추가한다.
• Metadata

  주석은 인덱싱되어 필터와 함께 검색할 수 있지만 메타데이터는 인덱싱되지 않기 때문에 검색에 사용할 수 없다.

Sampling Rules

: 샘플링 규칙으로 X-Ray 서비스와 레코드에 보내는 데이터의 양을 제어할 수 있다.

• X-Ray SDK가 초마다 모든 첫 번째 요청(reservoir)을 기록하고 다음 추가 요청의 5%를 기록한다.

Custom Sampling Rules

: 무엇이 리저버로 무엇이 비율인지 정의할 수 있다.

API

X-Ray Write APIs(used by the X-Ray daemon)

: X-Ray 데몬에서 데이터를 X-Ray 서비스에 쓸 때 사용한다

• PutTraceSegments
• PutTelemetryRecords
• GetSamplingRules
• GetSamplingTargets & GetSamplingStatisticSummaries

X-Ray Read APIs - continued

: 읽기를 위한 관리 정책

• GetServiceGraph
• BatchGetTraces
• GetTraceSummaries
• GetTraceGraph

X-Ray with Elastic Beanstalk

: Beanstalk 플랫폼에는 X-Ray 데몬이 포함돼 있어서 따로 추가할 필요가 없다.

ECS + X-Ray integration options

ECS Cluster

• X-Ray Container as a Deamin: X-Ray 데몬을 실행시키는 방법으로 데몬 자체를 컨테이너로 사용한다.
• X-Ray Container as a "Side Car": X-Ray 데몬이 애플리케이션 컨테이너로 나란히 실행

Fargate Cluster

• X-Ray Container as a "Side Car"

Example Task Definition

• postMappings: 컨테이너 포트는 2000번, 프로토콜은 UDP
• XRAY_DEAMON_ADDRESS: 환경 변수 설정
• 2개의 컨테이너를 네트워킹 관점에서 연결

AWS Distro for OpenTelemetry

: 단일 APi 셋, 라이브러리, 에이전트, 컬렉터 서비스를 사용하여 애플리케이션에서 분산된 트레이스 및 지표를 수집하는 방법

• 오픈 소스

AWS CloudTrail

: API 호출에 대한 내부 모니터링을 수행할 수 있고 사용자가 AWS 리소스를 변경한 내용에 대한 감사를 수행할 수 있다.

• 모든 리전이나 단일 리전에 적용되는 추적을 만들 수 있다.
• AWS CloudTrail을 사용하면 AWS 인프라 전반에서 작업과 관련된 계정 활동을 기록하고 지속적으로 모니터링하고 유지할 수 있다. AWS 계정 활동의 이벤트 기록, AWS Management Console, AWS SDK, AWS CLI를 통해 이루어진 감사 API 호출을 제공. CloudTrail을 사용하여 AWS 계정에서 비정상적인 활동을 감지할 수 있다.

Events

Management Events

: AWS 계정에 있는 리소스에서 수행되는 작업을 의미한다. 기본값으로 추적은 어떤 경우에도 관리 이벤트를 기록하도록 구성한다.

Data Events

: 기본적으로 분리되어 있으며 데이터 이벤트는 로그에 남지 않는다.

CloudTrail Insights Events

: CloudTrail이 이벤트를 분석하고 계정 내 비정상적인 활동을 찾아낸다.

• 이벤트가 올바른 유형인지 계속하여 분석하고 무언가 변경될 때 또는 변경을 시도할 때마다 비정상적인 패턴을 감지한다.

CloudTrail Events Retention

: CloudTrail에 90일 동안 보관하고 장기 보관을 위해 S3 버킷에 기록한다. 분석할 준비가 되면 S3에서 데이터를 쿼리할 때 사용하는 서버리스 서비스인 Athena 서비스를 이용하여 관심 있는 이벤트를 찾아 확인할 수 있다.