로그와 지표로 사고 진단

소개

유효한 주문은 실패하지만 inventory 요청은 성공합니다. 애플리케이션 지표를 비교하고 로그에서 실패한 요청을 추적하며 작은 설정 오류를 수정한 뒤, 실패 이력을 지우지 않고 복구를 확인합니다.

CloudWatch Logs에서 실패한 요청 찾기와 CloudWatch 지표로 애플리케이션 상태 측정을 먼저 완료하세요. 이 실습에는 자체 애플리케이션과 사고 상황이 제공됩니다.

인증 시험 관련 주제

실습 개요

사고 재현 및 대조 요청 비교

이 단계에서는 예상치 못하게 실패하는 유효한 주문 요청을 재현합니다. 독립적으로 준비된 서비스에는 일반적인 설정 오류가 있습니다. 로그와 지표는 빈 상태로 시작하므로 관찰 결과는 직접 보낸 요청에서 나옵니다.

cd /home/labex/project

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-failure-1' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/orders

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-failure-2' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/orders

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-control' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/inventory

같은 유효한 가상 apple 요청에 대해 orders의 HTTP 503 stock_unavailable 응답 두 개와 inventory의 HTTP 200 accepted 응답을 확인하세요. 대조 요청은 orders에 특정된 문제를 시사하지만 전체 시스템이 정상임을 입증하지는 않습니다.

최근 UTC 시간 범위와 정확한 Application 차원으로 서버 오류 수를 비교하세요. 지표는 빈도를 요약하고 개별 로그는 특정 응답을 설명할 수 있습니다.

START=$(date -u -d '15 minutes ago' +%Y-%m-%dT%H:%M:%SZ)
echo "$START"

쿼리 시간 범위의 종료 시간을 UTC로 저장하세요:

END=$(date -u -d '1 minute' +%Y-%m-%dT%H:%M:%SZ)
echo "$END"

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Errors \
  --dimensions Name=Application,Value=orders \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Errors \
  --dimensions Name=Application,Value=inventory \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

반환된 집계 구간 전체에서 orders의 Sum 2와 inventory의 Sum 0을 확인하세요. /labex/o05-reference는 그대로 유지하세요.

오류 수와 요청 로그 연결

이 단계에서는 요약된 증상을 구체적인 실패 요청과 연결합니다. 먼저 ERROR를 쿼리한 다음 정확한 요청 ID를 쿼리하세요. 따옴표로 감싼 구문은 전체 request_id 토큰과 일치하므로 이름이 비슷한 요청을 섞지 않습니다.

aws logs filter-log-events \
  --log-group-name /labex/o05-application \
  --filter-pattern ERROR \
  --query 'events[].{Time:timestamp,Message:message}'

aws logs filter-log-events \
  --log-group-name /labex/o05-application \
  --filter-pattern '"request_id=o05-failure-1"' \
  --query 'events[].message'

두 실패는 모두 application=orders, status 503, reason stock_unavailable을 나타냅니다. 지표와 로그는 최근 시간 범위의 같은 요청을 다룹니다. 애플리케이션 설정을 검사해 유효한 apple 요청과 맞지 않는 부분을 찾으세요.

cat app.json

orders의 accepted_sku는 pear입니다. inventory는 독립적으로 예상한 apple 설정을 사용합니다. 이는 작은 설정 오류입니다. 서비스를 교체하거나 관측 기능을 비활성화하면 문제를 고치지 않고 증상만 숨기게 됩니다.

실패한 요청은 apple을 보냈지만 orders 설정은 pear를 허용합니다. 이 불일치는 stock_unavailable에 대한 검증 가능한 설명이며 정상적인 inventory 요청은 문제 범위를 좁히는 데 도움이 됩니다. 다음 단계에서는 orders 설정을 바꾸고 유효한 요청을 다시 보내 이 설명을 검증합니다. 복구는 설정 수정만으로 입증되지 않으며 성공한 응답과 그에 대응하는 새 로그가 필요합니다.

설정 수정 및 복구 검증

이 단계에서는 허용할 SKU를 변경하고 원격 측정이 활성화된 상태에서 비즈니스 응답이 복구됨을 입증합니다. 일반적인 설정을 올바른 설정으로 교체하세요.

cat > app.json <<'JSON'
{"logging": {"enabled": true, "group": "/labex/o05-application", "stream": "requests"}, "metrics": {"enabled": true, "namespace": "LabEx/O05"}, "accepted_sku": "apple"}
JSON

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-recovered' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/orders

aws logs filter-log-events \
  --log-group-name /labex/o05-application \
  --filter-pattern '"request_id=o05-recovered"' \
  --query 'events[].message'

HTTP 200 accepted와 같은 복구 요청 ID에 대한 INFO 로그를 확인하세요. 과거 실패는 시간 범위 안에 남습니다. 정상 요청은 Errors=0을 게시하므로 누적 오류 Sum은 2로 유지되고 Requests는 3으로 증가합니다.

START=$(date -u -d '15 minutes ago' +%Y-%m-%dT%H:%M:%SZ)
echo "$START"

쿼리 시간 범위의 종료 시간을 UTC로 저장하세요:

END=$(date -u -d '1 minute' +%Y-%m-%dT%H:%M:%SZ)
echo "$END"

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Errors \
  --dimensions Name=Application,Value=orders \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Requests \
  --dimensions Name=Application,Value=orders \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

AWS View는 실제 애플리케이션 시리즈와 요청 로그를 보여 줍니다. 복구 요청 ID로 새 성공 응답과 보존된 실패 이력을 구별하세요.

원격 측정 중단 및 소유한 로그 그룹 정리

이 단계에서는 계측을 중단하고 사고 로그 그룹만 제거합니다. 기존 지표는 보존 정책에 따라 남습니다. 개별 지표 삭제 API는 없습니다.

cat > app.json <<'JSON'
{"logging": {"enabled": false, "group": "/labex/o05-application", "stream": "requests"}, "metrics": {"enabled": false, "namespace": "LabEx/O05"}, "accepted_sku": "apple"}
JSON

aws logs delete-log-group --log-group-name /labex/o05-application

aws logs describe-log-groups --query 'logGroups[].logGroupName'

aws logs get-log-events \
  --log-group-name /labex/o05-reference \
  --log-stream-name platform \
  --query 'events[].message'

/labex/o05-reference만 남고 원래 INFO platform reference keep unchanged 메시지가 있는지 확인하세요. 성공한 목록 조회는 대상만 삭제했음을 검증합니다. 실패한 조회는 정리를 입증하지 못합니다.

요약

대조 요청과 함께 사고를 재현하고 지표 횟수를 요청 로그와 연결했으며, 애플리케이션 설정을 수정하고 새 성공 응답을 검증했습니다. 대상 리소스를 정리하기 전까지 과거 증거를 보존했습니다.

자세한 내용은 AWS 공식 문서를 참고하세요: 지표 식별, 차원 및 통계; 용어와 정확한 구문으로 로그 이벤트 필터링.