CloudWatch 에이전트를 사용하는 일반적인 시나리오 - Amazon CloudWatch

CloudWatch 에이전트를 사용하는 일반적인 시나리오

다음 섹션에서는 CloudWatch 에이전트에 대한 일반적인 구성 및 사용자 지정 작업을 완료하는 방법을 간략하게 설명합니다.

다른 사용자로 CloudWatch 에이전트 실행

Linux 서버에서 CloudWatch는 기본적으로 루트 사용자로 실행됩니다. 에이전트를 다른 사용자로 실행하려면 CloudWatch 에이전트 구성 파일의 agent 섹션에 있는 run_as_user 파라미터를 사용합니다. 이 옵션은 Linux 서버에서만 사용할 수 있습니다.

이미 루트 사용자로 에이전트를 실행 중인데 다른 사용자를 사용하도록 변경하려면 다음 절차 중 하나를 사용하세요.

Linux를 실행하는 EC2 인스턴스에서 CloudWatch 에이전트를 다른 사용자로 실행하려면
  1. 새 CloudWatch 에이전트 패키지를 다운로드하여 설치합니다. 자세한 내용은 CloudWatch 에이전트 패키지 다운로드 단원을 참조하십시오.

  2. 새 Linux 사용자를 생성하거나 RPM 또는 DEB 파일이 생성한 기본 사용자 cwagent를 사용합니다.

  3. 다음 중 한 가지 방법으로 이 사용자에 대한 자격 증명을 제공합니다.

    • .aws/credentials 파일이 루트 사용자의 홈 디렉터리에 있는 경우 CloudWatch 에이전트를 실행하는 데 사용할 사용자의 자격 증명 파일을 생성해야 합니다. 이 자격 증명 파일은 /home/username/.aws/credentials입니다. 그런 다음 common-config.toml에 있는 shared_credential_file 파라미터 값을 자격 증명 파일의 경로 이름으로 설정합니다. 자세한 내용은 (선택 사항) 프록시 또는 리전 정보에 대한 일반 구성 수정 단원을 참조하십시오.

    • .aws/credentials 파일이 루트 사용자의 홈 디렉터리에 없는 경우 다음 중 하나를 수행할 수 있습니다.

      • CloudWatch 에이전트를 실행하는 데 사용할 사용자의 자격 증명 파일을 생성합니다. 이 자격 증명 파일은 /home/username/.aws/credentials입니다. 그런 다음 common-config.toml에 있는 shared_credential_file 파라미터 값을 자격 증명 파일의 경로 이름으로 설정합니다. 자세한 내용은 (선택 사항) 프록시 또는 리전 정보에 대한 일반 구성 수정 단원을 참조하십시오.

      • 자격 증명 파일을 생성하는 대신 인스턴스에 IAM 역할을 연결합니다. 에이전트는 이 역할을 자격 증명 공급자로 사용합니다.

  4. CloudWatch 에이전트 구성 파일에서 agent 섹션에 다음 줄을 추가합니다.

    "run_as_user": "username"

    필요에 따라 구성 파일을 추가로 수정합니다. 자세한 내용은 CloudWatch 에이전트 구성 파일 생성 단원을 참조하세요.

  5. 사용자에게 필수 권한을 부여하세요. 사용자는 수집할 로그 파일에 대한 읽기(r) 권한이 있어야 하며 로그 파일 경로의 모든 디렉터리에 대해 실행(x) 권한이 있어야 합니다.

  6. 방금 수정한 구성 파일로 에이전트를 시작합니다.

    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
Linux를 실행하는 온프레미스 서버에서 CloudWatch 에이전트를 다른 사용자로 실행하려면
  1. 새 CloudWatch 에이전트 패키지를 다운로드하여 설치합니다. 자세한 내용은 CloudWatch 에이전트 패키지 다운로드 단원을 참조하십시오.

  2. 새 Linux 사용자를 생성하거나 RPM 또는 DEB 파일이 생성한 기본 사용자 cwagent를 사용합니다.

  3. 이 사용자의 자격 증명을 사용자가 액세스할 수 있는 경로(예: /home/username/.aws/credentials)에 저장합니다.

  4. common-config.toml에 있는 shared_credential_file 파라미터 값을 자격 증명 파일의 경로 이름으로 설정합니다. 자세한 내용은 (선택 사항) 프록시 또는 리전 정보에 대한 일반 구성 수정 단원을 참조하십시오.

  5. CloudWatch 에이전트 구성 파일에서 agent 섹션에 다음 줄을 추가합니다.

    "run_as_user": "username"

    필요에 따라 구성 파일을 추가로 수정합니다. 자세한 내용은 CloudWatch 에이전트 구성 파일 생성 단원을 참조하세요.

  6. 사용자에게 필수 권한을 부여하세요. 사용자는 수집할 로그 파일에 대한 읽기(r) 권한이 있어야 하며 로그 파일 경로의 모든 디렉터리에 대해 실행(x) 권한이 있어야 합니다.

  7. 방금 수정한 구성 파일로 에이전트를 시작합니다.

    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path

