기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
로그인 검색 및 분석 CloudWatch
로그와 메트릭을 일관된 형식 및 위치로 캡처한 후에는 문제를 식별하고 해결하는 것 외에도 이를 검색하고 분석하여 운영 효율성을 개선할 수 있습니다. 로그를 보다 쉽게 검색하고 분석할 수 있도록 올바른 형식 (예: JSON) 으로 로그를 캡처하는 것이 좋습니다. 대부분의 워크로드는 네트워크, 컴퓨팅, 스토리지 및 데이터베이스와 같은AWS 리소스 모음을 사용합니다. 가능한 경우 이러한 리소스의 지표와 로그를 종합적으로 분석하고 상호 연관시켜 모든AWS 워크로드를 효과적으로 모니터링하고 관리해야 합니다.
CloudWatch 다양한AWS 리소스에서 CloudWatch 애플리케이션의 메트릭과 로그를 종합적으로 정의하고 모니터링하는 Application Insights, 이상 징후를 드러내는 CloudWatch 이상 탐지 등 로그 및 메트릭을 분석하는 데 도움이 되는 여러 기능을 제공합니다.지표 및CloudWatch CloudWatch Logs Insights를 사용하면 Logs 내 로그 데이터를 대화식으로 검색해 분석할 수 있습니다.
애플리케이션 인사이트를 사용하여 CloudWatch 애플리케이션을 종합적으로 모니터링하고 분석합니다.
애플리케이션 소유자는 Amazon CloudWatch 애플리케이션 인사이트를 사용하여 워크로드에 대한 자동 모니터링 및 분석을 설정할 수 있습니다. 이는 계정의 모든 워크로드에 대해 구성된 표준 시스템 수준 모니터링에 추가로 구성할 수 있습니다. CloudWatch Application Insights를 통해 모니터링을 설정하면 애플리케이션 팀이 사전에 운영에 적응하고 MTTR (평균 복구 시간) 을 줄일 수 있습니다. CloudWatch Application Insights는 애플리케이션 수준의 로깅 및 모니터링을 설정하는 데 필요한 노력을 줄이는 데 도움이 될 수 있습니다. 또한 팀이 로깅 및 모니터링 책임을 분할하는 데 도움이 되는 구성 요소 기반 프레임워크를 제공합니다.
CloudWatch Application Insights는 리소스 그룹을 사용하여 애플리케이션으로서 종합적으로 모니터링해야 하는 리소스를 식별합니다. 리소스 그룹에서 지원되는 리소스는 CloudWatch Application Insights 애플리케이션의 개별적으로 정의된 구성 요소가 됩니다. CloudWatch Application Insights 애플리케이션의 각 구성 요소에는 고유한 로그, 지표 및 경보가 있습니다.
로그의 경우 구성 요소 및 CloudWatch Application Insights 애플리케이션 내에서 사용해야 하는 로그 패턴 세트를 정의합니다. 로그 패턴 집합은 정규 표현식을 기반으로 검색할 로그 패턴 모음으로, 해당 패턴이 탐지된 시점에 대한 심각도가 낮음, 중간 또는 높음으로 표시됩니다. 메트릭의 경우 서비스별 및 지원되는 메트릭 목록에서 각 구성 요소에 대해 모니터링할 메트릭을 선택합니다. 경보의 경우 CloudWatch Application Insights는 모니터링 중인 지표에 대한 표준 또는 이상 탐지 경보를 자동으로 생성하고 구성합니다. CloudWatch Application Insights에는 로그에 설명된 기술과 CloudWatch 설명서의 CloudWatch Application Insights에서 지원하는 메트릭에 대한 메트릭과 로그 캡처에 대한 자동 구성이 있습니다. 다음 다이어그램은 CloudWatch Application Insights 구성 요소와 해당 로깅 및 모니터링 구성 간의 관계를 보여줍니다. 각 구성 요소는 로그와 지표를 사용하여 모니터링할 자체 CloudWatch 로그와 지표를 정의했습니다.
CloudWatch Application Insights에서 모니터링하는 EC2 인스턴스에는 Systems Manager CloudWatch 에이전트 및 권한이 필요합니다. 이에 대한 자세한 내용은 설명서에서 Application Insights를 사용하여 CloudWatch 애플리케이션을 구성하기 위한 사전 요구 사항을 CloudWatch 참조하십시오. CloudWatch Application Insights는 Systems Manager 사용하여 CloudWatch 에이전트를 설치하고 업데이트합니다. CloudWatchApplication Insights에서 구성된 메트릭과 로그는 각 CloudWatch Application Insights 구성 요소의AmazonCloudWatch-ApplicationInsights-SSMParameter 접두사와 함께 Systems Manager 매개 변수에 저장되는 CloudWatch 에이전트 구성 파일을 생성합니다. 그러면 EC2 인스턴스의 CloudWatch 에이전트 구성 디렉터리에 별도의 CloudWatch 에이전트 구성 파일이 추가됩니다. Systems Manager 명령을 실행하여 이 구성을 EC2 인스턴스의 활성 구성에 추가합니다. CloudWatch 애플리케이션 인사이트 사용은 기존 CloudWatch 에이전트 구성 설정에 영향을 주지 않습니다. 자체 시스템 및 CloudWatch 애플리케이션 레벨 CloudWatch 에이전트 구성 외에도 Application Insights를 사용할 수 있습니다. 하지만 구성이 겹치지 않도록 해야 합니다.
로그 인사이트를 사용한 CloudWatch 로그 분석 수행
CloudWatch Logs Insights를 사용하면 간단한 쿼리 언어를 사용하여 여러 로그 그룹을 쉽게 검색할 수 있습니다. 애플리케이션 로그가 JSON 형식으로 구조화된 경우 CloudWatch Logs Insights는 여러 로그 그룹의 로그 스트림에서 JSON 필드를 자동으로 검색합니다. CloudWatch Logs Insights를 사용하여 애플리케이션 및 시스템 로그를 분석하여 future 사용할 수 있도록 쿼리를 저장할 수 있습니다. CloudWatch Logs Insights의 쿼리 구문은 sum (), avg (), count (), min (), max () 등의 함수를 사용한 집계와 같은 함수를 지원하므로 애플리케이션 문제 해결이나 성능 분석에 유용할 수 있습니다.
내장된 CloudWatch 지표 형식을 사용하여 지표를 생성하는 경우 지원되는 집계 함수를 사용하여 내장된 지표 형식 로그를 쿼리하여 일회성 지표를 생성할 수 있습니다. 이를 통해 특정 지표를 사용자 지정 지표로 적극적으로 캡처하는 대신 필요에 따라 특정 지표를 생성하는 데 필요한 데이터 요소를 캡처하여 CloudWatch 모니터링 비용을 줄일 수 있습니다. 이는 카디널리티가 높고 측정항목 수가 많은 차원에 특히 효과적입니다. CloudWatch Container Insights는 또한 이러한 접근 방식을 취하여 상세한 성능 데이터를 캡처하지만 이 데이터의 하위 집합에 대한 CloudWatch 메트릭만 생성합니다.
예를 들어, 다음과 같은 내장된 지표 항목은 내장된 CloudWatch 지표 형식 명령문에 캡처된 지표 데이터에서 제한된 지표 집합만 생성합니다.
{ "AutoScalingGroupName": "eks-e0bab7f4-fa6c-64ba-dbd9-094aee6cf9ba", "CloudWatchMetrics": [ { "Metrics": [ { "Unit": "Count", "Name": "pod_number_of_container_restarts" } ], "Dimensions": [ [ "PodName", "Namespace", "ClusterName" ] ], "Namespace": "ContainerInsights" } ], "ClusterName": "eksdemo", "InstanceId": "i-03b21a16b854aa4ca", "InstanceType": "t3.medium", "Namespace": "amazon-cloudwatch", "NodeName": "ip-172-31-10-211.ec2.internal", "PodName": "cloudwatch-agent", "Sources": [ "cadvisor", "pod", "calculated" ], "Timestamp": "1605111338968", "Type": "Pod", "Version": "0", "pod_cpu_limit": 200, "pod_cpu_request": 200, "pod_cpu_reserved_capacity": 10, "pod_cpu_usage_system": 3.268605094109382, "pod_cpu_usage_total": 8.899539221131045, "pod_cpu_usage_user": 4.160042847048305, "pod_cpu_utilization": 0.44497696105655227, "pod_cpu_utilization_over_pod_limit": 4.4497696105655224, "pod_memory_cache": 4096, "pod_memory_failcnt": 0, "pod_memory_hierarchical_pgfault": 0, "pod_memory_hierarchical_pgmajfault": 0, "pod_memory_limit": 209715200, "pod_memory_mapped_file": 0, "pod_memory_max_usage": 43024384, "pod_memory_pgfault": 0, "pod_memory_pgmajfault": 0, "pod_memory_request": 209715200, "pod_memory_reserved_capacity": 5.148439982463127, "pod_memory_rss": 38481920, "pod_memory_swap": 0, "pod_memory_usage": 42803200, "pod_memory_utilization": 0.6172094650851303, "pod_memory_utilization_over_pod_limit": 11.98828125, "pod_memory_working_set": 25141248, "pod_network_rx_bytes": 3566.4174629544723, "pod_network_rx_dropped": 0, "pod_network_rx_errors": 0, "pod_network_rx_packets": 3.3495665260575094, "pod_network_total_bytes": 4283.442421354973, "pod_network_tx_bytes": 717.0249584005006, "pod_network_tx_dropped": 0, "pod_network_tx_errors": 0, "pod_network_tx_packets": 2.6964010534762948, "pod_number_of_container_restarts": 0, "pod_number_of_containers": 1, "pod_number_of_running_containers": 1, "pod_status": "Running" }
그러나 캡처된 지표를 쿼리하여 추가 통찰력을 얻을 수 있습니다. 예를 들어 다음 쿼리를 실행하여 메모리 페이지 장애가 발생한 최신 포드 20개를 확인할 수 있습니다.
fields @timestamp, @message | filter (pod_memory_pgfault > 0) | sort @timestamp desc | limit 20
아마존 OpenSearch 서비스를 통한 로그 분석 수행
CloudWatch 구독 필터를 사용하여 로그 그룹의 CloudWatch 로그 데이터를 원하는 Amazon OpenSearch OpenSearch Service 클러스터로 스트리밍할 수 있도록 하여 Amazon Service와 통합합니다. 기본 로그 및 지표 캡처 및 분석에 사용한 후 Amazon OpenSearch Service로 확장하여 다음 사용 사례에 사용할 수 있습니다. CloudWatch
-
세분화된 데이터 액세스 제어 — Amazon OpenSearch Service를 사용하면 데이터에 대한 액세스를 필드 수준까지 제한하고 사용자 권한에 따라 필드의 데이터를 익명화할 수 있습니다. 이는 민감한 데이터를 노출하지 않고 문제 해결을 지원하려는 경우에 유용합니다.
-
여러 계정, 지역 및 인프라에 대한 로그 집계 및 검색 — 여러 계정 및 지역의 로그를 공통 Amazon OpenSearch Service 클러스터로 스트리밍할 수 있습니다. 중앙 집중식 운영 팀은 계정 및 지역 전반에서 추세와 문제를 분석하고 분석을 수행할 수 있습니다. Amazon OpenSearch Service로 CloudWatch 로그를 스트리밍하면 중앙 위치에서 다중 지역 애플리케이션을 검색하고 분석하는 데도 도움이 됩니다.
-
ElasticSearch에이전트를 사용하여 Amazon OpenSearch Service로 직접 로그를 전송 및 보강합니다. 애플리케이션 및 기술 스택 구성 요소에서는 CloudWatch 에이전트가 지원하지 않는 OS를 사용할 수 있습니다. 로그 데이터를 로깅 솔루션으로 제공하기 전에 로그 데이터를 보강하고 변환해야 할 수도 있습니다. 아마존 OpenSearch 서비스는 아마존 서비스에 로그 데이터를 전송하기 전에 로그 보강 및 변환을 지원하는 Elastic Beats 제품군 데이터 수집기
및 Logstash와 같은 표준 Elasticsearch 클라이언트를 지원합니다. OpenSearch -
기존 운영 관리 솔루션은 로깅 및 모니터링을 위해 Logstash, Kibana
(ELK) 스택을 사용합니다. 이미 많은 워크로드가 구성되어 있는 Amazon OpenSearch Service 또는 오픈 소스 Elasticsearch에 상당한 투자를 했을 수 있습니다.ElasticSearch Kibana에서 만든 운영 대시보드를 계속 사용하고 싶을 수도 있습니다.
CloudWatch 로그를 사용할 계획이 없다면 Amazon OpenSearch Service 지원 에이전트, 로그 드라이버 및 라이브러리 (예: Fluent Bit, Fluentd, logstash 및 ElasticSearch API용 오픈 배포판
계정, 지역 및 애플리케이션 전반의 로그를 집계하려면 중앙 또는 공유 계정에 ElasticSearch 클러스터를 설정하는 것을 고려해야 합니다. 예를 들어, 중앙 집중식 로깅에 사용되는 Log Archive 계정을AWS Control Tower 설정합니다. 에서AWS Control Tower 새 계정을 생성하면 해당AWS CloudTrail 및AWS Config 로그가 이 중앙 집중식 계정의 S3 버킷으로 전송됩니다. 에서 사용하는AWS Control Tower 로깅은 구성, 변경 및 감사 로깅을 위한 것입니다.
Amazon OpenSearch Service를 사용하여 중앙 집중식 애플리케이션 로그 분석 솔루션을 구축하려면 중앙 집중식 로깅 계정에 하나 이상의 중앙 집중식 Amazon OpenSearch Service 클러스터를 배포하고, 다른 계정의 로그 그룹을 구성하여 중앙 집중식 Amazon OpenSearch Service로 로그를 스트리밍할 수 있습니다.클러스터를 탐색할 수 있습니다.
별도의 Amazon OpenSearch Service 클러스터를 생성하여 계정 전체에 분산될 수 있는 클라우드 아키텍처의 다양한 애플리케이션 또는 계층을 처리할 수 있습니다. 별도의 Amazon OpenSearch Service 클러스터를 사용하면 보안 및 가용성 위험을 줄이는 데 도움이 되며 공통 Amazon OpenSearch Service 클러스터를 사용하면 동일한 클러스터 내에서 데이터를 더 쉽게 검색하고 연결할 수 있습니다.
