Amazon EC2 모니터링에 Datadog을 사용하십니까? 자동화 된 수정을 위해 SIOS AppKeeper와 페어링

"Datadog이 Amazon EC2 서비스를 모니터링하고 실패를 감지하면 자동으로 다시 시작할 수 있다면 좋을 것 같습니다."라고 생각한 적이 있습니까? 저도 같은 생각을했고 직접 시도해보기로했습니다.

SIOS AppKeeper는 Amazon EC2 인스턴스에서 오류를 자동으로 모니터링하고 인스턴스를 자동으로 다시 시작하거나 오류가 감지되면 서비스를 재부팅합니다."Datadog의 모니터링 기능과 AppKeeper의 자동 치료 기능을 결합하면 어떨까요?"라고 생각했습니다.

효과가 있었고 여기에 내가 한 방법이 있습니다.

이미 Datadog을 사용 중이고 직접 시도해보고 싶다면이 기사의 끝에 등록하여 API에 액세스하십시오.

다음은 Datadog에서 알림을 수신하고 가동 중지 시간이 감지되면 Amazon EC2에서 웹 서버를 다시 시작하도록 AppKeeper를 설정하기 위해 수행 한 단계입니다.

이 실험을 성공적으로 실행하기 위해 Amazon EC2 (Linux 2 사용)에서 실행되는 Datadog 계정, AppKeeper 계정 및 NGINX 웹 서버가 이미있었습니다.

Datadog을 AppKeeper와 통합하여 자동 수정을 제공하는 방법

1 단계 : AppKeeper에서 다시 시작 API 토큰 가져 오기

다음 양식에서 Datadog 통합을위한 API 토큰을 요청하십시오.

https://mk.sios.jp/BC_AppKeeper_Datadog_api_application

양식에서 요청하면 제공 한 이메일 주소로 토큰이 전송됩니다.

2 단계 : AppKeeper에서 테넌트 만들기

다음 단계는 모니터링되는 인스턴스가 속한 AWS 계정을 AppKeeper에 등록하는 것이 었습니다. (AppKeeper는 등록 된 AWS 계정을 "테넌트"라고합니다.)

https://sioscoati.zendesk.com/hc/en-us/articles/900000123406-Quick-Start-Guide#h_39404cfb-4a76-450f-99c2-e197cc63e50d

3 단계 : AWS에서 IAM 역할 생성

그런 다음 AWS에서 IAM 역할을 생성했습니다 (AppKeeper 계정을 설정하는 데 필요함).이 절차에 대해 잘 모르는 경우 다음 안내를 따르세요.

4 단계 : AppKeeper에서 테넌트 추가

다음 단계는 AppKeeper에 "테넌트"를 추가하는 것이 었습니다 (AppKeeper는 AWS 계정을 "테넌트"로 간주 함).다음은이를 수행하는 방법에 대한 자세한 안내 링크입니다.

5 단계 : Datadog에서 합성 테스트 설정

그런 다음 모니터링하려는 Nginx 서버 (EC2 인스턴스)에 대해 Datadog의 개요 모니터링을 구성해야했습니다.방법은 다음과 같습니다.

Datadog 대시 보드를 열고 메뉴에서 UX Monitoring> Synthetic Tests를 선택하십시오.

오른쪽 [New Test]상단 모서리에있는 버튼을 클릭하고 개요 [New API Test]모니터링 사례 생성을 선택합니다.

개요 모니터링 사례를 생성하려면 양식에 다음 정보를 입력하십시오.

1. 요청 유형 선택
   "HTTP"를 선택합니다.
2. 요청 정의 :
   다음 값을 설정하십시오.
   URL : GET http : // {{{EC2 IP 주소}}
   이름 : AppKeeper Datadog 통합 테스트 (모든 이름)
   위치 : 도쿄

삼. 테스트 빈도 지정
변경 없음

4. 어설 션 정의
"새 어설 션"을 클릭하고 다음 값을 설정합니다.

언제 :
[status code]
[is][200]

5. 경고 조건 정의
변경 없음

6.팀에 알리기
변경 없음

6 단계 : Datadog에서 합성 테스트 실행

위의 입력이 완료되면“Create Test”를 눌러 외부 모니터링을위한 테스트 케이스를 생성합니다.

결과가 표시되고 "테스트 결과"섹션에서 웹 서버가 제대로 작동하고 있음을 확인할 수 있습니다.

Datadog을 사용하여 Synthetics 모니터링을 구성하기 위해 수행해야하는 모든 작업입니다.

7 단계 : Synthetics 경고를 받도록 AppKeeper 설정

다음으로 AppKeeper를 알림 대상으로 설정해야했습니다.Datadog 메뉴에서 통합으로 이동하여 통합 탭을 선택합니다.

검색 상자에 "Webhooks"를 입력하여 Webhooks 통합을 찾습니다.

