ELK to AWS: 간편한 로그 관리

게시 됨: 2022-03-11

Elasticsearch는 광범위한 데이터에서 정보를 빠르게 검색하도록 설계된 강력한 소프트웨어 솔루션입니다. Logstash 및 Kibana와 결합하여 비공식적으로 명명된 "ELK 스택"을 형성하며 로그 데이터를 수집, 임시 저장, 분석 및 시각화하는 데 자주 사용됩니다. 서버에서 Logstash로 로그를 보내는 Filebeat와 Elasticsearch에 저장된 데이터에 대해 실행된 일부 분석 결과를 기반으로 경고를 생성하는 Elastalert와 같은 몇 가지 다른 소프트웨어가 일반적으로 필요합니다.

ELK 스택은 강력하지만…

로그 관리를 위해 ELK를 사용한 경험은 매우 다양합니다. 한편으로는 매우 강력하고 기능의 범위가 상당히 인상적입니다. 반면에 설정이 까다롭고 유지 관리가 까다로울 수 있습니다.

사실 Elasticsearch는 일반적으로 매우 훌륭하고 다양한 시나리오에서 사용할 수 있습니다. 검색 엔진으로도 사용할 수 있습니다! 로그 데이터 관리에 특화되어 있지 않기 때문에 이러한 데이터 관리의 특정 요구 사항에 맞게 동작을 사용자 지정하려면 더 많은 구성 작업이 필요합니다.

ELK 클러스터를 설정하는 것은 꽤 까다로웠고 마침내 시작하고 실행하기 위해 여러 매개변수를 가지고 놀아야 했습니다. 그런 다음 구성하는 작업이 수행되었습니다. 제 경우에는 구성해야 할 다섯 가지 소프트웨어가 있었습니다(Filebeat, Logstash, Elasticsearch, Kibana 및 Elastalert). 문서를 읽고 다음 요소와 통신하지 않는 체인의 한 요소를 디버그해야 했기 때문에 이것은 상당히 지루한 작업이 될 수 있습니다. 마침내 클러스터를 가동하고 실행한 후에도 여전히 일상적인 유지 관리 작업(패칭, OS 패키지 업그레이드, CPU, RAM 및 디스크 사용량 확인, 필요에 따라 약간의 조정 등)을 수행해야 합니다.

Logstash 업데이트 후 전체 ELK 스택이 작동을 멈췄습니다. 자세히 살펴보니 ELK 개발자들이 어떤 이유로 구성 파일에서 키워드를 변경하고 복수화하기로 결정했습니다. 그것이 마지막 빨대였으며 더 나은 솔루션을 찾기로 결정했습니다(적어도 내 특정 요구 사항에 대한 더 나은 솔루션).

Apache와 다양한 PHP 및 노드 앱에서 생성된 로그를 저장하고 이를 구문 분석하여 소프트웨어의 버그를 나타내는 패턴을 찾고 싶었습니다. 내가 찾은 해결책은 다음과 같습니다.

  • 대상에 CloudWatch 에이전트를 설치합니다.
  • 로그를 CloudWatch 로그로 전달하도록 CloudWatch 에이전트를 구성합니다.
  • 로그를 처리하기 위해 Lambda 함수 호출을 트리거합니다.
  • 패턴이 발견되면 Lambda 함수는 Slack 채널에 메시지를 게시합니다.
  • 가능한 경우 모든 단일 로그에 대해 Lambda 함수를 호출하지 않도록 CloudWatch 로그 그룹에 필터를 적용하십시오(비용이 매우 빠르게 증가할 수 있음).

그리고 높은 수준에서 그게 다야! 유지 관리가 필요 없이 잘 작동하고 추가 노력 없이도 잘 확장되는 100% 서버리스 솔루션입니다. 서버 클러스터에 비해 이러한 서버리스 솔루션의 장점은 많습니다.

  • 본질적으로 클러스터 서버에서 주기적으로 수행하는 모든 일상적인 유지 관리 작업은 이제 클라우드 공급자의 책임입니다. 모든 기본 서버는 사용자가 알지 못하는 사이에 패치, 업그레이드 및 유지 관리됩니다.
  • 더 이상 클러스터를 모니터링할 필요가 없으며 모든 확장 문제를 클라우드 공급자에게 위임합니다. 실제로 위에서 설명한 것과 같은 서버리스 설정은 사용자가 아무것도 하지 않아도 자동으로 확장됩니다!
  • 위에서 설명한 솔루션은 구성이 덜 필요하며 클라우드 공급자가 구성 형식에 주요 변경 사항을 가져올 가능성은 거의 없습니다.
  • 마지막으로, 일부 CloudFormation 템플릿을 작성하여 모든 것을 코드로서의 인프라로 넣는 것은 매우 쉽습니다. 동일한 작업을 수행하여 전체 ELK 클러스터를 설정하려면 많은 작업이 필요합니다.

