해당 내용은 DATADOG 공식 문서 및 학습 사이트를 참고하여 작성하였습니다.
1. Metric
1) 정의
- 시스템 또는 애플리케이션의 성능 지표를 나타내는 수치적인 데이터
- CPU 사용률, 메모리 사용량, 네트워크 속도 등
2) 표현 형식
- 주로 수치 값(숫자와 타임스탬프)으로 표현되며, 시계열 데이터베이스에 저장되어 시간에 따른 추이를 분석 가능
3) 용도
- 시스템 및 애플리케이션의 성능을 모니터링하고 추적하는 데 사용됨
- 시간 경과에 따라 그래프로 표현하면 데이터에서 패턴(정상/비정상)이 보이게 됨
4) Metrics Summary
- 지정된 기간 내 Datadog에 수집된 Metiric 항목 목록이 표시됨
- 실제 값은 없으며 메타 데이터만 제공
5) Metrics Explorer
- 지정된 기간 내 쿼리 편집기를 통해 Metrics 검색 가능
- 두 개 이상의 쿼리 비교 가능
2. Log
1) 정의
- 시스템, 응용 프로그램 또는 서비스에서 발생하는 이벤트와 정보를 기록하는 텍스트 기반의 데이터
- 특정 이벤트, 오류, 경고, 디버그 정보 등
2) 표현 형식
- 주로 텍스트 형태로 기록되며, 로그 메시지에는 사람이 읽을 수 있는 형태의 정보가 포함
3) 용도
- 애플리케이션의 동작을 추적하고 디버깅하거나, 보안 사건을 모니터링하고 오류를 식별하는 등 다양한 용도로 사용됨
4) Log Explorer
- [Logs] 에서 확인 가능하며, 필터링을 통해 원하는 로그 검색 가능
- Time range: 검색 원하는 시간 선택 가능
- Search bar: 쿼리를 사용하여 로그 검색 및 필터링 가능
> Fields: 필드 집계를 사용하면 쿼리 필터와 일치하는 모든 로그가 로그 패싯의 값에 따라 그룹으로 집계됨
> Patterns: 패턴 집계를 사용하면 유사한 구조의 메시지가 있고 동일한 서비스에 속하며 동일한 상태를 갖는 로그가 함께 그룹화됨. 따라서 시각적으로 보기 좋게 오류 탐지 가능
> Transactions: 트랜잭션은 사용자 세션 또는 여러 마이크로 서비스에서 처리된 요청과 같은 일련의 이벤트 인스턴스에 따라 인덱싱된 로그를 집계함
- Facet panel: Host, Service, Status 등으로 로그 필터링 가능
- Log side panel: 로그 클릭 시 나오는 세부 정보 출력창이며 태그별로 구분됨
※ 로그 검색 방법
- DATE, HOST, SERVICE와 같은 기본 사항은 @ 없이 검색(service:*)
- CONTENT(로그 메시지)에서 문자열 검색할 때는 "" 사용("*")
- Event Attributes 내 특정 속성 검색할 때는 @ 포함(@filename:*)
3. Trace
1) 정의
- 애플리케이션에서 발생하는 트랜잭션의 분산 추적 데이터를 의미
- 여러 서비스 간의 호출 및 작업 흐름을 시각적으로 표시하고 각 단계에서 소요된 시간 등의 성능 데이터 등
2) 용도
- Trace 데이터는 APM(Application Performance Monitoring) 도구를 통해 시각화됨
- 애플리케이션의 특정 트랜잭션 경로에서 발생하는 지연(병목 현상)이나 성능 문제를 식별 가능
3) Span
- 분산 시스템에서의 특정 작업 또는 이벤트를 나타내는 단위
- Trace는 여러 Span들의 집합으로, 하나의 요청 또는 트랜잭션을 의미
4. Monitoring
1) 대상
- 주로 Metric 데이터가 대상이 됨(로그도 가능)
- 성능(CPU 사용률, 메모리, 디스크 등), 보안(비정상적인 서비스 사용 등), 제품 사용량(고객의 플랫폼 사용량 등)
2) 알림(Alert)
- 특정 대상에 대해 설정한 조건을 초과하는 경우 알림 발생
- [Monitors] 탭에서 새 모니터 생성 > Metric/Logs/APM/... 데이터 선택 > 알림 종류 선택 > Metric 정의 > 임계값 선택 > 알림 제목, 메시지, 수신자 선택
※ 알림 메시지 생성 방법
> {{ }} 로 변수 지정해서 작성할 수 있음
> Ex) User: {{log.attributes.userIdentity.userName}}
> 만약 alert의 경우에만 알림받고 싶은 경우에는 {{#is_alert}} {{/is_alert}} 내에 작성하기
3) 활용 예시
- CPU 사용률 Monitor:
> 대상: 서버의 CPU 사용률 메트릭 데이터
> 조건: CPU 사용률이 특정 임계값을 초과할 경우
> 액션: 경고 생성 또는 자동 조치
- 응답 시간 Monitor:
> 대상: 특정 애플리케이션의 응답 시간 메트릭 데이터
> 조건: 응답 시간이 기준을 초과할 경우
> 액션: 경고 생성 또는 자동 조치
- 가용성 Monitor:
> 대상: 특정 서비스의 가용성 메트릭 데이터
> 조건: 서비스의 가용성이 특정 기간 동안 특정 임계값 아래로 떨어질 경우
> 액션: 경고 생성 또는 자동 조치
5. USM(Universal Service Monitoring)
1) 정의
- 코드를 계측할 필요 없이 전체 기술 스택에 대한 서비스 상태 측정 항목 보기를 제공
2) 활성화 조건
- Linux의 경우 서비스가 컨테이너에서 실행되고 있을 것
- Windows에서 IIS를 사용하는 경우 서비스가 가상 머신에서 실행되고 있을 것
- Datadog 에이전트는 서비스와 함께 설치될 것
- 통합 서비스 태그 지정을 위한 env 태그를 배포에 적용할 것
6. SLOs(Service Level Objectives)
1) 정의
- 서비스가 특정 시간 동안 얼마나 신뢰할 수 있는지를 나타내는 목표 지표
2) 용도
- 서비스의 성능을 정량화하고, 서비스 품질을 측정하여 사용자 경험 향상
3) SLOs
- [Service Mgmt > SLOs] 에서 생성 가능
- 생성 후 Alerts에서 알람도 생성하여 모니터링 가능
기타
앱에서 로그 수집 실습
- 로그 수집 활성화
- Datadog Agent를 통해 로그 수집 활성화
- DD_LOGS_ENABLED=true #에이전트 컨테이너에서 로그 수집을 활성화
- DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true #다른 모든 컨테이너에서 로그 수집을 활성화
- 에이전트에 대한 특정 로그 수집 구성 매개변수 지정
- com.datadoghq.ad.logs:'[{"소스":"에이전트","서비스":"에이전트"}]' #로그 수집을 위한 구성 매개변수를 설정. 여기에서 에이전트 로그의 소스 및 서비스 태그를 지정 가능 source는 로그를 보내는 통합을 정의하는 속성 ex) nginx service는 로그를 소유한 서비스 이름 ex) cloudtrail
Log Explore
- Fields : 필드 집계를 사용하면 쿼리 필터와 일치하는 모든 로그가 로그 패싯의 값에 따라 그룹으로 집계됨.
- Patterns : 패턴 집계를 사용하면 유사한 구조의 메시지가 있고 동일한 서비스에 속하며 동일한 상태를 갖는 로그가 함께 그룹화됨. 따라서 시각적으로 보기 좋게 오류 탐지 가능
- Transactions : 트랜잭션은 사용자 세션 또는 여러 마이크로 서비스에서 처리된 요청과 같은 일련의 이벤트 인스턴스에 따라 인덱싱된 로그를 집계함.
Dashboard
- 로그 이벤트를 시각화하여 시간 경과에 따른 이벤트 변화를 표시 가능
Monitors
- 지정된 유형의 로그가 지정된 기간동안 사용자 정의 임계값을 초과하면 경고하도록 로그 모니터 생성 가능
ex)
- logs("/login/auth_proc").index("*").rollup("count").by("@http._x_forwarded_for").last("5m") > 100
이에 대한 액션으로 @sns-datadog-monitor-alarm 등 설정 가능
Logs > Configuration > Pipelines 탭
- 수집 후 인덱싱 전 (모든 로그가 처리되기 전) 로그의 필터링된 하위 집합에 적용되는 정렬된 process의 집합
- 결과적으로 로그는 표준 이름 규칙과 통일된 구조 및 속성을 갖게 되므로 지정된 태그와 함께 속성을 사용하여 Datadog를 통해 로그 데이터 검색 쿼리를 작성할 수 있음
- 통합 파이프라인의 프로세서 세부 정보는 편집할 수 없으므로 필드가 회색으로 표시되며 view만 가능
- ex) ssh 이벤트에서 IP 주소 추출
- New Pipeline 생성하기 생성된 파이프라인 확장하여 Add Processor 클릭 Grok Parser 선택 프로세서 이름 설정하고 로그 파싱 클릭 로그 샘플 중 원하는 로그 메시지 클릭(publickey 포함) 생성하고 Log > Explore 에서 로그 검색 시 sshd 활동에서 IP 주소도 출력되어 @network.client.ip에 배치됨
Logs > Configuration > Indexs 탭
- 모든 Datadog 수집 로그가 동등한 가치를 가지는 것은 아님. 로그 인덱스를 사용하면 보존 기간, 할당량, 사용 모니터링 및 빌링이 다른 가치 그룹의 로그로 필터링하여 더 중요한 로그에 대한 비용과 관심을 집중시킬 수 있음.
- 인덱스를 만들 때 인덱스 필터, 보존 기간 및 일일 할당량을 설정할 수 있음. 인덱스 필터와 일치하는 모든 로그가 인덱스를 통해 흐르게됩니다. 여러 인덱스가있는 경우 일치하는 필터링 기준을 가진 인덱스 목록의 첫 번째 인덱스를 통해 로그가 흐름
- 특정 인덱스를 필터링하여 조사 및 분석 가능. 로그 탐색기의 인덱스 편집기에서 라이브 인덱스에서 인덱스를 선택 가능. 인덱싱 된 로그를 페이스팅 검색, 패턴, 분석, 대시 보드 및 모니터링에 사용 가능.
Logs > Configuration > Archives 탭
- 사용하면 사용자가 제공한 클라우드 스토리지(AWS S3, GCP, Azure)에 로그를 장기 보존하고 필요할 때 빠르게 재생성 가능
Logs > Configuration > Data Access 탭
- 수집하는 로그 데이터 및 사용자 역할에 따라 로그에 대한 역할 기반 읽기 액세스를 설정 가능
- UNRESTRICTED ACCESS에 있는 역할들은 기본 역할들이며, New Query 생성하여 제한된 엑세스 생성 가능 ex) env:intro-to-log 쿼리 적용하여 저장하면, 해당 쿼리만 볼 수 있는 역할 만들 수 있음
Security > Cloud SIEM > Detection Rule 탭
- 리스트된 감지 규칙을 확인 가능
- Datadog 'default' 아이콘이 있는 규칙은 기본 규칙에 해당
- 사용자 정의 규칙 생성 가능 ex) 규칙 생성
- New rule 클릭 Detection method를 'Threshold'로 설정 (알람은 정의된 기준치보다 높을 때 트리거) Query 옆 연필 아이콘을 클릭하여 쿼리명 설정 'service:nginx AND -@http.status_code:200' 쿼리 입력(nginx에서 200을 제외한 쿼리 의미) Set rule cases 에서 Trigger에 '쿼리명 > 임계치' 입력하고 트리거 이름, 심각도, 알림 설정 Say what's happening에서 규칙 이름과 설명 입력 가능 Add tag를 통해 태그 입력하고 Save Rule 클릭 생성한 규칙은 Security > Signal에서 규칙에 대한 신호 확인 가능
Security > Setup & Configuration
- Notification Rules 탭 : 감지 규칙이 작동할 때 알람을 받을 수 있도록 하는 규칙 생성 가능
- Detection Rules 탭 : 특정 트리거에 대해 알림을 받기 위해 감지 규칙 생성 가능
Security > Security Signals 탭
- 감지규칙에 해당하는 로그가 있는 경우 확인 가능
- Event Explore에서 알림 확인 가능