CloudWatch 에이전트가 희소 로그 파일을 처리하는 방법

희소 파일은 빈 블록과 실제 내용이 모두 포함된 파일입니다. 희소 파일은 블록을 구성하는 실제 null 바이트 대신 빈 블록을 나타내는 간단한 정보를 디스크에 작성하여 디스크 공간을 보다 효율적으로 사용합니다. 이렇게 하면 일반적으로 희소 파일의 실제 크기가 명백한 크기보다 훨씬 작아집니다.

그러나 CloudWatch 에이전트는 희소 파일을 일반 파일 처리 방법과 다르게 처리하지 않습니다. 에이전트가 희소 파일을 읽을 때 빈 블록은 null 바이트로 채워진 “실제” 블록으로 처리됩니다. 이 때문에 CloudWatch 에이전트는 희소 파일의 외관상 크기만큼의 바이트를 CloudWatch에 게시합니다.

희소 파일을 게시하도록 CloudWatch 에이전트를 구성하면 예상보다 높은 CloudWatch 비용이 발생할 수 있으므로 그렇게 하지 않는 것이 좋습니다. 예를 들어 Linux의 /var/logs/lastlog는 일반적으로 희소 파일이므로 CloudWatch에 게시하지 않는 것이 좋습니다.

CloudWatch 에이전트가 수집한 지표에 사용자 지정 측정기준 추가

에이전트에 의해 수집되는 지표에 태그와 같은 사용자 지정 측정기준을 추가하려면 해당 지표를 나열하는 에이전트 구성 파일의 섹션에 append_dimensions 필드를 추가하세요.

예를 들어, 구성 파일의 다음 예제 섹션에서는 stackName의 값이 포함된 Prod라는 사용자 지정 측정기준을 에이전트에 의해 수집된 cpudisk 지표에 추가합니다.

"cpu":{ "resources":[ "*" ], "measurement":[ "cpu_usage_guest", "cpu_usage_nice", "cpu_usage_idle" ], "totalcpu":false, "append_dimensions":{ "stackName":"Prod" } }, "disk":{ "resources":[ "/", "/tmp" ], "measurement":[ "total", "used" ], "append_dimensions":{ "stackName":"Prod" } }

에이전트 구성 파일을 변경할 때마다 에이전트를 다시 시작하여 변경 사항을 적용해야 합니다.

여러 CloudWatch 에이전트 구성 파일

Linux 서버와 Windows 서버 모두에서, 여러 개의 구성 파일을 사용하도록 CloudWatch 에이전트를 설정할 수 있습니다. 예를 들어 인프라의 모든 서버에서 항상 수집하려는 일련의 지표, 로그, 추적을 수집하는 공통 구성 파일을 사용할 수 있습니다. 그런 다음 특정 애플리케이션이나 특정 상황에서 지표를 수집하는 추가 구성 파일을 사용할 수 있습니다.

이렇게 설정하려면 먼저 사용하려는 구성 파일을 생성합니다. 동일한 서버에서 함께 사용할 구성 파일은 파일 이름이 서로 달라야 합니다. 구성 파일을 서버 또는 파라미터 스토어에 저장할 수 있습니다.

fetch-config 옵션을 사용하여 CloudWatch 에이전트를 시작하고 첫 번째 구성 파일을 지정합니다. 실행 중인 에이전트에 두 번째 구성 파일을 추가하려면, 동일한 명령에 append-config 옵션을 사용합니다. 구성 파일에 나열된 모든 지표, 로그, 추적이 수집됩니다. 다음 명령 예제는 파일로 저장된 구성을 사용하는 이 시나리오를 보여줍니다. 첫 행은 infrastructure.json 구성 파일을 사용하여 에이전트를 시작하고, 둘째 행은 app.json 구성 파일을 추가합니다.

