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

구현

Opensearch Ingestion pipeline을 구성해야한다. 

 

구현은 크게 3가지로 나눈다

Source -> 로그 원문 또는 처리하고자 하는 데이터

Processor -> 처리하는 방법

Output -> 어디에서 모니터링할 것인가?

 

---

 

Source

나는 S3의 파일을 읽고자 했다. 하기 위해선 여러가지 작업들이 필요했다.

** 나는 S3 SQS를 사용하지 않았다.

특히 Multi Account의 구조이기 때문에 Account A에서 Account B, C, D와 같은 다른 계정의 버킷(S3)에 대한 접근이 필요했다. 

게다가 S3에 대해서는 Push(X) Pull(O) 권한이 필요했다.

즉, Account A가 Pulling하는 주체다.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html

Example 2: Bucket owner granting cross-account bucket permissions - Amazon Simple Storage Service

 

Source로 S3를 사용하기 위한 작업

Account B에 A가 가져가야할 버킷 'dev-bucket'이 있다고 하자.

Account B의 버킷 정책을 설정 후 이 정책을 Account A에 부여하자.

AWS 예시를 바꿔보자면 아래와 같다.

Account A 의 root 계정에 위임했으니 이 root 계정의 권한을 이용해 다시 다른 사용자에게 위임해서 사용한다.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "Example",
         "Effect": "Allow",
         "Action": [
            "s3:ListBucket"
         ],
         "Resource": [
            "arn:aws:s3:::dev-bucket"
         ]
      }
   ]
}

즉, Account A의 ops 사용자에게 해당 리소스의 권한을 다시 부여함으로써 ops 사용자의 opensearch pipeline은 s3에 접근할 수 있게 된다.

하지만 파이프라인에서는 신뢰 관계를 이용해야 하므로 Account A 의 ops 사용자의 연결된 Role 에 위 권한을 연결해야한다.

Opensearch Pipeline에서는 아래와 같이 된다.

version: "2"
source:
  s3:
    ...
    aws:
      ...
      sts_role_arn: arn:aws:iam::{account-A}:role/pipeline-role
processor:
  ...
sink:
  - opensearch:
      ...

 

pipeline-role을 생성해서 위 권한을 붙여야 한다.

 **sts_role_arn에 대해서 더 자세히 알아보자면

AWS STS를 통해 임시로 부여받을 역할(Role)을 지정하게 되는데

여기서는 S3와 OpenSearch 간의 데이터 전송을 처리하기 위해 특정 역할(Role)을 사용하는 데 필요하다.

즉,  pipeline-role은

파이프라인이 데이터 소스(S3)와 데이터 싱크(OpenSearch)에 접근할 때 필요한 권한을 가진 역할 -> Pulling

 

또한 추가적으로 bucket_owner를 이용해 Account B,C,D의 ID를 적어주어야 한다.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-owner-condition.html

Verifying bucket ownership with bucket owner condition - Amazon Simple Storage Service

 

 

S3에서 파일들을 가져오는 방법은 SQS가 아니라면 예약 스캔이 있다.

예약 스캔은 2가지 종류가 있다.

1회성 스캔

-> 정말 1번만 스캔되며 스캔할 객체의 시기를 지정해서 스캔할 수 있음
(예를 들면 최근 4시간 동안 생성된 파일들만 스캔 가능)

반복 스캔

-> 정기적으로 스캔되며 interval을 지정하여 모든 객체 스캔함 (filter로 prefix 나 suffix로 파일 스캔목록 제어가능)

Interval은 각각 알아서 설정하면 배칭프로세스 돌아가듯이 스캔한다.

 

 

processor

여기서 openpipeline의 진가가 나오는데 log 처리를 해준다는 이점이 있다.

각 서버에서 처리 후 보낸다면 애플리케이션이 변경되었을 때, 각 서버에서 바꿔야 하지만 pipeline으로 모아놓는다면 한 번에 애플리케이션 변경에도 처리가 가능하다.

특히 grok 과 같은 패턴도 무리없이 파싱이 가능하다.

여기선 모든 처리가 가능하다고 봐도 무방하다.

 

 

 

---

 

output

여기선 opensearch로 모니터링하고 싶기에 opensearch vpc, index를 생성하면 된다.

 

 

 

---

결국 모든 것을 종합하면 아래와 같은 파이프라인을 만들 수 있다.

 

 

version: "2"
log-pipeline:
  source:
    s3:
      codec:
        newline:
      compression: "none"
      aws:
        region: "ap-northeast-2"
        sts_role_arn: "arn:aws:iam::accountA-ID:role/pipline-role"
      acknowledgments: true
      scan:
        scheduling:
            interval: PT1M #1분
        buckets:
          - bucket:
              name: dev-bucket/*

      bucket_owners:
        dev-bucket: AccountB-ID 

      # delete_s3_objects_on_read: true # Default is false. This should be set to true only when acknowledgments are set to true
  processor:
    - grok: #미리 패턴 지정
        pattern_definitions:
            DATE_FORM: (%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{HOUR}:%{MINUTE}:%{SECOND}.%{WORD})
            FUNCTION: ([\w.]+)
            HANDLER_NAME: ([\w.]+)
            THREADID2: ([\w_-]+)
            ACCOUNTID: (%{INT})
        match:
          message: ['%{DATE_FORM:logdate}%{LOGLEVEL:loglevel}{GREEDYDATA:msgbody}']
    - date:
        match:
          - key: logdate
            patterns: ["yyyy-MM-dd HH:mm:ss.SSS"]
        destination: "@timestamp"
        output_format: "yyyy-MM-dd'T'HH:mm:ss.SSSXXX"
        source_timezone: "Asia/Seoul"
    - delete_entries:
        with_keys: [ "message" ]
  sink:
    - opensearch:
        hosts: [ "https://vpc-accountA.ap-northeast-2.es.amazonaws.com" ]
        aws:
          sts_role_arn: "arn:aws:iam::accountA-ID:role/pipline-role"
          region: "ap-northeast-2"
        index: "dev-log_%{yyyy.MM.dd}"

 

 

 

요약

Account A에서 통합관리하려고 한다면 Account A -> Account B,C,D 버킷에 대한 Pulling 권한 필요

Multi-Account에선 Bucket owner 사용필요root 계정 직접 사용은 피하기S3가 그렇게 좋은 Source는 딱히 아님