개요
회사 제품의 감시도구로 Datadog을 고려하게 되었었는데, 멘땅에 헤딩하면서 얻은 지식을 글로써 남겨둡니다. 전체적인 설정방법이라기보다는 공식문서에 없거나 몇몇 주의사항 위주로만 적었습니다.
감시요건은 아래와 같았습니다.
- 서비스 사활감시
- 인프라 감시
- 로그 수집
- 통지
시스템 감시
| 감시대상 | 감시항목 | |
|---|---|---|
| EC2 | prod-1, prod-2 | 사활감시, CPU, 메모리, 용량 |
| RDS | primary, replica | 사활감시, CPU, 메모리 |
로그 수집
| 로그수집대상 | 로그종류 | |
|---|---|---|
| EC2 | prod-1, prod-2 | APP의 error로그, debug로그, nginx의 access, error로그 등 |
이 외에도 여러가지가 있지만 본 글에서는 다루지 않겠습니다.
Datadog 작업내용
시스템 연계
- AWS과 연계하는 설정은 아래 2가지 방법이 있습니다.
1. 자동
AWS CloudFormation
- 리전이 디폴트로 북미로 되어 있기 때문에 현재 사용중인 리전으로 바꿔줄 필요가 있습니다.
- CloudFormation의 스택을 실행함에 있어서, 아래에 나열한 IAM 권한이 필요합니다.
- SecretsManagerReadWrite
- IAMFullAccess
- CloudWatchFullAccess
- CloudWatchLogsFullAccess
- AWSCloudFormationFullAccess
- AWSLambda_FullAccess
- EC2 모니터링 설정을 1분 단위로 변경합니다. (기본설정은 5분)
2. 수동
IAM설정부터 Lambda까지 공식문서를 보면서 설정합니다.
- EC2인스턴스에 datadog-agent를 설치해야합니다.
로그 연계
서비스의 로그 수집
- CloudWatch의 로그를 수집합니다.
- log groups -> subscription filter 에 람다함수를 추가해야 합니다.
- CloudWatch에서 수집하지 않는 로그에 대해서는 수동으로 설정합니다.
- 타겟이 되는 인스턴스에 datadog-agent를 설치합니다.
- /etc/datadog-agent/아래에 있는 설정 파일을 수정하거나 작성합니다. (로그를 수집하고 싶은 서비스에 따라 달라집니다.)
- CloudWatch의 로그는 ELB의 access로그만 연계하도록 인테그레이션의 로그설정을 변경합니다.
nginx의 로그 수집
- 설정파일을 작성한 후, datadog-agent를 재기동합니다.
logs:
- type: file
service: nginx-access-logs
path: /var/log/nginx/access.log
source: nginx
sourcecategory: http_web_access
tags: name:prd-1
- type: file
service: nginx-error-logs
path: /var/log/nginx/error.log
source: nginx
sourcecategory: http_web_access
tags: name:prd-1- 로그 열람 권한을 부여합니다.
sudo chmod 755 /var/log/nginx
sudo chmod 644 /var/log/nginx/*.log여기까지하면 Datadog에 로그가 연계되기 시작합니다.
그러나 CloudWatch 및 Lambda로 연계되는 로그는 기본적으로 그루핑이 되어있지도 않고, 한줄한줄 분해되어 있습니다. 또한 적절한 로그레벨(Error, Warn, Debug 등)이 정해져있지 않습니다.
이제는 Datadog에서 로그를 우리가 원하는 형태로 출력되도록 설정해줘야 합니다.
Datadog 에서 로그 출력방식 설정하기
- 설정은 메뉴의 파이프라인 항목에서 수정합니다.
로그 레벨 취득하기
- 위에서도 언급했듯이, Datadog에서 수신하는 로그의 스테이터스는 기본적으로
info입니다. - 이를 적절하게
Warning,Error등으로 표시하기 위해서는 아래 순서로 진행합니다.
- Logs>Configuration>Pipeline에서 새로운 processor를 작성
- Grok Parser에서 전달할 값을 정규표현으로 추출
- Status Remapperd에서 위에서 취득한 key(여기서는 log_status)로 로그 레벨을 맵핑합니다.
참고문서
여러줄에 걸친 로그를 하나로 묶기 / 불필요한 로그는 필터링하기
https://www.datadoghq.com/blog/multiline-logging-guide/
CloudWatch를 사용하지 않고, dd-agent를 사용하도록 설정합니다.
# 이동
cd /etc/datadog-agent/conf.d
# 로그수집을 ON으로 한다.
sudo vi datadog.yaml
# 서비스 전용 디렉토리를 만든다
sudo mkdir my-service.d
# agent권한 부여
sudo chown dd-agent:dd-agent my-servic.d/
# 기존의 설정을 복붙한다
sudo cp nginx.d/conf.yaml.example my-servic.d/conf.yaml
# 설정파일에서 필요한 부분을 수정하고, 불필요한 부분은 삭제한다
sudo vi my-servic.d/conf.yaml
# agent를 재시작한다.
sudo systemctl restart datadog-agent권한을 dd-agent에 부여할 필요가 있습니다.
이번에 작성한 설정파일은 아래와 같습니다.
logs:
- type: file
path: /var/www/html/logs/error.log
service: error-logs
source: php
tags: name:prd-1
log_processing_rules:
- type: multi_line
name: new_log_start_with_date
pattern: \d{4}\-(0[1-9]|1[012])\-(0[1-9]|[12][0-9]|3[01])
- type: exclude_at_match
name: exclude_missing_exception
patter: [제외할문구1]|[제외할문구2] # |로 복수의 문구를 지정가능여러줄을 그루핑하는 처리와 필터링하는 처리를 작성했습니다.
- service명은 임의로 지정가능 : 로그의 종류를 나타내는 이름으로 하면 관리하기 쉽습니다.
- source는 사용하고 있는 언어로 설정하면, Pipeline에서 자동으로 그 언어의 인테그레이션을 인스톨해주고 설정됩니다.
- 자동으로 생성된 Pipeline은 커스터마이즈가 안 되기 때문에 이번에는 Off로 해두고, 필요한 Pipeline을 만들었습니다.
참고문서
- 서버에서 로그를 수집하는 방법 Host Agent Log collection
- 두 줄 이상의 로그를 하나의 로그로 그룹화하는 방법 Multi-line aggregation
- 로그를 필터링하는 방법 Filter logs
로그의 모니터링 및 통지
1. 인테그레이션에서 SLACK을 설치합니다.
2. 모니터링 설정
- 로그 분석이 가능하고, 분석결과를 슬랙에 통지하는 것이 가능합니다.
- groups를 everything으로 하면 타겟이 되는 로그를 슬랙에 표시하는 것이 가능합니다. (5분 단위로 연계됨)
- 시스템 모니터링
- CPU 사용량 및 데이터베이스 메모리 사용량 등 일정 수치가 넘으면 통지하도록 설정할 수 있습니다.
3. 슬랙 통지
- 시스템 통지와 로그 통지는 슬랙에서 각각 채널을 나눠서 만드는 것이 보기가 좋았습니다.
- 특정한 조건일때만 표시할 내용을 설정하는 것도 가능합니다. (일본회사에 다니고 있어서 일본어가 있는 점 양해바랍니다)
맺음말
공식 문서가 잘 되어 있어서 시간이 충분하다면 찬찬히 읽어보면서 하나씩 해보면 필요한 요건대로 Datadog을 설정하는 것은 어렵지 않을 것입니다.
다만, Datadog에서 제공하는 기능이 워낙 다양하고 강력한 기능들도 많기 때문에, 익숙해지기까지는 시간이 걸릴 것 같습니다.
본 글에서는 제가 직접 설정하면서 얻은 지식을 조금 정리해보았습니다.
도움이 되셨으면 좋겠습니다.
감사합니다.
관련글
Datadog 소개
잘보고갑니다~^^