728x90

엊그제 CKA (Certified Kubenetes Administrator) 자격을 취득했습니다.
AWS Solutinos Architect Associate 취득이 거의 3년전이었으니
3년만에 또 하나의 자격증을 추가하는 <게으름>을 선보였습니다 ㅎㅎ

CKA 취득후 좀 쉴까 했더니, AWS SAA 자격이 11월 만료라고 갱신하라는 알람이 똬악...
그래서 부랴부랴 유데미 Udemy 에서 강의를 검색해 봤습니다. 
SAA 취득할때는 Ryan 님의 강의로 도움을 많이 받았는데, 
Ryan님의 회사 Cloud Guru가 다른 회사에 인수되면서 강의가 다 내려갔습니다 ㅜㅜ

 

고심끝에 고른 강의는 Neal Davis님의 SAP 강의 
일단 20시간 VOD라 짧고 굵게 공부할 수 있을 것 같고 
본인이 운영하는 Digital Cloud Training 이라는 서비스에서
실습할 수 있는 환경을 제공해 주는 것 같아 과감히 선택했습니다. 

가격도 정가 49000원 대비 추석 맞이 할인 71% 적용중이라 
14000원으로 아주아주 착해서... 과감히 결제했습니다 ㅋ
이제 11월까지 한번 또 달려봐야겠습니다!

그나저나 이거 공부하면 또... 번역 작업은 언제하나 싶은 생각이 듭니다. 
아직 챕터 1도 안끝났는데... 역시 잠을 줄여야 합니다 ㅜㅜ
강의를 자세히 살펴보려면 아래 링크로~ 샘플 강의 몇 가지를 들어볼 수 있습니다. 

http://app.ac/83IusLJ03

 

AWS Certified Solutions Architect Professional SAP-C01 2022

Become an AWS Certified Solutions Architect Professional and confidently pass your exam in 30 Days | Study Plan included

www.udemy.com

 

본 포스팅은 제휴마케팅을 통해
소정의 수수료를 지급받을 수 있습니다. 

728x90
728x90

AWS Route53 DNS 요청 실시간 모니터링 시스템 만들기의 세번째 포스팅입니다. 네번째까지 구성되어 있는 컨텐츠이지만 내용들은 짧막 짧막하니 아는 부분은 팍팍~ 넘어가시고 막히는 부분들을 확인해 보시면 좋겠습니다. 이전 글들은 아래와 같습니다.

(1편) Route53 로그 수집을 위한 Logging Group 설정 및 CloudWatch Logs 기본 설정 살펴보기

 

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #1/4

AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라 단가가 매겨지고 (=TTL조정으로 어느정도 비용 통제도 할..

ondemand.tistory.com

 

(2편) Route53 DNS 로그 수집을 위한 ElasticSearch Cluster만들기

 

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #2/4

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #1/4 AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라..

ondemand.tistory.com

 

앞선 두 포스팅을 잘 따라오셨다면 우리는 CloudWatch Logs의 기본적인 설정을 만들었고 AWS ElasticSearch Cluster까지 만드셨을 겁니다. 이제 만들어진 ES Cluster로 로그를 적재하기 위한 Subscription filter 구성 작업을 해보도록 하겠습니다. CloudWatch Logs의 관리 화면으로 이동하여 설정을 시작하겠습니다. 

 

Log Group에 대한 Elasticsearch subscription filter 설정하기

CloudWatch Logs 관리 화면에 진입하면 설정되어 있는 여러 Log Group 목록이 나옵니다. Log Group이 많은 경우 빠른 식별을 위해 제품 명을 Log group 이름에 넣으라고 말씀드렸던 것을 기억하시겠지요? 가이드를 잘 따라오셨다면 검색창에 키워드를 입력하여 쉽게 Log group을 찾을 수 있습니다. 

체크 박스로 로그 그룹을 선택하고 상단 `Actions` 드롭다운 메뉴를 누르겠습니다. 메뉴중 `Subscription filters`를 선택하면 4가지 필터 옵션을 선택하는 팝업이 이어집니다. 우리는 첫번째 항목으로 위치한 `Create Elasticsearch subscription filter`를 선택하겠습니다. 

필터 설정 화면은 크게 세 부분으로 나뉘어져 있습니다. 가장 첫번째 섹션은 `Choose destination`입니다. 이곳에서는 로그를 보낼 목적지를 선택하게 되는데요, 우리가 만든 AWS Elasticsearch Cluster의 도메인 이름을 이곳에 지정하게 됩니다.

AWS상에 여러개의 어카운트를 생성하여 사용하고 있다면 `Another account`를 선택하여 다른 어카운트의 ES Cluster로 로그를 전송하는 것도 가능합니다만 이 포스팅의 범위를 넘어서는 내용이니 설명은 따로 하지 않겠습니다. 우리는 기본 값인 `This account`를 선택한 상태에서 설정 작업을 진행하도록 하겠습니다. 

간혹 "만들어둔 ES Cluster가 목록에 보이지 않아요!" 라는 분들이 계십니다. ES Cluster는 결국은 EC2를 생성하고 Elasticsearch를 설치, 구동하는 것이기 때문에 생성되는데 생각보다 시간이 좀 걸립니다. 경험상 오래 걸릴때는 10분 정도까지 기다리기도 했으니 혹시나 클러스터 목록에 생성한 ES Cluster가 나오지 않는다면 조금 후에 다시 시도해 보시기 바랍니다. 리프레시 버튼이 없으니 뒤로 갔다가 다시 와야 한다는 점도 기억해 두면 좋겠네요.

첫번째 섹션 `Choose destination`에서 ES Cluster를 선택하면 화면이 늘어나면서 Lambda IAM Execution Role을 선택하라는 안내를 만나게 됩니다. 지금까지 여기저기 옮겨 다니면서 설정을 해왔는데 IAM 으로 다시 또 돌아가야 한다니... 이쯤에서 한숨을 한번 내쉬는 것이 정상입니다 ㅎㅎ 다행히도 우측에 Refresh 버튼이 있기 때문에 별도 창으로 IAM 관리 화면을 열고 Route53로그를 ElasticSearch가 잘 받을 수 있도록 Role을 만들어 보도록 하겠습니다.

그런데 갑자기 왠 Lambda일까요? Lambda가 필요한 이유는 간단합니다. Route53의 로그는 CloudWatch Logs를 통해 수집되면 gzip으로 압축된 상태로 저장됩니다. CloudWatch는 ES Cluster로 이 압축파일을 손대지 않고 그대~~로 전달합니다.. 따라서 이를 Unzip하고 ES에 주입하는 단계가 필요하고 이를 위해서 Lambda를 사용합니다. Lambda 코딩에 자신이 없다구요? 다행히도 우리가 Lambda코드를 만들 필요 없이 적당한 권한만 할당되면 미리 준비된 코드가 구동되는 방식입니다.

 

IAM에서 Lambda용 Role 설정하기

IAM 관리 화면을 별도 창으로 열어보겠습니다. 우리는 IAM의 Roles 메뉴에 진입하여 새로운 Role을 작성하도록 하겠습니다. 아래의 이미지에 나온 것처럼 Permission Policy에 우선 `AWSLambdaBasicExecutionRole`을 붙여 주겠습니다. 

(Update 2022.04.22)

AWS Console이 업데이트 되면서 IAM 도 화면이 많이 변경되었습니다.
당황하지 마시고 하나씩~ 보시면서 설정하시면 오히려 더 편리하기도 합니다!


 

`AWSLambdaBasicExecutionRole`이라는 Managed Policy가 추가 되었다면 `Add inline policy`버튼을 눌러 아래의 JSON을 입력합니다. JSON의 내용중 Resource의 Account ID, Region ID, ES Cluster Name등은 각자의 어카운트 환경과 설정에 맞게 수정해서 넣어야 합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "es:*"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:es:#ES가생성된리전#:#ACCOUNT_ID#:domain/#ES도메인명#/*"
        }
    ]
}

퍼미션 설정이 되었다면 이 권한을 갖게될 계정이 신뢰할 수 있는 서비스를 지정하겠습니다. 생성된 Role을 활용하는 주체는 CloudWatch Logs가 됩니다. CloudWatch Log는 Lambda를 실행해야 하기 때문에 Trusted Relationships에는 lambda.amazonaws.com 서비스를 추가해야 합니다. JSON 기준으로 Trust relationship을 보면 아래와 같습니다. 공통 영역이니 그대로 복사해서 붙여 넣어도 무방합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

여기까지 완료되었다면 IAM Role의 설정이 완료된 것입니다. 다시 CloudWatch Logs에서 subscription filter를 선택하던 화면으로 돌아가서 Lambda IAM Execution Role 지정 영역의 Refresh 를 눌러 방금 만든 Role이 나오는지 확인합니다. 저는 기억하기 좋게 cwlogs_route53_to_es 라고 Role 이름을 지었습니다. 생성한 Role을 선택후 다음 섹션으로 넘어가겠습니다. 

