AWS에서 앱 로그 메트릭의 외부 서비스 연계 정보
컨테이너 앱 모니터링 정보
예를 들어, ECS에서 실행되는 애플리케이션의 경우, 모니터링 에이전트를 사이드카로 동봉하고,
외부 서비스에 로그 메트릭스를 연계하는 경우가 많다고 생각합니다.
사이드카 패턴을 채용하는 이유로서는 이하등이 있을까 생각합니다.
・메인 컨테이너에 우선적으로 자원을 할당해, 낮은 레이턴시로 응답시킬 수 있다
· 로그 라우팅 설정을 변경할 때 앱에 손을 추가 할 필요가 없습니다.
이 때 포함 된 모니터링 에이전트가 자주 외부 서비스에 로그 메트릭을 보내면,
리소스를 찢어서 주요 기능에 영향을 줄 수 있습니다.
따라서 에이전트는 종종 앱 컨테이너에서 보낸 로그 메트릭을
버퍼링하고 정리하여 외부 서비스에 송신하는 등의 방법을 취합니다.
예를 들어 Datadog를 사용하는 경우 Datadog에서 제공하는 컨테이너 이미지
간편하게 컨테이너 감시를 실현할 수 있습니다.
Lambda 모니터링 정보
Lambda의 경우 ECS처럼 실행 환경에 좋아하는 컨테이너를 포함 할 수 없습니다. Lambda의 경우,
Lambda Extensions를 사용하는 것이 좋습니다. Lambda Extensions를 사용하여
함수와는 별도의 프로세스로서 모니터링용 에이전트등의 배치등이 가능하게 됩니다.
Lambda Extensions에 대해서는 이 기사 가 매우 알기 쉽게 참고가 되었습니다.
예를 들어, Datadog의 경우, Datadog Lambda 확장 라고 하는 것이 제공되고 있습니다.
이것을 앱이 움직이는 Lambda에 Lambda 레이어로 추가함으로써
함수 실행 중에 사용자 지정 메트릭과 로그를 동기적으로 전송할 수 있습니다.
또 다른 비슷한 것으로 Datadog Lambda 라이브러리이 있지만,
이 프로그램은 라이브러리로 프로그램으로 가져 와서 맞춤 메트릭 전송
가능하게 하는 것으로, 로그의 송신에는 대응하고 있지 않는 것 같습니다.
현재, 로그의 송신에 대응하고 있는 Datadog Lambda 확장 기능이 편리함이 좋을 것 같네요.
Reference
이 문제에 관하여(AWS에서 앱 로그 메트릭의 외부 서비스 연계 정보), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/masawai/items/2fb966c8de6b7fb9c2fb텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)