모든 AWS 서비스는 처리 과정을 CloudWatch 로그 그룹 아래에 정리된 파일에 기록합니다. 로그 그룹은 일반적으로 쉽게 식별할 수 있도록 서비스 자체의 이름을 따서 명명됩니다. 서비스의 시스템 메시지 또는 공통 상태 정보는 기본적으로 해당 로그 파일에 기록됩니다.
그러나 기본 로그 메시지 위에 사용자 지정 로그 메시지 정보를 추가할 수 있습니다. 이러한 로그를 현명하게 생성하면 유용한 CloudWatch 대시보드를 생성하는 역할을 할 수 있습니다.
작업 처리에 대한 추가 세부 정보를 제공하는 메트릭 및 구조화된 정보를 사용합니다. 서비스에 대한 시스템과 같은 정보가 포함된 표준 위젯을 포함할 수 있을 뿐만 아니라. 사용자 지정 위젯 또는 메트릭으로 집계된 자체 콘텐츠로 이를 확장할 수 있습니다.
목차
로그 파일 쿼리
출처: aws.amazon.com
AWS CloudWatch Log Insights를 사용하면 AWS 리소스의 로그 데이터를 실시간으로 검색하고 분석할 수 있습니다. 데이터베이스 보기로 볼 수 있습니다. 대시보드에서 쿼리를 정의하면 대시보드 보기 내에서 정의한 대로 대시보드를 방문하거나 과거의 지정된 시간 창에서 대시보드가 쿼리를 선택합니다.
CloudWatch Logs Insights라는 쿼리 언어를 사용하여 로그 데이터를 검색하고 분석합니다. 쿼리 언어는 SQL 언어의 하위 집합을 기반으로 합니다. 로그 데이터를 검색하고 필터링할 수 있습니다. 특정 로그 이벤트, 사용자 지정 로그 텍스트 또는 키워드를 검색하고 특정 필드를 기반으로 로그 데이터를 필터링할 수 있습니다. 그리고 가장 중요한 것은 하나 이상의 로그 파일 내에서 로그 데이터를 집계하여 요약된 지표 및 시각화를 생성하는 것입니다.
쿼리를 실행하면 CloudWatch Log Insights가 로그 그룹의 로그 데이터를 검색합니다. 그런 다음 쿼리 기준과 일치하는 파일의 텍스트를 반환합니다.
로그 파일 쿼리의 예
개념을 이해하기 위해 몇 가지 기본 쿼리를 살펴보겠습니다.
모든 서비스는 기본적으로 몇 가지 중요한 서비스 오류를 기록합니다. 이러한 오류 이벤트에 대한 전용 사용자 지정 로그를 생성하지 않는 경우에도 마찬가지입니다. 그런 다음 간단한 쿼리를 사용하여 지난 1시간 동안 애플리케이션 로그의 오류 수를 계산할 수 있습니다.
fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(1h)
또는 지난 날 API의 평균 응답 시간을 모니터링하는 방법은 다음과 같습니다.
fields @timestamp, @message | filter @message like /API response time/ | stats avg(response_time) by bin(1d)
기본적으로 CPU 사용률은 서비스가 CloudWatch에 기록하는 정보이므로 이러한 유형의 지표도 수집할 수 있습니다.
fields @timestamp, @message | filter @message like /CPUUtilization/ | stats avg(value) by bin(1h)
이러한 쿼리는 특정 사용 사례에 맞게 사용자 지정할 수 있으며 CloudWatch 대시보드에서 사용자 지정 지표 및 시각화를 생성하는 데 사용할 수 있습니다. 방법은 대시보드에 위젯을 배치하고 위젯 내부에 코드를 배치하여 무엇을 선택할지 정의하는 것입니다.
다음은 CloudWatch 대시보드에서 사용할 수 있고 Log Insights의 콘텐츠로 채울 수 있는 몇 가지 위젯입니다.
- 텍스트 위젯 – CloudWatch Insights 쿼리 출력과 같은 텍스트 기반 정보를 표시합니다.
- 로그 쿼리 위젯 – 애플리케이션 로그의 오류 수와 같은 CloudWatch Insights 로그 쿼리 결과를 표시합니다.
대시보드에 유용한 로그 정보를 생성하는 방법
출처: aws.amazon.com
CloudWatch 대시보드에서 CloudWatch Insights 쿼리를 효과적으로 사용하려면 시스템에서 사용하는 각 서비스에 대해 CloudWatch 로그를 생성할 때 몇 가지 모범 사례를 따르는 것이 좋습니다. 다음은 몇 가지 팁입니다.
#1. 구조화된 로깅 사용
미리 정의된 스키마를 사용하여 구조화된 형식으로 데이터를 기록하는 로깅 형식을 고수해야 합니다. 이렇게 하면 CloudWatch Insights 쿼리를 사용하여 로그 데이터를 더 쉽게 검색하고 필터링할 수 있습니다.
이는 기본적으로 아키텍처 플랫폼의 다양한 서비스에서 로그를 표준화하는 것을 의미합니다. 개발 표준에 정의되어 있으면 엄청난 도움이 됩니다.
예를 들어, 특정 데이터베이스 테이블과 관련된 각 문제가 다음과 같은 시작 메시지와 함께 기록되도록 정의할 수 있습니다.[TABLE_NAME] 경고/오류: <메시지>”.
또는 “와 같은 접두사로 전체 데이터 작업과 델타 데이터 작업을 구분할 수 있습니다.[FULL/DELTA]”를 클릭하여 구체적인 데이터 프로세스와 관련된 메시지만 선택합니다.
특정 소스 시스템의 데이터를 처리하는 동안 시스템 이름이 각 관련 로그 항목의 접두사가 되도록 정의할 수 있습니다. 나중에 로그 파일에서 이러한 메시지를 필터링하고 그에 대한 메트릭을 작성하는 것이 훨씬 쉽습니다.
출처: aws.amazon.com
#2. 일관된 로그 형식 사용
모든 AWS 리소스에서 일관된 로그 형식을 사용하면 CloudWatch Insights 쿼리를 사용하여 로그 데이터를 더 쉽게 검색하고 필터링할 수 있습니다.
이는 앞선 지적과도 상당한 관련이 있지만, 사실은 로그 형식이 표준화될수록 로그 데이터를 사용하기가 더 쉽다는 것입니다. 그런 다음 개발자는 해당 형식에 의존하고 직관적으로 사용할 수도 있습니다.
잔인한 사실은 대부분의 프로젝트가 로깅과 관련된 표준을 신경쓰지 않는다는 것입니다. 게다가 많은 프로젝트는 사용자 지정 로그를 전혀 생성하지도 않습니다. 충격적이지만 동시에 너무 흔합니다.
오류 처리 방식 없이 사람들이 어떻게 여기에서 살 수 있는지 궁금했던 적이 몇 번이나 되었는지 모르겠습니다. 그리고 예외로 일종의 오류 처리를 시도한 사람이 있다면 잘못 처리한 것입니다.
따라서 일관된 로그 형식은 강력한 자산입니다. 많은 사람들이 가지고 있지 않습니다.
#삼. 관련 메타데이터 포함
로그 데이터에 타임스탬프, 리소스 ID 및 오류 코드와 같은 메타데이터를 포함하면 CloudWatch Insights 쿼리를 사용하여 로그 데이터를 더 쉽게 검색하고 필터링할 수 있습니다.
#4. 로그 회전 활성화
로그 데이터가 너무 커지는 것을 방지하고 CloudWatch Insights 쿼리를 사용하여 로그 데이터를 더 쉽게 검색하고 필터링하려면 로그 회전을 활성화하십시오.
로그 데이터가 없는 것도 한 가지이지만 구조가 없는 로그 데이터가 너무 많은 것도 마찬가지로 절망적입니다. 데이터를 사용할 수 없다면 데이터가 전혀 없는 것과 같습니다.
#5. CloudWatch Logs 에이전트 사용
자신을 도울 수 없고 사용자 정의 로그 시스템 구축을 거부하는 경우 최소한 CloudWatch Logs 에이전트를 사용하십시오. AWS 리소스에서 CloudWatch Logs로 로그 데이터를 자동으로 전송합니다. 이렇게 하면 CloudWatch Insights 쿼리를 사용하여 로그 데이터를 더 쉽게 검색하고 필터링할 수 있습니다.
더 복잡한 인사이트 쿼리 예
CloudWatch Insights 쿼리는 단 두 줄의 문장보다 더 복잡할 수 있습니다.
fields @timestamp, @message | filter @message like /ERROR/ | filter @message not like /404/ | parse @message /.*[(?<timestamp>[^]]+)].*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/ | stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status | sort count desc | limit 20
이 쿼리는 다음을 수행합니다.
이 쿼리는 애플리케이션에서 가장 일반적인 오류를 식별하고 HTTP 메서드, 경로 및 상태 코드의 각 조합에 대한 평균 응답 시간을 추적합니다. 결과를 사용하여 CloudWatch 대시보드에서 사용자 지정 지표 및 시각화를 생성하여 웹 애플리케이션의 성능을 모니터링하고 문제를 해결할 수 있습니다.
Amazon S3 서비스 메시지를 쿼리하는 또 다른 예:
fields @timestamp, @message | filter @message like /REST.API.REQUEST/ | parse @message /.*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/ | stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status | sort count desc | limit 20
- 쿼리는 “REST.API.REQUEST” 문자열이 포함된 로그 이벤트를 선택합니다.
- 그런 다음 로그 메시지를 구문 분석하여 HTTP 메서드, 경로, 상태 코드 및 응답 시간을 추출합니다.
- HTTP 메소드, 경로 및 상태 코드의 각 조합에 대한 평균 응답 시간 및 로그 이벤트 수를 계산하고 결과를 개수별로 내림차순으로 정렬합니다.
- 출력을 상위 20개 결과로 제한합니다.
이 쿼리의 출력을 사용하여 시간 경과에 따른 HTTP 메서드, 경로 및 상태 코드의 각 조합에 대한 평균 응답 시간을 표시하는 CloudWatch 대시보드에 선 그래프를 생성할 수 있습니다.
대시보드 구축
CloudWatch Insights 로그 쿼리의 출력에서 CloudWatch 대시보드의 지표 및 시각화를 채우려면 CloudWatch 콘솔로 이동하고 대시보드 마법사를 따라 콘텐츠를 구축할 수 있습니다.
그런 다음 CloudWatch 대시보드의 코드는 다음과 같이 표시되며 CloudWatch Insights 쿼리 데이터로 채워진 지표를 포함합니다.
{
"widgets": [
{
"type": "metric",
"x": 0,
"y": 0,
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/EC2",
"CPUUtilization",
"InstanceId",
"i-0123456789abcdef0",
{
"label": "CPU Utilization",
"stat": "Average",
"period": 300
}
]
],
"view": "timeSeries",
"stacked": false,
"region": "us-east-1",
"title": "EC2 CPU Utilization"
}
},
{
"type": "log",
"x": 0,
"y": 6,
"width": 12,
"height": 6,
"properties": {
"query": "fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)
",
"region": "us-east-1",
"title": "Application Errors"
}
}
]
}
이 CloudWatch 대시보드에는 두 가지 위젯이 포함되어 있습니다.
내부에 대시보드 및 메트릭의 정의가 포함된 JSON 형식 파일입니다. 인사이트 쿼리 자체도 속성으로 포함합니다.
코드를 가져와 필요한 모든 AWS 계정에 배포할 수 있습니다. 서비스 및 로그 메시지가 모든 AWS 계정 및 단계에서 일관적이라고 가정하면 대시보드의 소스 코드를 변경할 필요 없이 대시보드가 모든 계정에서 작동합니다.
마지막 말
견고한 로깅 구조를 구축하는 것은 시스템 안정성의 미래에 대한 좋은 투자였습니다. 이제 더 큰 목적을 달성할 수 있습니다. 그 부작용으로 지표와 시각화가 포함된 유용한 대시보드를 가질 수 있습니다.
약간의 추가 작업만으로 한 번만 수행하면 되므로 개발 팀, 테스트 팀 및 프로덕션 사용자 모두 동일한 솔루션의 이점을 누릴 수 있습니다.
다음으로 최고의 AWS 모니터링 도구를 확인하십시오.