Slack 경고 구성

그럼 이제 자세하게 들어가 볼까요! 경고 엔지니어를 위한 Slack 웹훅이 포함된 이러한 설정을 위한 CloudFormation 템플릿이 어떻게 생겼는지 살펴보겠습니다. 먼저 모든 Slack 설정을 구성해야 하므로 자세히 살펴보겠습니다.

 AWSTemplateFormatVersion: 2010-09-09 Description: Setup log processing Parameters: SlackWebhookHost: Type: String Description: Host name for Slack web hooks Default: hooks.slack.com SlackWebhookPath: Type: String Description: Path part of the Slack webhook URL Default: /services/YOUR/SLACK/WEBHOOK

이를 위해 Slack 작업 공간을 설정해야 합니다. 추가 정보는 이 Slack용 WebHooks 가이드를 확인하세요.

Slack 앱을 만들고 수신 후크를 구성하면 후크 URL이 CloudFormation 스택의 매개변수가 됩니다.

 Resources: ApacheAccessLogGroup: Type: AWS::Logs::LogGroup Properties: RetentionInDays: 100 # Or whatever is good for you ApacheErrorLogGroup: Type: AWS::Logs::LogGroup Properties: RetentionInDays: 100 # Or whatever is good for you

여기에서 두 개의 로그 그룹을 만들었습니다. 하나는 Apache 액세스 로그 용이고 다른 하나는 Apache 오류 로그 용입니다.

이 기사의 범위를 벗어나기 때문에 로그 데이터에 대한 수명 주기 메커니즘을 구성하지 않았습니다. 실제로는 보존 기간을 단축하고 일정 기간이 지난 후 이를 Glacier로 이동하는 S3 수명 주기 정책을 설계하고 싶을 것입니다.

액세스 로그를 처리하는 Lambda 함수

이제 Apache 액세스 로그를 처리할 Lambda 함수를 구현해 보겠습니다.

 BasicLambdaExecutionRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

여기에서 Lambda 함수에 연결되어 직무를 수행할 수 있는 IAM 역할을 생성했습니다. 실제로 AWSLambdaBasicExecutionRole 은 이름에도 불구하고 AWS에서 제공하는 IAM 정책입니다. Lambda 함수가 해당 그룹 내에서 로그 그룹과 로그 스트림을 생성한 다음 자체 로그를 CloudWatch Logs로 보낼 수 있도록 허용합니다.

 ProcessApacheAccessLogFunction: Type: AWS::Lambda::Function Properties: Handler: index.handler Role: !GetAtt BasicLambdaExecutionRole.Arn Runtime: python3.7 Timeout: 10 Environment: Variables: SLACK_WEBHOOK_HOST: !Ref SlackWebHookHost SLACK_WEBHOOK_PATH: !Ref SlackWebHookPath Code: ZipFile: | import base64 import gzip import json import os from http.client import HTTPSConnection def handler(event, context): tmp = event['awslogs']['data'] # `awslogs.data` is base64-encoded gzip'ed JSON tmp = base64.b64decode(tmp) tmp = gzip.decompress(tmp) tmp = json.loads(tmp) events = tmp['logEvents'] for event in events: raw_log = event['message'] log = json.loads(raw_log) if log['status'][0] == "5": # This is a 5XX status code print(f"Received an Apache access log with a 5XX status code: {raw_log}") slack_host = os.getenv('SLACK_WEBHOOK_HOST') slack_path = os.getenv('SLACK_WEBHOOK_PATH') print(f"Sending Slack post to: host={slack_host}, path={slack_path}, url={url}, content={raw_log}") cnx = HTTPSConnection(slack_host, timeout=5) cnx.request("POST", slack_path, json.dumps({'text': raw_log})) # It's important to read the response; if the cnx is closed too quickly, Slack might not post the msg resp = cnx.getresponse() resp_content = resp.read() resp_code = resp.status assert resp_code == 200

그래서 여기에서는 Apache 액세스 로그를 처리하는 Lambda 함수를 정의하고 있습니다. Apache의 기본값인 공통 로그 형식을 사용하지 않는다는 점에 유의하십시오. 다음과 같이 액세스 로그 형식을 구성했습니다(그리고 기본적으로 JSON 형식의 로그를 생성하므로 더 쉽게 처리할 수 있습니다).

 LogFormat "{\"vhost\": \"%v:%p\", \"client\": \"%a\", \"user\": \"%u\", \"timestamp\": \"%{%Y-%m-%dT%H:%M:%S}t\", \"request\": \"%r\", \"status\": \"%>s\", \"size\": \"%O\", \"referer\": \"%{Referer}i\", \"useragent\": \"%{User-Agent}i\"}" json