"사용 가능"을 클릭하여 Datadog 계정에서 Webhook 통합을 활성화합니다. (활성화되면 "설치됨"열에 나타납니다.)

"구성"을 클릭하여 Webhook 통합 구성 페이지를 엽니 다.

페이지 하단의 "Webhooks"열에서 "New +"를 클릭하여 새 Webhooks 알림 대상을 만듭니다. 매개 변수에 대해 다음을 입력하십시오.

이름 : 통합 이름 (모든 이름)

URL : https://api.appkeeper.sios.com/v2/integration/ {{AWS 계정 ID}} / actions / recover

페이로드 :

{ “instanceId”:“{{EC2 Instance ID}}”, "이름": "nginx" }

맞춤 헤더 : 체크 박스를 선택하고 다음을 입력합니다.

{ “Content-type”:“application / json”, “accept”:“application / json”, "appkeeper-integration-token": "{{AppKeeper 외부 통합 토큰 가져 오기}}에서 얻은 토큰" }

완료되면 "저장"을 누르십시오.

8 단계 : AppKeeper를 합성 테스트에 연결

다음으로 Synthetics 모니터링 경고가 발생할 때 호출되도록 AppKeeper (등록 된 Webhooks 통합)를 구성해야했습니다.

메뉴의 UX Monitoring> Synthetic Tests에서 "Configuring the Synthetic Monitoring with Datadog"에서 설정 한 테스트 케이스를 엽니 다.

오른쪽 상단 기어 박스에서 "테스트 세부 정보 편집"을 선택하고 "5. Notify Your Team”상자를 눌러 변경 사항을 저장하십시오.

@webhook-{{Datadog의 Webhook 통합 이름}}

※“모니터가 해결되지 않은 경우 다시 알림”을 설정할 수 있습니다.AppKeeper가 처음으로 복구에 실패하면 다시 시도 할 수 있습니다.테스트 목적으로는 필요하지 않지만 (최소 간격)으로 설정하는[10 minutes] 것이 좋습니다.

이제 설치가 완료되었습니다.

9 단계 : 테스트를 다시 실행하여 통합 확인

그런 다음 Datadog이 다운 된 것으로 감지되면 AppKeeper가 웹 서버를 복원 할 것임을 확인했습니다.

UX Monitoring> Synthetic Tests in Datadog에서 방금 설정 한 Synthetics 모니터링 테스트 케이스를 엽니 다.

오른쪽 상단의 "Resume Test"를 클릭하고 Synthetics 모니터링을 켭니다.

이제 Datadog은 정기적으로 Synthetics 모니터링을 수행합니다.

테스트 결과는 서버가 성공적으로 액세스되었음을 보여줍니다.

다음으로 AppKeeper의 자동 수정을 테스트하기 위해 웹 서버의 의사 오류를 생성했습니다.

실제 장애를 일으키기 어렵 기 때문에 서비스를 중단하고 웹 페이지를 볼 수없는 상황을 만들었습니다.이를 위해 SSH를 사용하여 Nginx 서버가 설치된 EC2 인스턴스에 연결하고 Nginx를 중지했습니다.

sudo systemctl stop nginx

잠시 후 Datadog은 웹 서버에 더 이상 액세스 할 수 없음을 감지했습니다.

Datadog의 합성 테스트 페이지에도 테스트 케이스가 실패했음을 표시합니다.

테스트 케이스가 실패하면 Datadog은 Synthetics 모니터링이 실패했음을 AppKeeper에 알립니다.

AppKeeper가 알림을 받으면 자동으로 Nginx를 다시 시작합니다.

따라서 잠시 기다리면 Datadog의 Synthetics 모니터링 검사가 다시 통과되는 것을 볼 수 있습니다.

또한 AppKeeper 대시 보드에 로그인하면 복구가 수행되었음을 알 수 있습니다.

—

이 연습에서는 웹 서버 (Nginx)를 예로 사용하여 Datadog에서 오류를 감지하고 AppKeeper로 서비스를 복원하는 프로세스를 자동화했습니다.

Datadog을 EventBridge 및 Lambda와 통합하거나 사용자 지정 스크립트를 생성하여 유사한 자동화를 달성 할 수 있습니다.

그러나 대상 인스턴스를 자주 추가하거나 다양한 서비스를 다시 시작하면 EventBridge 및 Lambda 또는 스크립트를 유지 관리하는 데 드는 비용과 복잡성이 증가합니다.

AppKeeper는 Datadog과의 입증 된 통합 및 애플리케이션에 대상 인스턴스를 쉽게 추가 할 수 있으므로 DevOps 환경에 자동화를 쉽게 추가하여 다운 타임을 줄일 수 있습니다.

현재 Datadog을 사용 중이고 AppKeeper의 Restart API를 사용해 보려면 먼저 여기에서 14 일 무료 평가판에 가입하세요 (무료 평가판을 설치 한 후 구독을 구매할 수 있음).그런 다음 여기를 클릭하여 무료 평가판을 요청하세요. 프로세스를 안내하고 시작하는 데 도움이되는 무료 평가 토큰을 제공합니다.

