로그 아카이브
개요
수집된 모든 로그(인덱싱 여부와 무관)를 나만의 클라우드 스토리지 시스템으로 전달하도록 Datadog 계정을 구성하세요. 로그를 스토리지 최적화된 아카이브에 더 오래 보관해 규정 준수 요구사항을 충족하고, Rehydration이나 Archive Search로 임시 조사를 위한 감사 가능성도 유지할 수 있어요.
Log Archiving & Forwarding 페이지로 이동해 수집된 로그를 나만의 클라우드 호스팅 스토리지 버킷으로 전달하는 아카이브를 설정하세요.
- 아직 하지 않았다면 클라우드 프로바이더용 Datadog 통합을 설정하세요.
- 스토리지 버킷을 만드세요.
- 그 아카이브에
read및/또는write권한을 설정하세요. - 로그를 아카이브로 보내고 아카이브에서 가져오도록 라우팅하세요.
- 암호화, 스토리지 클래스, 태그 같은 고급 설정을 구성하세요.
- 설정을 검증하고 Datadog가 감지할 수 있는 잘못된 구성이 있는지 확인하세요.
가져온 로그를 환경에서 스토리지 최적화된 아카이브로 직접 라우팅하고 싶다면 Observability Pipelines로 로그 아카이브하는 방법을 참고하세요.
다음 메트릭은 재시도 후 성공적으로 보내진 로그를 포함해 성공적으로 아카이브된 로그에 대해 보고해요.
- datadog.archives.logs.bytes
- datadog.archives.logs.count
출처: 문서
본문
아카이브 구성하기
통합 설정하기
{% tab title="AWS S3" %} 아직 구성하지 않았다면 S3 버킷을 보유한 AWS 계정에 AWS 통합을 설정하세요.
- 일반적인 경우 Datadog가 AWS S3와 통합하는 데 사용할 수 있는 역할을 만드는 것이 포함돼요.
- AWS China 계정에는 특히 역할 위임 대신 액세스 키를 사용하세요.
{% /tab %}
{% tab title="Azure Storage" %} 아직 하지 않았다면 새 스토리지 계정을 보유한 구독 내에 Azure 통합을 설정하세요. 여기에는 Datadog가 통합하는 데 사용할 앱 등록 만들기가 포함돼요.
참고: Azure ChinaCloud와 Azure GermanyCloud로의 아카이빙은 지원되지 않아요. Azure GovCloud로의 아카이빙은 Preview로 지원돼요. 접근을 요청하려면 Datadog 지원팀에 문의하세요. {% /tab %}
{% tab title="Google Cloud Storage" %} 아직 하지 않았다면 GCS 스토리지 버킷을 보유한 프로젝트에 Google Cloud 통합을 설정하세요. 여기에는 Datadog가 통합하는 데 사용할 Google Cloud 서비스 계정 만들기가 포함돼요. {% /tab %}
스토리지 버킷 만들기
{% callout %}
다음 Datadog 사이트 사용자를 위한 중요 참고 사항: app.ddog-gov.com, us2.ddog-gov.com
{% alert level="danger" %} 아카이브로 로그를 보내는 것은 Datadog GovCloud 환경 밖으로 나가는 것이며, 이는 Datadog의 통제를 벗어나요. Datadog은 GovCloud 환경을 떠난 로그, 특히 사용자가 FedRAMP, DoD Impact Levels, ITAR, 수출 규정 준수, 데이터 상주 또는 해당 로그에 적용되는 유사 규정과 관련해 가질 수 있는 의무나 요구사항을 포함해 어떤 것에도 책임지지 않아요. {% /alert %}
{% /callout %}
{% tab title="AWS S3" %} AWS 콘솔로 가서 아카이브를 보낼 S3 버킷을 만드세요.
{% callout %}
다음 Datadog 사이트 사용자를 위한 중요 참고 사항: app.ddog-gov.com, us2.ddog-gov.com
{% alert level="danger" %} Datadog 아카이브는 버추얼 호스트 스타일 주소 지정에 의존하는 S3 FIPS 엔드포인트와 통합할 때 점(.)이 있는 버킷 이름을 지원하지 않아요. AWS 문서에서 자세히 알아보세요: AWS FIPS와 AWS Virtual Hosting. {% /alert %}
{% /callout %}
참고:
- 버킷을 공개적으로 읽을 수 있게 만들지 마세요.
- US1, US3, US5 사이트의 경우 리전 간 데이터 전송 수수료와 클라우드 스토리지 비용에 영향을 받는 방법은 AWS Pricing을 참고하세요. 리전 간 데이터 전송 수수료를 관리하려면 스토리지 버킷을
us-east-1에 만드는 것을 고려하세요.
{% /tab %}
{% tab title="Azure Storage" %}
- Azure Portal로 가서 아카이브를 보낼 스토리지 계정을 만드세요. 스토리지 계정에 이름을 지정하고 표준 성능 또는 프리미엄 Block blobs 계정 유형 중 하나를 선택한 뒤 hot 또는 cool 액세스 티어를 선택하세요.
- 해당 스토리지 계정에 컨테이너 서비스를 만드세요. Datadog Archive 페이지에 추가해야 하므로 컨테이너 이름을 기록해 두세요.
참고: 마지막 데이터는 드문 경우(일반적으로 타임아웃)에 다시 써야 하므로 불변성 정책을 설정하지 마세요. {% /tab %}
{% tab title="Google Cloud Storage" %} Google Cloud 계정으로 가서 아카이브를 보낼 GCS 버킷을 만드세요. 객체 액세스 제어 방법 선택에서 Set object-level and bucket-level permissions을 선택하세요.
참고: 마지막 데이터는 드문 경우(일반적으로 타임아웃)에 다시 써야 하므로 보존 정책을 추가하지 마세요. {% /tab %}
권한 설정
logs_write_archive 권한을 가진 Datadog 사용자만 로그 아카이브 구성을 만들고, 수정하고, 삭제할 수 있어요.
{% tab title="AWS S3" %}
-
다음 권한 문으로 정책을 만드세요:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DatadogUploadAndRehydrateLogArchives", "Effect": "Allow", "Action": ["s3:PutObject", "s3:GetObject"], "Resource": [ "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*", "arn:aws:s3:::<MY_BUCKET_NAME_2_/_MY_OPTIONAL_BUCKET_PATH_2>/*" ] }, { "Sid": "DatadogRehydrateLogArchivesListBucket", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": [ "arn:aws:s3:::<MY_BUCKET_NAME_1>", "arn:aws:s3:::<MY_BUCKET_NAME_2>" ] } ] }GetObject와ListBucket권한을 통해 아카이브 검색이 가능해요.PutObject권한은 아카이브 업로드에 충분해요.s3:PutObject와s3:GetObject액션 아래의 리소스 값이/*로 끝나는지 확인하세요. 이 권한은 버킷 안의 객체에 적용되기 때문이에요.
-
버킷 이름을 편집하세요.
-
선택 사항으로 로그 아카이브가 포함된 경로를 지정하세요.
-
새 정책을 Datadog 통합 역할에 연결하세요.
- AWS IAM 콘솔에서 Roles로 이동하세요.
- Datadog 통합이 사용하는 역할을 찾으세요. 기본적으로 DatadogIntegrationRole이라는 이름이며, 조직에서 이름을 바꿨다면 다를 수 있어요. 역할 이름을 클릭해 역할 요약 페이지를 여세요.
- Add permissions를 클릭한 다음 Attach policies를 클릭하세요.
- 위에서 만든 정책의 이름을 입력하세요.
- Attach policies를 클릭하세요.
{% /tab %}
{% tab title="Azure Storage" %}
- Datadog 앱에 스토리지 계정 쓰기·읽기 권한을 부여하세요.
- Storage Accounts 페이지에서 스토리지 계정을 선택하고 Access Control (IAM)으로 간 뒤 Add > Add Role Assignment를 선택하세요.
- Storage Blob Data Contributor라는 역할을 입력하고, Azure와 통합하려고 만든 Datadog 앱을 선택한 뒤 저장하세요.
{% /tab %}
{% tab title="Google Cloud Storage" %}
-
Datadog Google Cloud 서비스 계정에 버킷에 아카이브를 쓸 권한을 부여하세요.
-
Google Cloud IAM Admin 페이지에서 Datadog Google Cloud 서비스 계정 principal을 선택하고 Edit principal을 선택하세요.
-
ADD ANOTHER ROLE을 클릭하고 Storage Object Admin 역할을 선택한 뒤 저장하세요.
Storage Object Admin 역할은 Datadog의 권장 구성이에요. 조직에서 최소 권한 사용자 정의 역할이 필요하다면 아카이브 업로드에 다음 개별 권한이 필요해요:
storage.objects.createstorage.objects.getstorage.objects.liststorage.objects.delete
storage.objects.delete는 Datadog가 버킷의 기존 객체를 덮어쓰는 아카이브 쓰기 재시도를 지원하는 데 필요해요. 멀티파트 업로드 권한(storage.multipartUploads.*)은 필요하지 않아요.
{% /tab %}
로그를 버킷으로 라우팅하기
Log Archiving & Forwarding 페이지로 가서 Archives 탭에서 Add a new archive를 선택하세요.
참고:
logs_write_archive권한을 가진 Datadog 사용자만 이 단계와 다음 단계를 완료할 수 있어요.- Azure Blob Storage로 로그를 아카이빙하려면 App Registration이 필요해요. Azure 통합 페이지의 지침을 참고하고 문서 페이지 오른쪽의 "사이트"를 "US"로 설정하세요. 아카이빙 목적으로만 만든 App Registration에는 "Storage Blob Data Contributor" 역할만 필요해요. 스토리지 버킷이 Datadog Resource로 모니터링되는 구독에 있다면 App Registration이 중복된다는 경고가 표시돼요. 이 경고는 무시해도 돼요.
- 버킷이 지정된 IP로 네트워크 접근을 제한한다면 IP 범위 목록의 웹훅 IP를 허용 목록에 추가하세요.
- US1-FED 및 US2-FED 사이트에서는 Datadog GovCloud 환경 밖의 대상으로 로그를 보내도록 Datadog를 구성할 수 있어요. Datadog은 GovCloud 환경을 떠나는 로그에 대해 책임지지 않아요. 또한 이 로그가 GovCloud 환경을 떠난 후 적용되는 FedRAMP, DoD Impact Levels, ITAR, 수출 규정 준수, 데이터 상주 또는 유사 규정에 관한 의무나 요구사항에 대해서도 Datadog은 책임지지 않아요.
| 서비스 | 단계 |
|---|---|
| Amazon S3 | - S3 버킷에 적합한 AWS 계정·역할 조합을 선택하세요.- 버킷 이름을 입력하세요.선택 사항: 로그 아카이브의 모든 콘텐츠에 대해 접두사 디렉터리를 입력하세요. |
| Azure Storage | - Azure Storage 아카이브 유형과 스토리지 계정에 Storage Blob Data Contributor 역할을 가진 Datadog App의 Azure 테넌트·클라이언트를 선택하세요.- 스토리지 계정 이름과 아카이브용 컨테이너 이름을 입력하세요.선택 사항: 로그 아카이브의 모든 콘텐츠에 대해 접두사 디렉터리를 입력하세요. |
| Google Cloud Storage | - Google Cloud Storage 아카이브 유형과 스토리지 버킷에 쓰기 권한을 가진 GCS 서비스 계정을 선택하세요.- 버킷 이름을 입력하세요.선택 사항: 로그 아카이브의 모든 콘텐츠에 대해 접두사 디렉터리를 입력하세요. |
고급 설정
Datadog 태그
이 선택적 구성 단계를 사용해:
- 아카이브에 모든 로그 태그를 포함하세요(모든 새 아카이브에서 기본 활성화). 참고: 결과 아카이브의 크기가 커져요.
- Restriction Queries 정책에 따라 재수화된 로그에 태그를 추가하세요.
logs_read_data권한을 참고하세요.
최대 스캔 크기 정의
이 선택적 구성 단계를 사용해 로그 아카이브에서 Archive Search 또는 Rehydration에 스캔할 수 있는 로그 데이터의 최대 용량(GB)을 정의하세요.
최대 스캔 크기가 정의된 아카이브의 경우 모든 사용자는 Archive Search 또는 Rehydration을 시작하기 전에 스캔 크기를 추정해야 해요. 추정 스캔 크기가 해당 아카이브에 허용된 것보다 크다면 사용자는 요청의 시간 범위를 줄여야 해요. 시간 범위를 줄이면 스캔 크기가 줄어 Archive Search 또는 Rehydration을 시작할 수 있어요.
참고: Archive Search 중 스캔되는 데이터의 양을 줄이려면 아카이브에 Partition Attributes와 Lookup Attributes를 구성하세요. 파티션 속성은 관련 없는 데이터 세그먼트를 건너뛰어 검색 범위를 좁히고, 룩업 속성은 특정 로그 항목을 정확히 찾아내는 속도를 높여요.
아카이브 파티션 속성
파티션 속성은 공통 필드 값을 기준으로 아카이브된 로그를 그룹으로 구성해요. Archive Search 중 관련 없는 아카이브 세그먼트를 건너뛰고 스캔 용량을 줄이는 광범위한 필터에 사용하세요.
아카이브당 최대 2개의 파티션 속성을 구성할 수 있어요.
- 사용처: 검색 필터로 자주 사용하는
service,source,env,status같은 저카디널리티 속성. - 작동 방식: 같은 파티션 속성 값을 가진 로그는 스토리지에서 함께 위치해요. Datadog는 쿼리와 일치하지 않는 전체 파티션을 건너뛰므로 스캔되는 데이터 양이 크게 줄어요.
아카이브 룩업 속성
룩업 속성은 특정 값을 가진 로그에 대한 빠른 경로를 만들어요. Archive Search로 대상 조사 속도를 높이는 고카디널리티 식별자에 사용하세요.
아카이브당 최대 2개의 룩업 속성을 구성할 수 있어요.
- 사용처:
trace_id,container_id,user_id,request_id같은 고카디널리티 속성. - 작동 방식: Datadog가 쓰기 시점에 이러한 속성의 인덱스를 만들어 Archive Search가 전체 아카이브를 스캔하지 않고도 특정 로그를 정확히 찾을 수 있게 해요.
파티션 vs 룩업 속성
| 파티션 | 룩업 |
|---|---|
| 카디널리티 | 낮음(수십~수백 개 값) |
| 일반적인 속성 | service, source, env, status |
| 도움이 되는 방식 | 쿼리와 일치하지 않는 전체 파티션을 건너뜀 |
| 가장 적합한 용도 | 환경 또는 서비스별 광범위한 필터링 |
| 한도 | 아카이브당 최대 2개 |
최대 검색 성능을 위해 둘을 결합하세요: 파티션 속성이 검색 범위를 관련 데이터 세그먼트로 좁히고, 룩업 속성은 그 세그먼트 안에서 특정 로그를 즉시 찾을 수 있게 해요.
{% callout %}
다음 Datadog 사이트 사용자를 위한 중요 참고 사항: us3.datadoghq.com
방화벽 규칙
{% tab title="Azure storage" %} 방화벽 규칙은 지원되지 않아요. {% /tab %}
{% /callout %}
압축
기본적으로 Datadog는 zstd(Zstandard) 압축(.json.zst)으로 로그를 아카이브해요. 이는 gzip보다 더 나은 압축 비율과 더 빠른 압축 해제 속도를 제공해요. gzip 압축(.json.gz)도 구성할 수 있어요.
압축을 구성하려면 Log Archiving & Forwarding 페이지에서 아카이브를 만들거나 편집할 때 Compression Type을 선택하세요:
- zstd(기본값): 더 나은 압축 비율과 압축 해제 속도. 특히 Archive Search를 계획한다면 새 아카이브에 권장.
- gzip: 널리 지원되며 대부분의 도구와 호환.
참고: 기존 아카이브의 압축 형식을 바꾸는 것은 새 아카이브 파일에만 영향을 줘요. 버킷에 이미 저장된 파일은 원래 형식으로 유지돼요.
스토리지 클래스
{% tab title="AWS S3" %} 아카이브에 스토리지 클래스를 선택하거나 S3 버킷에 수명 주기 구성을 설정해 로그 아카이브를 최적 스토리지 클래스로 자동 전환할 수 있어요.
Archive Search는 다음 스토리지 클래스만 지원해요:
- S3 Standard
- S3 Standard-IA
- S3 One Zone-IA
- S3 Glacier Instant Retrieval
- S3 Intelligent-Tiering(선택적 비동기 아카이브 액세스 티어가 둘 다 비활성화된 경우에만)
아카이브가 다른 스토리지 클래스를 사용한다면 먼저 위 지원되는 스토리지 클래스 중 하나로 이동해야 해요. {% /tab %}
{% tab title="Azure Storage" %} 아카이빙과 Archive Search는 다음 액세스 티어만 지원해요:
- Hot access tier
- Cool access tier
아카이브가 다른 액세스 티어를 사용한다면 먼저 위 지원되는 티어 중 하나로 이동해야 해요. {% /tab %}
{% tab title="Google Cloud Storage" %} 아카이빙과 Archive Search는 다음 액세스 티어를 지원해요:
- Standard
- Nearline
- Coldline
- Archive
{% /tab %}
S3 아카이브용 서버 측 암호화 (SSE)
Datadog에서 S3 아카이브를 만들거나 갱신할 때 선택적으로 Advanced Encryption을 구성할 수 있어요. Encryption Type 드롭다운 아래에는 세 가지 옵션이 있어요:
- Default S3 Bucket-Level Encryption(기본값): Datadog가 S3 버킷의 기본 암호화 설정을 덮어쓰지 않아요.
- Amazon S3 managed keys: S3 버킷의 기본 암호화와 무관하게 Amazon S3 관리 키(SSE-S3)를 사용한 서버 측 암호화를 강제해요.
- AWS Key Management Service: S3 버킷의 기본 암호화와 무관하게 AWS KMS의 고객 관리 키(CMK)를 사용한 서버 측 암호화를 강제해요. CMK ARN을 제공해야 해요.
{% tab title="Default S3 Bucket-Level Encryption" %} 이 옵션을 선택하면 Datadog는 업로드 요청에 어떤 암호화 헤더도 지정하지 않아요. S3 버킷의 기본 암호화가 적용돼요.
S3 버킷의 암호화 구성을 설정하거나 확인하려면:
- S3 버킷으로 이동하세요.
- Properties 탭을 클릭하세요.
- Default Encryption 섹션에서 암호화 유형을 구성하거나 확인하세요. 암호화가 AWS KMS를 사용한다면 유효한 CMK와 CMK에 연결된 CMK 정책이 있는지 확인하세요.
{% /tab %}
{% tab title="Amazon S3 managed keys" %} 이 옵션은 모든 아카이브 객체가 Amazon S3 정리 키를 사용해 SSE_S3로 업로드되도록 보장해요. 이는 S3 버킷의 기본 암호화 설정을 재정의해요. {% /tab %}
{% tab title="AWS Key Management Service" %} 이 옵션은 모든 아카이브 객체가 AWS KMS의 고객 관리 키(CMK)를 사용해 업로드되도록 보장해요. 이는 S3 버킷의 기본 암호화 설정을 재정의해요.
유효한 CMK와 CMK 정책을 만들려면 다음 단계를 완료했는지 확인하세요. 그런 다음 CMK ARN을 제공해 이 암호화 유형을 성공적으로 구성하세요.
- CMK를 만드세요.
- AWS 계정 번호와 Datadog IAM 역할 이름을 적절히 바꿔 다음 내용으로 CMK에 CMK 정책을 연결하세요:
{
"Id": "key-consolepolicy-3",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<MY_AWS_ACCOUNT_NUMBER>:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<MY_AWS_ACCOUNT_NUMBER>:role/<MY_DATADOG_IAM_ROLE_NAME>"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<MY_AWS_ACCOUNT_NUMBER>:role/<MY_DATADOG_IAM_ROLE_NAME>"
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
Datadog에서 Encryption Type으로 AWS Key Management Service를 선택한 후 AWS KMS 키 ARN을 입력하세요. {% /tab %}
검증
아카이브 설정이 Datadog 계정에서 성공적으로 구성되면 처리 파이프라인이 Datadog에 수집된 모든 로그를 강화하기 시작하고, 이후 그 로그는 아카이브로 전달돼요.
다만 아카이브 구성을 만들거나 갱신한 후 다음 아카이브 업로드가 시도되기까지는 수 분이 걸릴 수 있어요. 아카이브가 업로드되는 빈도는 달라질 수 있어요. 15분 후 스토리지 버킷을 다시 확인해 아카이브가 Datadog 계정에서 성공적으로 업로드되고 있는지 확인하세요.
그 후에도 아카이브가 여전히 보류 상태라면 포함 필터를 확인해 쿼리가 유효하고 Live Tail의 로그 이벤트와 일치하는지 확인하세요. Datadog가 설정이나 권한의 의도하지 않은 변경으로 인해 외부 아카이브에 로그를 업로드하지 못하면 해당 로그 아카이브가 구성 페이지에서 강조 표시돼요.
아카이브에 마우스를 올려 오류 세부 정보와 문제 해결을 위한 조치를 확인하세요. Events Explorer에도 이벤트가 생성돼요. 이런 이벤트에 대한 모니터를 만들어 실패를 빠르게 감지·수정할 수 있어요.
여러 아카이브
여러 아카이브가 정의되면 로그는 필터에 따라 첫 번째 아카이브로 들어가요.
아카이브는 신중하게 정렬하는 것이 중요해요. 예를 들어 첫 번째 아카이브를 env:prod 태그로 필터링하고 두 번째 아카이브는 필터 없이(*에 해당) 만든다면 모든 프로덕션 로그는 한 스토리지 버킷이나 경로로 가고 나머지는 다른 쪽으로 갈 거예요.
아카이브 형식
Datadog가 스토리지 버킷으로 전달하는 로그 아카이브는 압축된 JSON 형식이에요. 압축 구성에 따라 아카이브 파일은 zstd(.json.zst, 기본값) 또는 gzip(.json.gz) 압축을 사용해요. 지정한 접두사(없으면 /)를 사용해 아카이브는 아카이브 파일이 생성된 날짜와 시간을 나타내는 디렉터리 구조로 저장돼요. 예:
/my/bucket/prefix/dt=20180515/hour=14/archive_143201.1234.02aafad5-f525-4592-905e-e962d1a5b2f7.json.gz
/my/bucket/prefix/dt=<YYYYMMDD>/hour=<HH>/archive_<HHmmss.SSSS>.<UUID>.json.gz
이 디렉터리 구조는 날짜 기준으로 과거 로그 아카이브를 쿼리하는 과정을 단순화해요.
더 알아보기 (Learn more)
*Logging without Limits는 Datadog, Inc.의 상표입니다.