Amazon OpenSearch로 EKS환경 Observability 구현하기에 대한 3번째 글 입니다.
1. Amazon OpenSearch로 EKS환경 Observability 구현하기 (1) - 마이크로서비스 환경의 Obervability와 필요성, AWS 인프라 구성
2. Amazon OpenSearch로 EKS환경 Observability 구현하기 (2) - OpenSearch 클러스터 테스트 및 EKS 클러스터 배포
3. Amazon OpenSearch로 EKS환경 Observability 구현하기 (3) - 로그검색 활성화 및 Observavility 구현/테스트
로그검색 활성화
- 환경구성 시에 FluentBit의 서비스는 이미 구현이 되어있습니다. FluentBit가 어떻게 구성되어있는지 확인하기 위해 구성파일을 확인해보도록 하겠습니다.
- FluentBit의 구성파일은 ~/environment/observability-with-amazon-opensearch/sample-apps/00-fluentBit/kubernetes/fluentbit.yaml에 위치하고 있습니다.
- [SERVICE] 섹션은 fluentbit 파이프라인을 설정하기 위해 다양한 구성을 결합합니다.
- [INPUT] 섹션 은 로그 수집 방법을 정의합니다.
- [FILTER] 섹션은 로그 처리 방법을 정의합니다.
- [OUTPUT] 섹션은 로그가 Data Prepper로 전달되는 방식을 정의합니다.
- [SERVICE] 섹션은 fluentbit 파이프라인을 설정하기 위해 다양한 구성을 결합합니다.
- OpenSearch 대시보드로 이동하여 인덱스가 생성되어있는지 확인하도록 하겠습니다.
- 콘솔을 사용하여, 다음 커맨드를 통해 요청을 보냅니다.
GET _cat/indices/sample_app_logs*?v
- 로그를 검색하려면 인덱스 패턴을 생성해야합니다. 인덱스 패턴을 생성하여 인덱스를 찾을 수 있습니다.
- 관리섹션에서 스택관리로 이동합니다.
- 인덱스 패턴을 선택한 후 만들기를 선택합니다.
- 패턴 이름에 sample_app_logs* 를 입력하고 다음단계를 선택합니다.
- 타임 필드에 time 을 선택하고 인덱스 패턴을 생성합니다.
- 관리섹션에서 스택관리로 이동합니다.
- 검색페이지로 이동합니다.
- o11y Shop에서 오는 로그를 검사할 수 있습니다.
Observability 구현
- o11y Shop 고객은 때때로 UI가 느리고 때때로 구매를 완료할 수 없으며 시스템에 오류가 발생한다고 불평하는 상황을 가정하겠습니다.
- 추적 및 로그분석을 진행하여 오류율이 증가한 마이크로 서비스를 식별해보도록 하겠습니다.
- o11y Shop에서 트레이스(추적) 생성
- Cloud9의 터미널 세션에서 다음 명령을 실행하여 샘플 애플리케이션 웹 URL을 다시 가져오고 웹 브라우저에서 엽니다.
cd /environment/observability-with-amazon-opensearch/scripts/ kubectl get svc -nclient-service | awk '{print $4}' | tail -n1
- 일반적인 제품 구매 워크플로우를 따라보겠습니다. 몇가지 제품을 선택하고 모든 단계를 거쳐 구매를 완료합니다. 몇가지의 주문을 취소하고 주문상태를 확인하는 과정을 진행합니다.
- Observability 플러그인
- OpenSearch Plugins 아래에서 Observability를 선택합니다.
- Application Analytics 메뉴를 선택 하고 Create Application을 선택합니다.
- Name 필드 에 Sample Application을 입력 하고 Description 필드에 설명을 입력합니다.
- 포지션 아래의 로그 소스 섹션을 펼치고 sample_app_logs를 샘플 애플리케이션 의 소스 로그로 추가합니다.
- Base Query 필드 에서 아래 PPL 쿼리를 생성합니다.
- Base Query 필드 에서 아래 PPL 쿼리를 생성합니다.
- Services & entities 섹션을 펼치고 order , analytics-service , frontend-client , database , authentication , Inventory , Payment 및 Recommandation 서비스를 모두 선택하여 조사를 위해 sample application 에 포함시킵니다.
- 만들기 버튼(create)을 클릭하여 어플리케이션 작성을 완료합니다.
- 개요 탭 에는 Latency by trace group 이라는 테이블이 있습니다 . 이 보기는 HTTP 메서드 및 경로 별로 추적을 그룹화 하므로 특정 작업과 관련된 평균 대기 시간, 오류율 및 추세를 볼 수 있습니다.
- 서비스 탭에는 애플리케이션의 서비스에 대한 두 가지 보기가 있습니다. 첫 번째 테이블 보기에는 평균 대기 시간, 오류율 및 서비스당 처리량과 같은 각 서비스와 관련된 서비스 및 추세가 나열됩니다. 두 번째 보기 애플리케이션 구성 맵은 다양한 서비스가 서로 연결되는 방법을 보여주는 대화형 맵입니다.
- Traces & Spans 탭 에서 Trace Id 중 하나를 클릭하여 단일 추적을 검사해보겠습니다.
- 추적 세부 정보 화면이 팝업되고 서비스 보기에서 소요된 시간, 타임라인 및 각 추적의 스팬 목록 부분이 표시됩니다.
- OpenSearch Plugins 아래에서 Observability를 선택합니다.
실패한 서비스 식별하기
문제의 원인이 되는 서비스를 찾는 상황을 가정하고, 실패한 서비스를 찾아보겠습니다.
- 옵저버빌리티 - 애플리케이션 - 개요(Overview)탭을 확인해보도록 하겠습니다.
- Composition Map의 오류율 탭을 선택합니다.
- Payment 서비스가 진한 빨간색으로 표시되므로 결제 서비스가 다른 서비스들보다 오류율이 높은것을 확인 할 수 있습니다.
- Payment 서비스를 클릭하여 필터조건을 serviceName:payment 으로 설정합니다 이렇게하면 payment서비스 이름을 기준으로 추적을 필터링 할 수 있습니다.
- Traces & Spans 탭을 선택하면 결제 서비스와 관련된 모든 추적 목록이 표시됩니다.
실패한 서비스를 찾았으니, 원인을 찾아 결제서비스가 실패하는 이유를 알아보도록 하겠습니다.
실패한 서비스 정상화 하기
애플리케이션은 추적데이터와 로그데이터를 모두 내보내므로 이 두가지의 신호를 연관시킨다면 문제의 근본원인을 파악하고 오류를 해결 할 수 있습니다.
- 실행시점
- 로그와 추척 메트릭은 실행이 발생한 순간 또는 시간범위를 기록할 수 있습니다.
- 실행(요청) 컨텍스트
- OpenTelemetry는 로그레코드에 TraceId와 SpanId를 포함하여 로그를 확장하기때문에 동일한 실행 컨텍스트에 해당하는 로그와 추적을 연관시킬 수 있습니다.
- 리소스 컨텍스트
- OpenTelemetry의 추적 및 메트릭 데이터에는 리소스에 대한 정보가 포함되어있기때문에 로그로 확장이 가능합니다.
이 3가지의 상관관계를 활용한다면 탐색, 쿼리, 필터링 및 분석의 기반으로 사용할 수 있습니다.
예제 애플리케이션의 마이크로서비스는 Python과 Java작성되어있고, OpenTelemetry 로깅 라이브러리를 사용하여 애플리케이션 로그에 trace_id와 span_id 컨택스트를 추가한 상태입니다.
- Traces & Spans 탭에서 TraceID(Errors -> yes) 중 하나를 선택 해 보겠습니다.
- 디테일을 확인하니 payment의 checkout부분에 문제가 있는것 같습니다.
- Trace ID를 복사하고 Logs Events 탭으로 이동하여 이벤트를 검색합니다.
- 다음 쿼리를 사용하여 이벤트를 검색하면 됩니다.
where traceId = '0dfa628cee7f6755c8e1cc3d25ff55f6'
- 로그를 확인해보니 Payment의 Checkout operation이 문제이고 503 status 리턴을 확인할 수 있습니다.
- Payment 서비스의 Checkout 이 문제가있고, 오류가 발생한 이유를 찾았기 때문에 수정하도록 하겠습니다.
- Cloud9 환경에 접속하여 payment 서비스를 확인해보도록 하겠습니다.
- 현재 코드는 랜덤한 수를 사용하고있고 해당 수가 ERROR_RATE_THRESHOLD보다 작은경우 503 상태코드를 반환합니다.
- 현재 임계값이 100으로 설정되어있으므로, 해당 값을 0으로 변경하겠습니다. 로직이 if문을 만족하지 않아 else로 동작할것입니다.
- 코드를 변경하였으므로, 새롭게 이미지를 빌드하도록 하겠습니다. 태그는 fixed로 하겠습니다.
aws ecr get-login-password --region ${AWS\_REGION} | docker login --username AWS --password-stdin ${ACCOUNT\_ID}.dkr.ecr.${AWS\_REGION}.amazonaws.com export repo\_name=payment-service cd $HOME/environment/observability-with-amazon-opensearch/sample-apps/08-paymentService/ docker build -t ${repo\_name}:fixed . docker tag ${repo\_name}:fixed ${ACCOUNT\_ID}.dkr.ecr.${AWS\_REGION}.amazonaws.com/${repo\_name}:fixed docker push ${ACCOUNT\_ID}.dkr.ecr.${AWS\_REGION}.amazonaws.com/${repo\_name}:fixed
- 이미지태그를 변경하고 업데이트된 쿠버네티스 매니페스트를 적용하도록 하겠습니다.
sed -i -e "s|amazonaws\\\\.com\\\\/payment\\\\-service|amazonaws\\\\.com\\\\/payment\\\\-service\\\\:fixed|g" ${HOME}/environment/observability-with-amazon-opensearch/sample-apps/08-paymentService/kubernetes/01-deployment.yaml kubectl apply -f ${HOME}/environment/observability-with-amazon-opensearch/sample-apps/08-paymentService/kubernetes/
- 결제서비스가 다시 실행되면 체크아웃 작업을 다시 실행합니다
- 결제 서비스에서 오류가 해결된 것을 확인할 수 있습니다.
정리
- OpenSearch 클러스터를 사용하였습니다.
- EKS환경을 통해 샘플 앱인 o11y Shop을 배포하였습니다.
- Data Prepper를 통해 FluentBit 로그를 기록했습니다.
- OpenTelemetry 를 통해 추적데이터를 DataPrepper로 보냈습니다.
- OpenSearch의 Observability 를 사용하여 문제있는 서비스를 찾아내고, 수정 / 재배포하여 서비스를 정상화 하였습니다.