다음은 Linux용 명령 예제입니다.

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/tmp/infrastructure.json
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -m ec2 -s -c file:/tmp/app.json

다음은 Windows Server용 명령 예제입니다.

& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\infrastructure.json"
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a append-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\app.json"

다음 예제 구성 파일은 이 기능의 사용을 보여줍니다. 첫 번째 구성 파일은 인프라의 모든 서버에 사용되며, 두 번째 구성 파일은 특정 애플리케이션의 로그만 수집하며, 해당 애플리케이션을 실행하는 서버에 추가됩니다.

infrastructure.json

{ "metrics": { "metrics_collected": { "cpu": { "resources": [ "*" ], "measurement": [ "usage_active" ], "totalcpu": true }, "mem": { "measurement": [ "used_percent" ] } } }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log", "log_group_name": "amazon-cloudwatch-agent.log" }, { "file_path": "/var/log/messages", "log_group_name": "/var/log/messages" } ] } } } }

app.json

{ "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/app/app.log*", "log_group_name": "/app/app.log" } ] } } } }

구성에 추가된 모든 구성 파일은 파일 이름이 서로 달라야 하며 초기 구성 파일의 이름과도 달라야 합니다. 파일 이름이 동일한 구성 파일이 있는 append-config를 에이전트에서 이미 사용 중인 구성 파일로 사용할 경우 추가 명령은 첫 번째 구성 파일에 추가되는 것이 아니라 해당 파일의 정보를 덮어씁니다. 파일 이름이 동일한 두 개의 구성 파일이 서로 다른 파일 경로에 있는 경우에도 마찬가지입니다.

앞의 예는 두 개의 구성 파일을 사용하는 것을 보여주지만, 에이전트 구성에 추가할 수 있는 구성 파일의 수는 제한되지 않습니다. 서버에 있는 구성 파일과 파라미터 스토어에 있는 구성을 함께 사용할 수도 있습니다.

CloudWatch 에이전트가 수집한 지표 집계 또는 롤업

에이전트에 의해 수집되는 지표를 집계하거나 롤업하려면 에이전트 구성 파일의 해당 지표에 대한 섹션에 aggregation_dimensions 필드를 추가하세요.

예를 들어, 다음 구성 파일 조각은 AutoScalingGroupName 측정기준에서 지표를 롤업합니다. 각 Auto Scaling 그룹의 모든 인스턴스에서 지표가 집계되어 전체적으로 표시될 수 있습니다.

"metrics": { "cpu":{...} "disk":{...} "aggregation_dimensions" : [["AutoScalingGroupName"]] }

Auto Scaling 그룹 이름에서 롤업할 뿐 아니라 InstanceIdInstanceType 측정기준 각각의 조합을 따라 롤업하려면 다음을 추가합니다.

"metrics": { "cpu":{...} "disk":{...} "aggregation_dimensions" : [["AutoScalingGroupName"], ["InstanceId", "InstanceType"]] }

대신 지표를 하나의 모음에 롤업하려면 []를 사용합니다.

"metrics": { "cpu":{...} "disk":{...} "aggregation_dimensions" : [[]] }

에이전트 구성 파일을 변경할 때마다 에이전트를 다시 시작하여 변경 사항을 적용해야 합니다.

CloudWatch 에이전트로 고분해능 지표 수집

metrics_collection_interval 필드는 수집되는 지표의 시간 간격을 초 단위로 지정합니다. 이 필드에 60 미만의 값을 지정하면 지표가 고분해능 지표로 수집됩니다.

예를 들어, 모든 지표가 고해상도 지표이며 10초마다 수집되어야 하는 경우 agent 섹션의 metrics_collection_interval에서 글로벌 지표 수집 간격 값으로 10을 지정합니다.

"agent": { "metrics_collection_interval": 10 }

또는 다음 예에서는 cpu 지표는 1초마다 수집되도록 설정하고 다른 모든 지표는 1분마다 수집되도록 설정합니다.

"agent":{ "metrics_collection_interval": 60 }, "metrics":{ "metrics_collected":{ "cpu":{ "resources":[ "*" ], "measurement":[ "cpu_usage_guest" ], "totalcpu":false, "metrics_collection_interval": 1 }, "disk":{ "resources":[ "/", "/tmp" ], "measurement":[ "total", "used" ] } } }