(Update 2022.04.22)

Lambda IAM 생성/지정하는 부분이 보이지 않는 경우
아직 OpenSearch 클러스터 생성이 완료되지 않은 것입니다.
조금 기다렸다가 다시 Subscription Filter 를 생성하시기 바랍니다.!


 
아래와 같은 에러가 발생하면 커피 한잔, 담배 한대 피우고 오시기 바랍니다!!!

 

 

로그 포맷 설정

Subscription filters 설정의 두번째 섹션인 `Configure log format and filters`에서는 로그 포맷을 정의하게 됩니다. 정의된 로그 포맷으로 규격을 맞추어 CloudWatch Logs에서 Lambda를 거쳐 ES로 로그가 전달되는 식입니다. 포맷을 별도로 정의하지 않으면 ES에서는 `@message` 컬럼으로만 로그 데이터가 저장됩니다. 따라서 저장된 로그를 조회하거나 다루기 쉽게 하려면 로그 포맷을 지정하는 것이 중요합니다. 

안타깝게도 사전에 정의된 Log format 목록에는 Route53이 CloudWatch Logs를 통해 전달하는 포맷 정보가 기본 항목으로 들어 있지 않습니다. 따라서 Log format으로 `Space Delimited`를 선택하고 2021년 8월 기준 로그에 대해서 만든 아래의 내용을 필터 패턴에 넣어주면 ElasticSearch Cluster에서 사용하기 편한 컬럼을 만들고 저장할 수 있게 됩니다.

[version, timestamp, zone_id, domain, rr_type, error, protocol, region, resolver_ip, edns0]

마지막 섹션인 `Test pattern`에서는 이미 수집되기 시작한 CloudWatch Logs의 샘플 로그를 이용하여 입력한 filter pattern이 데이터를 잘 구분해 내는지 확인해 볼 수 있습니다. 앞선 포스팅에서 확인했던 것처럼 이미 로그가 쌓이고 있을 것이기 때문에 쌓인 로그 중 하나를 선택하여 입력한 필터가 데이터를 잘 구분해 주는지 확인해 보겠습니다. 

데이터가 잘 쌓이고 있고 필터가 적당히 구성되었다면 위 그림에서 볼 수 있는 것처럼 로그를 잘 구분하고 있는 것을 확인할 수 있습니다. 이제 모든 구성이 끝났으니 화면 맨 아래의 `Start streaming`을 눌러 데이터 전송을 시작하겠습니다. 문제가 없다면 성공 메세지와 함께 Subscription filters가 생성된 것을 확인할 수 있습니다.

 

이제 4편에서 모든 구성을 마무리하고 ES 에서 데이터를 조회해 보는 일만 남았습니다.

 