이 Lambda 함수는 Python 3로 작성되었습니다. CloudWatch에서 보낸 로그 라인을 가져와서 패턴을 검색할 수 있습니다. 위의 예에서는 5XX 상태 코드를 생성한 HTTP 요청을 감지하고 Slack 채널에 메시지를 게시합니다.

패턴 감지 측면에서 원하는 모든 작업을 수행할 수 있으며, Logstash 또는 Elastalert 구성 파일의 정규식 패턴과 달리 이것이 진정한 프로그래밍 언어(Python)라는 사실은 복잡한 패턴 인식을 구현할 수 있는 많은 기회를 제공합니다. .

개정 관리

개정 제어에 대한 간략한 설명: 이와 같은 작은 유틸리티 Lambda 함수에 대한 CloudFormation 템플릿에 코드를 인라인으로 두는 것이 상당히 수용 가능하고 편리하다는 것을 알았습니다. 물론 많은 Lambda 함수 및 계층이 포함된 대규모 프로젝트의 경우 이것이 가장 불편할 것이고 SAM을 사용해야 할 것입니다.

 ApacheAccessLogFunctionPermission: Type: AWS::Lambda::Permission Properties: FunctionName: !Ref ProcessApacheAccessLogFunction Action: lambda:InvokeFunction Principal: logs.amazonaws.com SourceArn: !Sub arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:*

위의 내용은 CloudWatch Logs에 Lambda 함수를 호출할 수 있는 권한을 부여합니다. 주의 사항: SourceAccount 속성을 사용하면 SourceArn 과 충돌이 발생할 수 있습니다.

일반적으로 Lambda 함수를 호출하는 서비스가 동일한 AWS 계정에 있을 때는 포함하지 않는 것이 좋습니다. SourceArn 은 어쨌든 다른 계정이 Lambda 함수를 호출하는 것을 금지합니다.

 ApacheAccessLogSubscriptionFilter: Type: AWS::Logs::SubscriptionFilter DependsOn: ApacheAccessLogFunctionPermission Properties: LogGroupName: !Ref ApacheAccessLogGroup DestinationArn: !GetAtt ProcessApacheAccessLogFunction.Arn FilterPattern: "{$.status = 5*}"

구독 필터 리소스는 CloudWatch Logs와 Lambda 간의 링크입니다. 여기서 ApacheAccessLogGroup 으로 전송된 로그는 위에서 정의한 Lambda 함수로 전달되지만 필터 패턴을 통과하는 로그만 전달됩니다. 여기에서 필터 패턴은 일부 JSON을 입력으로 예상하고(필터 패턴은 '{'로 시작하고 '}'로 끝남) "5"로 시작하는 필드 status 가 있는 경우에만 로그 항목과 일치합니다.

이는 Apache에서 반환된 HTTP 상태 코드가 500 코드인 경우에만 Lambda 함수를 호출한다는 것을 의미합니다. 이는 일반적으로 매우 나쁜 일이 진행되고 있음을 의미합니다. 이렇게 하면 Lambda 함수를 너무 많이 호출하지 않아 불필요한 비용을 피할 수 있습니다.

필터 패턴에 대한 자세한 내용은 Amazon CloudWatch 설명서에서 찾을 수 있습니다. CloudWatch 필터 패턴은 확실히 Grok만큼 강력하지는 않지만 꽤 좋습니다.

구독이 생성되기 전에 CloudWatch Logs가 실제로 Lambda 함수를 호출할 수 있도록 하는 DependsOn 필드에 유의하십시오. 이것은 단지 케이크에 불과하며 실제 시나리오에서와 같이 아마도 가장 불필요할 것입니다. Apache는 아마도 적어도 몇 초 전에 요청을 수신하지 않을 것입니다(예: EC2 인스턴스를 로드 밸런서와 연결하고 로드를 가져오기 위해) EC2 인스턴스의 상태를 정상으로 인식하는 밸런서).

오류 로그를 처리하는 Lambda 함수