에이전트 구성 파일을 변경할 때마다 에이전트를 다시 시작하여 변경 사항을 적용해야 합니다.

다른 계정에 지표, 로그, 추적 전송

CloudWatch 에이전트가 지표, 로그, 추적을 다른 계정에 전송하도록 하려면 전송 서버의 에이전트 구성 파일에서 role_arn 파라미터를 지정합니다. role_arn 값은 에이전트가 데이터를 대상 계정에 전송할 때 사용하는 대상 계정의 IAM 역할을 지정합니다. 지표 또는 로그를 대상 계정에 전달할 때는 이 역할을 통해 전송 계정이 대상 계정의 해당 역할을 맡을 수 있습니다.

에이전트 구성 파일에 지표를 보낼 때 사용할 문자열, 로그를 보낼 때 사용할 문자열, 추적을 보낼 때 사용할 문자열 등 role_arn 문자열을 별도로 지정할 수도 있습니다.

구성 파일의 agent 섹션 부분에 대한 다음의 예에서는 데이터를 다른 계정에 보낼 때 CrossAccountAgentRole을 사용하도록 에이전트를 설정합니다.

{ "agent": { "credentials": { "role_arn": "arn:aws:iam::123456789012:role/CrossAccountAgentRole" } }, ..... }

또는 다음 예에서는 지표, 로그 및 추적 전송에 사용할 전송 계정에 대해 서로 다른 역할을 설정합니다.

"metrics": { "credentials": { "role_arn": "RoleToSendMetrics" }, "metrics_collected": {....
"logs": { "credentials": { "role_arn": "RoleToSendLogs" }, ....

필요한 정책

에이전트 구성 파일에서 role_arn을 지정할 때 전송 및 대상 계정의 IAM 역할에 특정 정책이 있는지도 확인해야 합니다. 전송 계정과 대상 계정의 역할에는 모두 CloudWatchAgentServerPolicy가 있어야 합니다. 이 정책을 역할에 지정하는 방법에 대한 자세한 내용은 Amazon EC2 인스턴스에서 CloudWatch 에이전트와 함께 사용할 IAM 역할 생성 단원을 참조하세요.

전송 계정의 역할은 다음의 정책을 포함해야 합니다. 역할을 편집할 때 IAM 콘솔의 [권한(Permissions)] 탭에서 이 정책을 추가합니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::target-account-ID:role/agent-role-in-target-account" ] } ] }

대상 계정의 역할에는 전송 계정에서 사용하는 IAM 역할을 인식하도록 다음 정책이 포함되어야 합니다. 역할을 편집할 때 IAM 콘솔의 [신뢰 관계(Trust relationships)] 탭에서 이 정책을 추가합니다. 이 정책을 추가하는 대상 계정의 역할은 CloudWatch 에이전트와 함께 사용하기 위한 IAM 역할 및 사용자 생성에서 생성한 역할입니다. 이 역할은 전송 계정에서 사용한 정책의 agent-role-in-target-account에 지정된 역할입니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::sending-account-ID:role/role-in-sender-account" ] }, "Action": "sts:AssumeRole" } ] }

통합 CloudWatch 에이전트와 이전 CloudWatch Logs 에이전트 간의 타임스탬프 차이

CloudWatch 에이전트는 이전 CloudWatch Logs 에이전트와 비교했을 때 타임스탬프 형식에 대해 다른 기호 집합을 지원합니다. 이러한 차이는 다음 표에 표시됩니다.

두 에이전트 모두에서 지원하는 기호 통합 CloudWatch 에이전트에서만 지원하는 기호 이전 CloudWatch Logs 에이전트에서만 지원하는 기호

%A, %a, %b, %B, %d, %f, %H, %l, %m, %M, %p, %S, %y, %Y, %Z, %z

%-d, %-l, %-m, %-M, %-S

%c,%j, %U, %W, %w

새 CloudWatch 에이전트에서 지원하는 기호의 의미에 대한 자세한 내용은 Amazon CloudWatch 사용 설명서CloudWatch 에이전트 구성 파일: 로그 섹션 단원을 참조하세요. CloudWatch Logs 에이전트에서 지원하는 기호에 대한 자세한 내용은 Amazon CloudWatch Logs 사용 설명서에이전트 구성 파일 단원을 참조하세요.