(#4/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

여기까지 잘 따라오셨나요? Subscription filter도 설정했으니 이제 끝이야!! 라고 하기에는 아직 할 일이 조금 남아 있습니다. 필요한 준비는 대충 되었지만 실제로 Elasticsearch에 접근하기 위한 계정

ondemand.tistory.com

 

728x90
728x90
 

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #1/4

AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라 단가가 매겨지고 (=TTL조정으로 어느정도 비용 통제도 할..

ondemand.tistory.com

지난 글에서는 Route53 로그 추출을 위한 사전 작업으로 Route53의 대상 Hosted Zone에 Query Logging을 설정하고 CloudWatch Logs로 로그를 전송하도록 구성을 했습니다. 로그가 정상적으로 CloudWatch Logs로 수집되기 시작했기 때문에, 이번 글에서는 `Subscription filters`를 생성하여 <로그를 구독할 서비스를 설정>하고 CloudWatch Logs의 로그를 해당 서비스가 구독하도록 하겠습니다.

다만 이 작업을 진행하기 전에 Amazon ElasticSearch를 향한 `Subscription filters` 생성시 입력해야 하는 ElasticSearch Cluster 도메인을 먼저 만들고, 해당 도메인을 filter에 지정하는 작업을 해보도록 하겠습니다. 참고로 CloudWatch Logs에서 생성할 수 있는 filter는 4가지 정도가 있습니다만 AWS ElasticSearch로 전송하는 것이 가장 간단합니다. 

(Update 2022.04.21)

AWS의 제품 라인업에서 ElasticSearch가 빠지고 Amazon OpenSearch로 대치되었습니다.
ES의 오픈소스 버전이라고 생각하면 되기 때문에 기본적으로 큰 차이는 없습니다!

 

 


 

Amazon Elasticsearch Cluster 생성하기

`Elasticsearch subscription filter`를 설정하기 위해서 AWS Web Console 에서 `Amazon Elasticsearch`를 선택하고 관리 화면으로 이동하도록 하겠습니다. 제가 사용하는 Account에는 생성된 ES Cluster가 없기 때문에 아래 화면과 같습니다만, 미리 생성되어 있거나 사용중인 ES Cluster가 있다면 목록에 해당 클러스터의 이름이 보일것입니다.

어쨌든 우리는 새로운 클러스터를 만들어야 하기 때문에 `Create domain`을 눌러 새로운 ElasticSearch Amazon OpenSearch Cluster를 구성해 보도록 하겠습니다. 새로운 클러스터 생성시 `도메인`을 지정하게 되고, 이후 CloudWatch에서 subscription filter를 설정할 때도 생성한 도메인 이름을 선택하게 됩니다. 

간단하게 짧은 시간동안 Route53 DNS의 로그를 수집하여 분석해야 하거나 로그 양이 많지 않은 경우라면 클러스터에 사용되는 리소스 규모를 적당한 크기로 선택하는 것이 좋습니다. ElasticSearch 생성의 첫 단계에서 `Development and testing` 타입으로 클러스터를 생성해도 무방할지 생각해 보시기 바랍니다. 설명에 따르면 이 옵션을 쓰면 AWS Region의 가용성 영역을 하나만 사용하게 되고 HA(High Availability)를 보장받기 힘듭니다. 그럼에도 불구하고 우리는 공부를 하는 중이니 간단하게 클러스터를 구성하도록 하겠습니다.

 

 

 

두번째 화면에서는 할당될 Elasticsearch 클러스터의 도메인(Domain)으로 사용할 키워드를 입력합니다. 앞서 이야기 한 것처럼 여기에서 입력한 키워드를 클러스터 선택시 사용하게 됩니다. 이외에도 자동 튜닝, 인스턴스 타입, 스토리지 크기 등을 정하게 됩니다만 크게 필요가 없다면 옵션을 끄는 것이 비용 관점에서 유리합니다. 물론 성능이 좋은 ES 클러스터를 만들어야 한다면 세세하게 설정을 손봐야 하겠지만 일단 로그를 흘리면서 ES로 던지고, ES와 함께 제공되는 Kibana에서 조회해 보는 것이 목적이니 기본 값으로 시험해 봐도 무방하다.

 

 

(Update 2022.04.21)

Amazon OpenSearch 로 제품이 변경되면서 설정 화면이 약간 바뀌었습니다.
아래와 같이 `Deployment type` 선택이 약간 아래로 밀렸고 Name 지정을 먼저 하도록 바뀌었습니다.
순서만 약간 바뀌었을 뿐, 입력하고 선택하는 내용은 대부분 큰 변경이 없습니다.

1.
먼저 Domain Name과 Deployment Type을 선택합니다.
시험중이라면 `Development and testing`을 선택하여 단일 리전에만 배포합니다.




 

다음으로 ES와 Kibana에 접근할 수 있는 접근 권한을 설정해야 합니다. VPC내에서만 접근 가능하게 하거나 Cognito 등을 연동하여 IAM 기반으로 접근할 수 있도록 하는 것이 좋습니다만 시험을 위해서 Public Access로 구성을 진행하고 <Fine-grained access control> 섹션에서 `Create master user`를 눌러 단순하게 ID, Password로 접근하게 하는 방법을 써도 무방합니다. Production용 시스템을 구성한다면 이렇게 구성하지 않는 것이 Job Security에 유리하겠습니다 :-)

 

 

(Update 2022.04.21)

시험적으로 만들어보는 중이니 `Network`는 `Public access`로
`Fine-grained access control`도 `Create master user`를 이용하도록 합시다.
이전 버전과 큰 차이는 없습니다. 




`Access Policy` 역시 단순한 시험을 위해 IP ACL로 설정해 보았습니다. 

이후 AWS의 꽃 중 하나인 Tag 설정 단계가 있지만 시험용 설정을 위해서는 굳이 설정하지 않아도 됩니다. 마지막으로 `Review` 단계에서 입력한 값들을 한번 더 검증하고 문제가 없다면 `Confirm` 버튼을 눌러 ElasticSearch Cluster 생성을 마무리 하도록 하겠습니다.

늘 느끼는 것이지만 AWS를 비롯한 Public Cloud에서는 이것 저것 설정하고 준비해야 할 것들이 꽤 많습니다. 이어지는 글들에서는 CloudWatch Logs에서 Subscription filter를 생성하고 IAM에서 필요로 하는 권한을 설정하는 작업을 진행하도록 하겠습니다. 

 

(#3/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53 DNS 요청 실시간 모니터링 시스템 만들기의 세번째 포스팅입니다. 네번째까지 구성되어 있는 컨텐츠이지만 내용들은 짧막 짧막하니 아는 부분은 팍팍~ 넘어가시고 막히는 부분들을 확

ondemand.tistory.com


AWS 입문자라면 AWS 자격증 공부를 통해 체계적으로 전반적인 AWS 에코시스템을 학습하는 것이 좋습니다. udemy 베스트셀러 강의를 통해 자격증과 AWS 지식을 함께 쌓아보시면 어떨까요?

 

[NEW] Ultimate AWS Certified Cloud Practitioner - 2021

Pass the Amazon Web Services Certified Cloud Practitioner CLF-C01 exam, Practice Exams included with explanations!

www.udemy.com

 

본 포스팅은 제휴마케팅을 통해 소정의 수수료를 지급받을 수 있습니다.

728x90
728x90

여기까지 잘 따라오셨나요? Subscription filter도 설정했으니 이제 끝이야!! 라고 하기에는 아직 할 일이 조금 남아 있습니다. 필요한 준비는 대충 되었지만 실제로 Elasticsearch에 접근하기 위한 계정 매핑 작업이 남아 있습니다. 사실 어떤 계정으로 ES Cluster가 제공하는 Kibana를 쓸 것이냐는 선택이 폭이 무척 넓고 구현 방법도 다양합니다.

특히 보안관점에서 탄탄해지려면 이 포스팅 시리즈의 내용만으로는 부족합니다. 다만 우리의 목적은 빠르게 로그를 적재해 보는 것이기 때문에 앞선 포스팅들에서도 간단하게 IP를 통해 접근을 제어하고 별도로 만든 특정 Master Account로 로그인하도록 했었습니다.

여기에 더하여 AWS가 ES Cluster에 데이터를 적재할 수 있도록 하기 위해서 Lambda를 위해 생성한 IAM Role을 ES Cluster의 권한에 매핑하도록 하겠습니다.

IAM Role을 Kibana에 매핑하기

먼저 Kibana에 생성했던 Master Account로 로그인을 합니다. 좌측 메뉴의 `Open Distro for Elasticsearch > Security` 메뉴에 진입하면 7개의 서브 메뉴가 나옵니다. 그 중 `Roles`를 선택하고 쓰기 권한이 있는 특정한 Role을 찾거나 만들도록 하겠습니다.

간단한 시험을 위해 여기서는 `all_access` Role을 사용하도록 하겠습니다. 네, 보안적으로 좋은 프랙티스는 아닙니다!


ES Cluster의 all_access Role에 Lambda에 부여한 AWS IAM Role의 ARN을 매핑해 줘야 합니다. 잠시 AWS의 IAM 관리 화면으로 넘어가서 Role화면으로 이동하겠습니다.

ES Cluster의 Role인지 IAM의 Role인지 헷갈리지 않도록 유의하시기 바랍니다! IAM 관리 화면에서 앞서 생성한 Lambda용 Role을 찾아 해당 Role의 ARN을 복사하겠습니다.


복사한 ARN을 ES Cluster의 Kibana 화면에서 선택한 쓰기 권한이 있는 Role에 추가해 줍니다. Mapped Users 탭의 Manage mapping 버튼을 누르고 Backend Roles 에 ARN을 추가한다음 Map 버튼을 누릅니다. 에러가 발생하지 않았다면 문제가 없는 것입니다.


이제 거의 끝났습니다. 쓰기 권한이 있는 ES Cluster Role에 IAM Lambda Role이 연결되었기 때문에 로그가 클러스터에 적재되기 시작했을 겁니다. 만약 이렇게 했는데도 로그가 쌓이지 않는다면 권한 부여하는 과정에 잘못된 ARN을 복사해 왔을 가능성이 있습니다. 차근히 화면을 보면서 다시 설정하시면 문제 없을 것이라 생각합니다.

이제 `Index Management`로 이동하여 로그가 들어오는지 확인해 보겠습니다. CloudWatch Logs에서 보내는 로그의 기본 인덱스명은 cwl로 시작합니다. 아래와 같이 cwl로 시작하는 로그들이 들어오는게 보이는지 확인하겠습니다.


이제 좌측 메뉴의 `Kibana` 섹션에서 Discover 메뉴를 선택하고 인덱스 패턴을 만들어 보겠습니다. 여기부터는 ES 혹은 Kibana의 영역이기 때문에 더 자세한 설명은 생략하도록 하겠습니다. 인덱스 패턴까지 만들고 저장했다면 이제 로그를 쿼리할 수 있게 됩니다.

 

 


생성한 인덱스에 우리가 앞서 Subcription filter 생성시 지정했던 것처럼 Field 이름들이 잘 들어오고 있는지도 확인할 수 있습니다. 대략 보니 크게 문제 없어 보입니다. 눈치 채셨겠지만 filter 설정시 사용한 컬럼 이름들이 Kibana의 Field로 사용되기 때문에 적절한 키워드를 사용해 주시면 되겠습니다.


Kibana의 Discover 화면에서 최근 15분간의 데이터를 조회해 봤습니다. 네~ 무척 잘 들어오고 있습니다. 모자이크 처리를 해두긴 했지만 지정한 컬럼별로 데이터가 잘 꽂히고 있는 것을 확인할 수 있었습니다.

아직 실트래픽이 실리고 있지 않아 쿼리 규모가 아주 작습니다만 실제 사용자 트래픽을 수용할 때는 적절히 클러스터의 규모를 조정해 줄 필요가 있습니다.

 

Elasticsearch 에 데이터가 적재되지 않을때 트러블 슈팅

 

이렇게 고생해서 셋업을 했는데 ES 클러스터에 데이터가 적재되지 않는 경우 무척 난감하실겁니다. 리소스들을 다시 정리하는 것도 일이고... 어디서 잘못된 것인지 찾는것도 스트레스입니다.

대부분의 경우 AWS CloudWatch Logs 기술 문서와 ElasticSearch 기술 문서에 내용이 나와 있긴 하지만 그래도 잘 안되는 경우 아래의 문서를 참고하실 수 있습니다.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/es-troubleshoot-cloudwatch-logs/

 

Amazon ES로 스트리밍할 CloudWatch Logs 문제 해결

기본적으로 Amazon CloudWatch는 각 Amazon ES 도메인마다 하나의 AWS Lambda 함수만 생성합니다. 여러 로그 그룹을 설정하여 하나의 Amazon ES 도메인으로 데이터를 인덱싱하는 경우, 여러 로그 그룹이 모두

aws.amazon.com

 


지금까지 4개의 포스팅을 통해 Route53의 DNS 쿼리 로그를 CloudWatch Logs와 Elasticsearch를 활용하여 적재하고 분석하는 환경을 만들어 봤습니다.

DNS 쿼리는 상용 서비스 단계에서 무척 많은 로그를 남기게 됩니다. 때문에 많은 기업들이 on-premise에서 활용하는 서비스용 Authoritative NS에 대해서는 평상시에 로그를 특별히 남기지 않는 경우도 많습니다.

AWS를 통해 Route53을 쓰는 것은 일종의 Managed DNS 또는 Managed GSLB를 쓰는 것ㅇ기 때문에 서버의 로그를 바로 획득하기 어렵습니다.

하지만 (돈을 조금 낸다면.. 속닥속닥..) 로그를 쉽게 적재하고 분석할 수 있는 방법이 제공되고 있으니 필요할 때 유용히 활용할 수 있으면 좋겠습니다. 시리즈 글은 아래의 링크들을 참고하시기 바랍니다!

 

[NEW] Ultimate AWS Certified Cloud Practitioner - 2021

Pass the Amazon Web Services Certified Cloud Practitioner CLF-C01 exam, Practice Exams included with explanations!

www.udemy.com

 

 

(#1/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라 단가가 매겨지고 (=TTL조정으로 어느정도 비용 통제도 할..

ondemand.tistory.com

 

(#2/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #1/4 AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라..

ondemand.tistory.com

 

(#3/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53 DNS 요청 실시간 모니터링 시스템 만들기의 세번째 포스팅입니다. 네번째까지 구성되어 있는 컨텐츠이지만 내용들은 짧막 짧막하니 아는 부분은 팍팍~ 넘어가시고 막히는 부분들을 확

ondemand.tistory.com

 

본 블로그의 글들은 제휴 마케팅을 통해 소정의 수수료를 지급받을 수 있습니다.

728x90

+ Recent posts