이제 Apache 오류 로그를 처리할 Lambda 함수를 살펴보겠습니다.

 ProcessApacheErrorLogFunction: Type: AWS::Lambda::Function Properties: Handler: index.handler Role: !GetAtt BasicLambdaExecutionRole.Arn Runtime: python3.7 Timeout: 10 Environment: Variables: SLACK_WEBHOOK_HOST: !Ref SlackWebHookHost SLACK_WEBHOOK_PATH: !Ref SlackWebHookPath Code: ZipFile: | import base64 import gzip import json import os from http.client import HTTPSConnection def handler(event, context): tmp = event['awslogs']['data'] # `awslogs.data` is base64-encoded gzip'ed JSON tmp = base64.b64decode(tmp) tmp = gzip.decompress(tmp) tmp = json.loads(tmp) events = tmp['logEvents'] for event in events: raw_log = event['message'] log = json.loads(raw_log) if log['level'] in ["error", "crit", "alert", "emerg"]: # This is a serious error message msg = log['msg'] if msg.startswith("PHP Notice") or msg.startswith("PHP Warning"): print(f"Ignoring PHP notices and warnings: {raw_log}") else: print(f"Received a serious Apache error log: {raw_log}") slack_host = os.getenv('SLACK_WEBHOOK_HOST') slack_path = os.getenv('SLACK_WEBHOOK_PATH') print(f"Sending Slack post to: host={slack_host}, path={slack_path}, url={url}, content={raw_log}") cnx = HTTPSConnection(slack_host, timeout=5) cnx.request("POST", slack_path, json.dumps({'text': raw_log})) # It's important to read the response; if the cnx is closed too quickly, Slack might not post the msg resp = cnx.getresponse() resp_content = resp.read() resp_code = resp.status assert resp_code == 200

이 두 번째 Lambda 함수는 Apache 오류 로그를 처리하고 심각한 오류가 발생한 경우에만 Slack에 메시지를 게시합니다. 이 경우 PHP 알림 및 경고 메시지는 경고를 트리거할 만큼 심각한 것으로 간주되지 않습니다.

다시 말하지만, 이 함수는 Apache 오류 로그가 JSON 형식일 것으로 예상합니다. 다음은 내가 사용한 오류 로그 형식 문자열입니다.

 ErrorLogFormat "{\"vhost\": \"%v\", \"timestamp\": \"%{cu}t\", \"module\": \"%-m\", \"level\": \"%l\", \"pid\": \"%-P\", \"tid\": \"%-T\", \"oserror\": \"%-E\", \"client\": \"%-a\", \"msg\": \"%M\"}"
 ApacheErrorLogFunctionPermission: Type: AWS::Lambda::Permission Properties: FunctionName: !Ref ProcessApacheErrorLogFunction Action: lambda:InvokeFunction Principal: logs.amazonaws.com SourceArn: !Sub arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:* SourceAccount: !Ref AWS::AccountId

이 리소스는 CloudWatch Logs에 Lambda 함수를 호출할 수 있는 권한을 부여합니다.

 ApacheErrorLogSubscriptionFilter: Type: AWS::Logs::SubscriptionFilter DependsOn: ApacheErrorLogFunctionPermission Properties: LogGroupName: !Ref ApacheErrorLogGroup DestinationArn: !GetAtt ProcessApacheErrorLogFunction.Arn FilterPattern: '{$.msg != "PHP Warning*" && $.msg != "PHP Notice*"}'

마지막으로 Apache 오류 로그 그룹에 대한 구독 필터를 사용하여 CloudWatch Logs를 Lambda 함수와 연결합니다. "PHP Warning" 또는 "PHP Notice"로 시작하는 메시지가 있는 로그가 Lambda 함수에 대한 호출을 트리거하지 않도록 하는 필터 패턴에 유의하십시오.

최종 생각, 가격 및 가용성

비용에 대한 마지막 한마디: 이 솔루션은 ELK 클러스터를 운영하는 것보다 훨씬 저렴합니다. CloudWatch에 저장된 로그는 S3와 동일한 수준으로 가격이 책정되며 Lambda는 프리 티어의 일부로 매월 100만 회의 호출을 허용합니다. 트래픽이 보통에서 많은 웹사이트(CloudWatch Logs 필터를 사용한 경우)에 충분할 것입니다. 특히 코딩을 잘했고 오류가 너무 많지 않은 경우에 그렇습니다!

또한 Lambda 함수는 최대 1,000개의 동시 호출을 지원합니다. 이 글을 쓰는 시점에서 이것은 변경할 수 없는 AWS의 하드 제한입니다. 그러나 위의 함수에 대한 호출은 약 30-40ms 동안 지속될 것으로 예상할 수 있습니다. 이것은 다소 많은 트래픽을 처리할 수 있을 만큼 충분히 빨라야 합니다. 워크로드가 너무 강력하여 이 한도에 도달한 경우 향후 기사에서 다루게 될 Kinesis 기반의 더 복잡한 솔루션이 필요할 수 있습니다.

Toptal 엔지니어링 블로그에 대한 추가 정보:

  • AWS SSM을 사용한 SSH 로깅 및 세션 관리