AWS CloudWatch

• Có timestamp
• Có thể tạo dashboard metric
• Metric nằm trong 1 namespace
• Dimension: 1 thuộc tính của metric như instance id, env name…
• Max 30 dimension / metric

EC2 mặc định có các metric 5 phút, trường hợp muốn chi tiết hơn (detailed metric) phải trả thêm tiền

Free Tier cho phép 10 detailed metric

Custom metric

Monitor các thông số không có sẵn trong các metric của AWS, như RAM, disk space, số user đã login

• Sử dụng API PutMetricData
• Có thể thêm dimension khi push
• Resolution
  • Standard (1 minute)
  • High (1/5/10/30s), giá cao hơn
• Có thể put data trong vòng 2 tuần ở quá khứ và 2 tiếng ở tương lai

Anomaly Detection

• Sử dụng ML, phát hiện các bất thường trong metric
• Tạo Alarrm từ các bất thường đó thay vì Static Threshold
• Có thể chỉ định thời gian hoặc event để ignore

Amazon Lookout for Metrics

• Giống Anomaly Detection, phát hiện các điểm bất thường trong metric và xác định vấn đề gốc rễ sảy ra sử dụng ML
• Tự phát hiện và chuẩn đoán lỗi mà không cần thao tác thủ công nào
• Tích hợp cùng các Service của AWS và bên thứ 3 (SaaS, qua AppFlow)

Evidently

• Validate tính năng mới tới một số % user nhất định để test, nếu OK thì release all
• Có thể collect data để phân tích, monitor performance
• Lưu event trong Cloudwatch Logs hoặc S3

• Launches: enable/disable feature cho 1 số user
• Experiments (A/B testing): so sánh các version khác nhau của 1 feature xem version nào tốt hơn
• Overrides: Chỉ định user cụ thể

Log

• Log group: thường đại diện cho 1 application
• Log stream: thường là instance trong 1 application/log file/container

• Có thể define expiration (1d – 10y)
• Có thể send log tới các resource khác như S3 (có thể mất tới 12h), Data Stream, Data Firehose, Lambda, OpenSearch
• Mặc định log được mã hoá bởi KMS, có thể chỉ định key nếu cần

Source

• SDK, CloudWatch Logs Agent, CloudWatch Unified Agent
• Beanstalk
• ECS
• Lambda
• VPC Flow Logs
• API Gateway
• Route53
• …

Log Insight

• Search, analyze log được lưu trong CloudWatch Logs, vd như tìm các action của 1 IP trong log, hoặc tìm các log có level ERROR…
• Có thể query từ nhiều Log group trên nhiều account khác nhau
• Có thể lưu query và add vào Dashboard

Log Subscription

• Realtime xử lý log từ Cloudwatch, send data tới Kinesis Data Stream, Kinesis Data Firehose, or Lambda (max 2 / group)
• Hoặc Subscription Filter để filter các log nào sẽ được gửi tới đích

Log có thể lấy từ các account khác nhau và các region khác nhau, cần config Destination Access Policy hoặc IAM Role để Assume ở account send log

Có thể tạo Metric từ subscription (Metric filter, Max 3 Dimension), usecase như khi xuất hiện ERROR trong log, put metric data tới Cloudwatch Metric, từ Metric tạo Alarm như khi 5 lỗi trong vòng 1 phút, gửi noti tới SNS topic…

Alarm

Có 3 Target chính

• EC2 Action
• EC2 Auto Scaling
• SNS

Có thể call API hoặc từ CLI để test alarm state

Composite Alarms

Kết hợp and/or các Alarm với nhau để tạo ra 1 alarm phức tạp

Synthetics Canary

• Configurable script that monitor your APIs, URLs, Websites, …
• Reproduce what your customers do programmatically to find issues before customers are impacted
• Checks the availability và latency của endpoints, lưu load time, screenshots của UI
• Tích hợp với CloudWatch Alarms
• Viết bằng Node.js or Python
• Giả lập Google Chrome browser
• Có thể run 1 lần hoặc lên lịch

EventBridge

Lên lịch định kỳ hoặc khi có event, trigger action nào đó

• Default Event Bus: Các service của AWS gửi event tới
• Partner Event Bus: các partner của AWS gửi event tới
• Custom Event Bus: tự tạo

• Sử dụng Schema Registry để generate code cho application (schema object của event bus), có version Schema Registry
• Có thể truy cập cross-account nhờ Resource base policy, gắn với Event Bus
• Có thể archive event (all/filter) được gửi tới event bus (set khoảng thời gian hoặc không set)
• Có thể replay các archived event

X-Ray

Debug, troubleshoot application và xem các service trong flow như thế nào

• Visual analyze application
• Debug Performance (bottlenecks)
• Hiểu về dependency trong microservice architecture của application
• Review request behavior
• Tìm lỗi và exception
• SLA đáp ứng được chưa
• Chỗ nào bị thắt nút
• Xác định user bị ảnh hưởng

Các service có thể dùng X-Ray

• Lambda
• Elastic Beanstalk
• ECS
• ELB
• API Gateway
• EC2 Instances server on premise…

Để sử dụng X-Ray, cần làm các việc sau

• Import SDK của X-Ray để capture các request tới aws service, database, queue…
• Cài X-Ray daemon nếu X-Ray chạy trên OnPremise server, các server aws như EC2, Lambda đã có sẵn
• Phải có quyền IAM để write data tới X-Ray

Để sử dụng X-Ray trên Lambda

• IAM Role
• Import X-Ray trong code
• Enable X-Ray Active Tracing

Concept

• Segment: như ID của mỗi application/service
• Subsegment: define trong segment nếu cần chi tiết hơn
• Trace: các segment được collect cùng từ đầu đến cuối
• Sampling: Giảm số lượng request send tới X-Ray để giảm cost
  • Mặc định sẽ ghi lại record request đầu tiên trong 1 giây, sau đó là 5% (rate) của lượng còn lại, VD trong 1s có 100 request thì sẽ có 6 request được record
  • Có thể sửa % (rate) mà không cần update code
• Annotation: Key-Value được sử dụng để index trace và filter
• Metadata: Key-Value, nhưng không index, không search

X-Ray daemon/agent có thể config để gửi trace tới account khác (make sure IAM Role có quyền)

ECS + X-Ray

• EC2 Cluster
  • Setup X-Ray Container cho mỗi EC2 như là Deamon
  • Side Car: Mỗi Container docker sẽ có X-Ray Container riêng, bao nhiêu container app trên 1 EC2 sẽ có bấy nhiêu X-Ray Container
• Fargate Cluster:
  • Side car

Đối với Side Car thì cần link container x-ray daemon với container app, và setting env AWS_XRAY_DAEMON_ADDRESS

AWS Distro for OpenTelemetry

Là bản phân phối của AWS cho project OpenTelemetry, collect, put data tới các service và partner như X-Ray, CloudWatch, Prometheus… Hoạt động trên cả EC2, ECS… và cả OnPremises

Về cơ bản giống X-Ray nhưng là Opensource