클라우드/AWS

Opensearch Ingestion 으로 통합 로그 모니터링하기 - 1

게임이 더 좋아 2024. 8. 22. 18:21
반응형
728x170

필요성

대부분의 기업들에서는 AWS Organization 밑에 여러가지 서비스 계정이 존재한다.

즉, 서비스 계정으로 AWS Resource들이 분리되어 있다.

그렇기 때문에 통합을 만들기가 은근히 까다롭다.

특히 서비스마다 특성도 다르기 때문에 로그를 파싱하는 것도 어려울 것이다.

 

하지만 한 번에 관리할 수 있다면?

- 각 서비스의 로그가 추가되었을 때, 한 곳에서 파싱구조 변경해서 파싱 가능

- 서비스가 새로 생겼을 때, 파이프라인 구성이 용이함

- 서비스가 삭제되었을 때, 파이프라인 삭제도 용이함

- 통합되어있기 때문에 사용자를 한 곳에서 관리 및 권한 제어가 용이함

- Opensearch의 장애를 자동으로 탐지해서 교체함 (Auto Recovery)

- Opensearch Alert을 한 곳에서 설정 가능

등이 있다.

 

Opensearch Ingestion이 그것을 가능하게 해주는 수많은 방법 중 하나다.

https://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/ingestion.html

 

아마존 OpenSearch 인제션 - 아마존 OpenSearch 서비스

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

 

 


 

구조

 

AWS에서 소개하는 기본적인 구조는 아래와 같다.

 

내가 구성하려는 것도 이와 다르지 않다.

 

Manager를 두고서 Admin이 유저마다 대시보드 관리 및 Alert 그룹 설정 등을 하게 한다.

하는 역할은 우선 아래와 같다.

- 타 유관부서와 대시보드 공유

- 타 유관부서에 Alert 그룹 관리

 

수많은 소스가 존재한다.

S3의 파일이 있을 것이고

EC2의 시스템로그가 있을수도있고

EC2에서 뽑은 fluentbit가 전송하는 로그가 있을 수도 있다.

Osis 에서는 S3 및 HTTP로 로그 Source 를 지원한다.

충분히 가능하다.


 

구현

 

Opensearch pipeline에서는 많은 것을 지원하는데

파싱해서 보낼 것이냐?? 파싱을 pipeline에서 할 것이냐??를 먼저 결정해야 한다.

충분히 파싱해서 보낼 수 있는 로그에 대해서는 걱정이 없다. (HTTP source)

하지만 S3에 저장된 로그를 직접 가져온다면 S3 자체에서는 파싱이 불가능하다.

그래서 S3에 대해서 구현한 과정을 나눠보려고 한다.

다음 글에서 작성하겠다.

 

 

728x90
반응형
그리드형