평가 토큰 신청

감사합니다.이번 기회에 EC2에서 실행되는 애플리케이션의 자동 모니터링 및 복구를 제공하는 SIOS AppKeeper에 대해 자세히 알아 보시기 바랍니다.

— SIOS 기술 기술팀의 Tatsuya Hirao.

애플리케이션 가용성 문제가있는 9 가지 신호

"문제를 인식하는 것이 문제 해결의 첫 번째 단계"라는 말을 들어 보셨을 것입니다. 그러나 놀랍게도 많은 중소기업 및 놀랍게도 대기업에서도 애플리케이션 가용성이 당연한 것이 아니라는 사실을 인식하지 못하고 있습니다.

여전히 애플리케이션 가용성 문제가 있음을 나타내는 다음 9 가지 징후를 읽으십시오.

1. 응용 프로그램을 사용하는 것보다 다시 시작하는 데 더 많은 시간을 소비합니다.

응용 프로그램 충돌은 일상적인 일이 될 수 있지만 응용 프로그램이 작동 중보 다 자주 중단되면 문제가됩니다.

2.받은 편지함 또는 제어 센터에서 경고 폭풍을 통해 일시 중지하기 시작했습니다.

애플리케이션 또는 서버 다운 타임에 대한 경고를 배포했지만 경고 폭풍으로받은 편지함이 너무 많아서 모두 무음 처리했습니다.

3. 모든 중요한 작업을위한 하나의 데이터 센터가 있습니다.

운영을위한 단일 데이터 센터는 편리하게 들릴 수 있지만 의도는 좋지만 방향이 잘못된 건설 직원 한 명이 단일 데이터 센터를 비용이 많이 드는 비가 용 영역으로 전환하는 것으로 알려져 있습니다.

4. 데이터 보호에 대한 귀하의 아이디어에는 백업 검색 및 아카이브가 포함됩니다.

데이터 보호 전략이 중요합니다.데이터 복제 기술 및 사이트 간 복제, 지역 간 복제가 중심이되었으므로 복제 또는 데이터 보호 전략이 존재하지 않거나 저장소에 대한 긴 조그가 포함 된 경우 큰 문제가 될 수 있습니다.

5. 복구 절차에는 항상 수동 개입이 필요합니다.

수동 개입 자체는 문제가되지 않습니다. 일부 이벤트는 너무 어렵고 복잡하여 어느 정도의 수작업이 필요할 수 있습니다.그러나 수동 개입이 항상 서버 또는 애플리케이션 중단 후 비즈니스의 첫 번째, 두 번째 및 세 번째 순서라면 문제가됩니다.

6. RTO는 몇 시간 또는 몇 분이 아닌 일 단위로 측정됩니다.

RTO (복구 시간 목표)를 어떻게 측정하고 있습니까? RTO를 한 달에 몇 분이 아닌 며칠 또는 몇 시간으로 측정합니까?사실 모든 비즈니스에는 RTO에 대한 허용 수준이 있습니다.그러나 RTO는 아키텍처의 서버 재 구축 및 전체적인 불안정성의 기능이되어서는 안됩니다.

7. 대기 상태가 안정적으로 동기화되지 않기 때문에 RPO를 모릅니다.

애플리케이션의 안정적인 모니터링 및 복구 확인란을 선택하고 한 단계 더 나아가 대기 클러스터 지원 시스템을 제공했습니다.잘 했어.하지만 해결하기 전에 RPO (복구 지점 목표)는 무엇입니까? RPO는 "0 일차와 어제 밤 사이의 어딘가"보다 더 정확한 것이어야합니다.

8. 단일 실패 지점은 단순히 존재하는 것이 아니라 표준입니다.

단일 실패 지점은 어디에 있습니까?예산으로 모든 단일 장애 지점을 제거 할 수는 없지만 모든 주요 범주와 기업의 모든 중요 구성 요소에서 단일 장애 지점을 식별 할 수 있다면…

9. 귀하의 마지막 재난이 지역, 지역 또는 전국 뉴스를 만들었습니다.

마지막 주요 폭풍, 그리드 장애 또는 장애 이벤트로 인해 다운 타임으로 인해 비즈니스에 문제가 발생한 경우 다음 비즈니스 순서는 더 높은 가용성입니다.

다운 타임은 고객, 생산성 및 마음의 평화 측면에서 비즈니스에 손실을줍니다.해결되지 않은 위험은 비즈니스와 평판에 확실한 영향을 미칩니다.이러한 경고 서명이 있으면 가용성 문제가있을 수 있습니다.그리고이를 무시하면 곧 더 큰 문제가 발생할 수 있으므로 애플리케이션 가용성이 중요합니다.

— Cassius Rhue, VP, 고객 경험