Amazon CloudWatch Agent와 collectd 시작하기

이 글은 AWS Cloud Operations & Migrations Blog에 게시된 Getting Started with CloudWatch agent and collectd by Helen Ashton and Kevin Lewin을 한국어 번역 및 편집하였습니다.

관찰 가능성(Observability)은 워크로드의 상태, 사용량, 성능 및 고객 경험을 이해하는 데 도움이 됩니다. 관찰 가능성은 사고 감지 및 사고 해결 지원부터 새로운 기능이 사용자 및 워크플로에 미치는 영향을 이해하는 데 이르기까지 다양한 사용 사례를 지원할 수 있습니다. 하지만 올바른 솔루션을 설정하기 위해선 상황에 맞는 올바른 데이터를 수집할 수 있어야 합니다. 이 게시물에서는 Linux 인스턴스에서 수집할 수 있는 지표들을 추가하기 위해 collectd 와 Amazon CloudWatch 에이전트를 사용하는 방법을 살펴보겠습니다.

우선 Amazon Elastic Compute Cloud(Amazon EC2) Linux 인스턴스에서 collectd 및 CloudWatch 에이전트의 기본 설정 방법을 살펴 보겠습니다. CloudWatch 에이전트는 Amazon EC2 인스턴스에서 시스템 수준 지표와 로그를 수집할 수 있으며, collectd의 추가 지표 수집도 지원합니다. 여러분은 수집한 데이터를 통해 리소스의 성능과 사용량을 이해할 수 있고 고객과 워크로드를 지원하기 위한 데이터 기반 결정을 내리는 데 도움을 받을 수 있습니다.

시작하는 데 도움이 되도록 열린 파일 수 데이터를 수집하는 간단한 예를 사용하고, 여러 서버에서 이 과정을 관리할 수 있도록 AWS Systems Manager (SSM)를 사용하여 collectd와 CloudWatch 에이전트를 설치 및 구성하는 방법을 살펴보겠습니다. 그런 다음 여러분과 관련된 지표를 살펴보고 그에 따라 collectd를 구성할 수 있습니다.

Amazon CloudWatch 개요

Amazon CloudWatch는 AWS 리소스와 AWS에서 실행하는 애플리케이션을 실시간으로 모니터링합니다. CloudWatch를 사용하여 지표, 로그, 추적을 수집하고 경보를 설정하고 합성 검사를 생성하는 등의 작업을 수행할 수 있습니다. 수집한 정보를 통해 성능, 오류, 디버깅 또는 근본 원인 분석과 같은 영역과 관련된 데이터를 관찰하고 검증하고 경고할 수 있습니다.

많은 AWS 서비스는 기본 지표를 CloudWatch로 전송하므로 추가 구성이나 비용 없이 리소스에 대한 통찰력을 얻을 수 있습니다. 예를 들어 Amazon EC2 서비스에는 CPU 사용률, 디스크 읽기/쓰기, 네트워크 지표를 포함한 다양한 지표가 있습니다.

CloudWatch 에이전트를 사용하여 Amazon EC2 인스턴스에 대한 추가 지표를 수집할 수 있습니다. 이러한 추가 지표에는 추가 CPU 지표와 디스크 및 메모리에 대한 지표가 포함됩니다. 또한 collectd를 활용하여 CloudWatch 에이전트만으로는 사용할 수 없는 지표를 수집할 수도 있습니다.

collectd란 무엇인가요?

collectd를 사용하면 Linux OS에서 시스템 및 애플리케이션 성능 지표를 수집할 수 있습니다. collectd는 오픈 소스 프로젝트이며 데이터 수집을 위한 데몬을 제공합니다. collectd를 구성하면 CloudWatch 에이전트가 그 데이터를 캡처하여 CloudWatch 서비스로 보낼 수 있습니다. collectd 데이터가 CloudWatch에 있으면 데이터를 검색, 집계, 시각화 및 경보를 만들거나 다른 CloudWatch 데이터와 결합할 수 있습니다. CloudWatch 에이전트가 이미 수집할 수 있는 시스템 지표를 collectd의 추가 지표와 결합하면 시스템과 애플리케이션을 더 효과적으로 모니터링하고 분석하고 문제를 해결할 수 있습니다.

이 예에서는 Amazon EC2에서 collectd 및 CloudWatch를 사용하는 데 중점을 두지만, collectd와 CloudWatch 에이전트는 모두 하이브리드 및 온프레미스 환경에서 사용할 수 있습니다. 기존 온프레미스 환경에서는 CPU 온도, 물리적 디스크 전원 사이클, 불량 섹터와 같은 하드웨어 수준 지표를 수집할 수 있습니다. 지표들은 JVM 관련 모니터링과 같은 더 높은 수준의 추상화에서도 활용될 수도 있습니다.

수집하려는 지표를 지정하려면 적절한 collectd 플러그인을 구성하면 됩니다. 네트워킹이나 Apache, Java, MySQL과 같은 기술 중심 플러그인을 포함한 광범위한 영역을 포괄하는 100개 이상의 플러그인을 사용할 수 있습니다. 예를 들어, Apache 플러그인은 수신된 요청 수 또는 전송된 바이트 수에 대한 데이터를 수집할 수 있습니다. 프로세스 플러그인은 특정 이름의 프로세스 수 또는 열린 파일 수(Linux에만 해당)에 대한 데이터를 수집할 수 있습니다. 사용자 플러그인을 사용하면 현재 시스템에 로그인한 사용자 수를 수집할 수 있습니다. 여기에서는 fhcount 플러그인을 사용하여 열린 파일 수에 대한 데이터를 수집합니다. 일반적으로 열린 파일 수에는 제한이 있으며, 한 프로세스에 열린 파일이 너무 많으면 다른 프로세스에 영향을 미칠 수 있습니다.

CloudWatch와 collectd 함께 사용하기

Amazon EC2 인스턴스에 collectd와 CloudWatch 에이전트를 설치/구성하기 위해 Systems Manager State Manager 및 Parameter Store를 사용합니다. 이를 통해 여러 서버에 대해 개별적으로 로그인할 필요 없이 설치/구성을 한 번에 실행할 수 있습니다. State Manager를 사용하면 설정을 다시 적용할 일정을 설정하여 CloudWatch 에이전트를 최신 상태로 유지하거나 구성이 제거된 경우 다시 적용하거나 원하는 일정에 따라 새 구성을 적용할 수 있습니다. 이를 원하지 않는 경우에도 일정 없이 State Manager를 사용할 수 있습니다.

Systems Manager를 활용한 워크플로우는 다음과 같습니다:

단계 1: 권한: Amazon EC2 역할에 CloudWatch와 Systems Manager 권한 추가
단계 2: collectd와 CloudWatch 에이전트의 구성 생성
단계 3: 구성을 Parameter Store에 저장
단계 4: State Manager를 사용하여 collectd와 CloudWatch 에이전트를 설치/구성
단계 5: 지표가 수집되는지 확인
단계 6: 경보/대시보드 생성

그림 1. collectd 및 CloudWatch 에이전트 구성을 위한 워크플로를 보여주는 다이어그램

단계 1: 권한

Amazon EC2 인스턴스의 AWS Identity and Access Management (IAM) 역할의 일부로 다음 정책이 필요합니다.
CloudWatchAgentServerPolicy: CloudWatch 에이전트가 CloudWatch에 데이터를 기록할 수 있도록 합니다.
AmazonSSMManagedInstanceCore: 핵심 Systems Manager 기능을 위해 필요합니다.
콘솔에서 작업하는 방법에 대한 안내는 Amazon EC2 인스턴스에서 CloudWatch 에이전트와 함께 사용할 IAM 역할 생성 문서를 참조하십시오.

단계 2: 구성 생성

시작하기 쉽도록 collectd와 CloudWatch 에이전트의 기본 구성을 사용합니다. 구성을 수정하여 추가 데이터를 수집할 수 있습니다. 두 가지 구성에 대해 설명하고 이를 Systems Manager Parameter Store에 저장하는 방법을 안내드리겠습니다.

단계 2.1: collectd 구성

collectd의 경우, 원하는 플러그인에 대한 구성 세부 정보를 생성해야 합니다. 여기서는 네트워크와 fhcount 플러그인을 구성합니다. 또한 수집 간격에 대한 전역 값으로 60초로 설정할 수 있습니다. collectd 문서에서 제공되는 다양한 전역 옵션을 살펴보시기 바랍니다.

Interval 60

LoadPlugin network
<Plugin network>
  Server "127.0.0.1" "25826"
</Plugin>

LoadPlugin fhcount
<Plugin fhcount>
  ValuesAbsolute true
  ValuesPercentage true
</Plugin>

네트워크 플러그인을 사용하면 collectd가 네트워크를 통해 지표를 수집할 수 있습니다. CloudWatch 에이전트는 기본적으로 호스트 127.0.0.1 및 UDP 포트 25826에 collectd 서버를 띄워서 데이터를 수집합니다.
네트워크 플러그인의 SecurityLevel 속성을 설정할 수도 있습니다. 기본값은 None입니다. 이 값을 변경하면 CloudWatch 에이전트 구성에서 collectd에 대한 보안 수준도 변경해야 합니다. CloudWatch 에이전트 구성을 설명할 때 이에 대해 다시 설명하겠습니다.

fhcount 플러그인은 Linux에서 사용 중인 파일 핸들, 사용되지 않은 파일 핸들 및 총 파일 핸들 수에 대한 통계 정보를 제공합니다. 데이터를 절대값, 백분율 또는 둘 다로 수집할 수 있습니다.

이 때 CloudWatch 내에서 고유한 지표를 얼마나 많이 수집하느냐에 따라 지표 데이터에 대한 비용이 발생하므로 필요한 것만 수집하고 지불하도록 구성하는 것이 중요합니다.

ValuesAbsolute = true로 설정하면 사용 중인 파일 핸들/사용되지 않은 파일 핸들/최대 값에 대한 3개의 지표를 생성합니다.
ValuesPercent = true로 설정하면 사용 중인 파일 핸들 및 사용되지 않은 파일 핸들의 백분율에 대한 2개의 지표를 생성합니다.

구체적인 플러그인의 구성 옵션에 대해서는 collectd 문서를 참조하십시오.

단계 2.2: CloudWatch 에이전트 구성

CloudWatch 에이전트의 구성은 세 가지 주요 섹션으로 나뉩니다: agent, metrics 그리고 logs입니다. collectd 지표 데이터를 수집하기 위해서는 metrics 섹션만 필요합니다.

collectd 지표 데이터를 수집하려면 metrics_collected 필드 내에서 collectd 속성을 사용하도록 지정해야 합니다.

{
    "metrics": {
        "metrics_collected": {
            "collectd": {
                "collectd_security_level": "none",
                "metrics_aggregation_interval": 60
            }
        }
    }
}

collectd 섹션에서는 아무것도 지정할 필요는 없지만, 우리는 다음 항목들을 지정하겠습니다:

collectd_security_level: collectd의 네트워크 플러그인 구성을 통해 데이터는 기본적으로 암호화되지 않은 상태로 전송됩니다. 그러나 CloudWatch 에이전트는 기본적으로 암호화된 데이터를 요구합니다. 데이터를 수집하려면 두 가지가 일치해야 하며, “none” 값을 사용하여 CloudWatch 에이전트에게 데이터가 암호화되지 않을 것임을 알려줍니다.
참고: collectd의 네트워크 플러그인 구성에서 SecurityLevel 속성에 값을 지정하는 경우, CloudWatch 에이전트의 collectd_security_level 속성도 적절하게 변경해야 합니다.
metrics_aggregation_interval: collectd 구성에서 지정한 빈도에 관계없이, CloudWatch 에이전트에게 데이터를 60초마다 하나의 데이터 포인트로 집계하도록 지시합니다. 이 값을 0으로 설정하여 집계를 하지 않을 수도 있습니다.

단계 3: 구성을 Parameter Store에 저장

이제 구성 내용을 Systems Manager Parameter Store에 저장하겠습니다. State Manager를 사용하여 설정을 수행할 때, Parameter Store에서 구성 세부 정보를 가져올 것입니다. 이를 통해 필요할 때 중앙에 구성을 저장하고 쉽게 재사용하고 업데이트할 수 있습니다.

위의 두 가지 구성에 대해 각각 Parameter Store에 매개변수를 생성합니다.

Systems Manager 콘솔에서 Parameter Store를 선택한 다음, 파라미터 생성(Create parameter)을 선택합니다.

각 파라미터에 이름을 지정합니다. 예를 들어:
- collectd-config
- cloudwatch-config-forcollectd
계층(Tier)을 표준(Standard)으로 선택하고, 유형(Type)을 문자열(String)로 선택합니다.
(위에서 구성한) 적절한 구성을 값(Value) 상자에 복사하여 붙여 넣습니다.
파라미터 생성(Create parameter)을 선택하여 저장합니다.

더 자세한 내용은 AWS 문서의 Systems Manager 파라미터 생성을 참조하십시오.

Systems Manager Parameter Store의 이름 지정에 대한 참고: 파라미터에 사용하는 이름은 Amazon EC2 IAM 역할의 권한에 따라 달라집니다. Amazon EC2 인스턴스에 두 가지 정책이 필요합니다.

CloudWatchAgentServerPolicy 정책은 “AmazonCloudWatch-“로 시작하는 파라미터를 읽을 수 있게 합니다.
AmazonSSMManagedInstanceCore 정책은 어떤 파라미터 이름이든 읽을 수 있게 합니다.

두 정책이 모두 사용되므로 파라미터에 대한 이름을 자유롭게 지정할 수 있습니다.

단계 4: State Manager 를 사용하여 설치/구성

Systems Manager를 사용하여 collectd의 설치 및 구성을 수행하기 전에, 수동으로 이 작업을 어떻게 수행하는지 간단히 살펴보겠습니다. 이렇게 하면 수동 명령과 Systems Manager 설정 간의 관련성을 확인할 수 있습니다. Systems Manager에서 미리 정의된 문서가 있기 때문에 CloudWatch 에이전트에 대한 수동 구성은 설명하지 않겠습니다.

collectd: 수동 구성

수동으로 collectd를 설치하는 경우, Amazon EC2 인스턴스에 ssh로 로그인하고 다음 명령을 실행합니다:

collectd를 설치합니다.
sudo amazon-linux-extras install collectd
이 명령은 Amazon Linux 2를 대상으로 하며, 다른 배포판은 다른 설치 방법을 가질 수 있습니다.
위에서 작성한 구성을 사용하여 파일 /etc/collectd.conf의 내용을 바꿉니다.
sudo vi /etc/collectd.conf
그리고 위에서 작성한 collectd 구성을 사용합니다.
collectd 에이전트 시작합니다.
sudo systemctl start collectd.service

이 방법을 사용하면 단일 서버에서 수동으로 collectd를 설정할 수 있지만, 여러 서버가 있는 경우나 업데이트를 자동화하려는 경우에는 적합하지 않습니다. 이 경우 Systems Manager의 일부인 State Manager 연결을 사용할 수 있습니다.

단계 4.1: collectd: State Manager 연결

필요한 인스턴스에서 설정을 실행하기 위해 State Manager 연결을 생성합니다. 연결을 생성하자마자 실행되게 됨을 유의하십시오.

State Manager 콘솔에서 연결 생성(Create association)을 선택하고 다음 값을 사용합니다:

이름: LinuxCollectdSetup (원하는 이름을 사용할 수 있습니다)
문서: AWS-RunShellScript (라디오 버튼을 사용하여 선택하며 문서 이름을 클릭하지 않도록 주의합니다)

파라미터:

Commands

sudo amazon-linux-extras install collectd
sudo systemctl stop collectd.service
sudo echo '{{ssm:collectd-config}}' > /etc/collectd.conf
sudo systemctl start collectd.service

대상 선택: 원하는 인스턴스를 선택합니다.
일정 지정: 적절히 선택 (나중에 수정할 수 있습니다.)

나머지는 기본값으로 두십시오.

Commands 섹션 내에서 수동으로 수행하는 것과 거의 같은 명령을 실행합니다. 다만 두 가지 차이점이 있습니다:

2번째 줄: 이미 collectd가 있고 실행 중인 경우에도 새 구성이 적용되도록 서비스 중지가 추가되었습니다. 따라서 나중에 collectd 구성을 업데이트하기 위해 동일한 연결을 사용할 수 있습니다.
3번째 줄: Amazon EC2 인스턴스에서 구성 파일을 수동으로 편집하는 대신 Parameter Store의 collectd-config 파라미터의 값을 가져와 내용을 /etc/collectd.conf 파일에 배치합니다.

연결 생성을 선택하십시오. State Manager 연결 목록으로 돌아가게 되며, 생성한 연결(LinuxCollectdSetup)을 찾아 상태가 “대기 중(Pending)”에서 “성공(Success)”으로 변경될 때까지 기다립니다 (상태 변경을 보려면 연결 테이블을 새로 고치십시오).

참고:

상태가 실패로 표시될 경우: 몇 가지 일반적인 문제는 이 게시물의 다음 단계 섹션에서 강조되어 있습니다.
권한: State Manager 연결이 Parameter Store에서 읽을 수 있도록 하려면 ssm:GetParameters 권한이 필요합니다. 이 동작은 인스턴스가 Systems Manager와 함께 작동하려면 필요한 AmazonSSMManagedInstanceCore 정책에 포함되어 있습니다.
인스턴스 선택: 이 연결을 생성하는 일환으로 포함시키려는 인스턴스를 지정했습니다. 이를 수동으로 선택하거나 태그, 리소스 그룹 또는 모두 선택하여 수행할 수 있습니다. 나중에 서버를 어떻게 업데이트할 것인지(환경 별, 애플리케이션 별 등)를 고려하여 해당 인스턴스 그룹에 적합한 태그를 선택하십시오. 마찬가지로 인스턴스를 언제 업데이트할지 고려하여 적절한 일정을 설정하거나 수동으로 연결을 실행하도록 선택하십시오.

단계 4.2: CloudWatch 에이전트: State Manager 연결

Systems Manager에는 CloudWatch 에이전트의 설치 및 구성 지침이 포함된 두 가지 미리 정의된 문서가 있습니다. 이로 인해 이 작업을 수행하는 데 필요한 명령어들을 걱정할 필요가 없고 어떤 문서를 사용해야 하는지와 CloudWatch 에이전트 구성이 어디에 저장되는지만 알면 됩니다.

별도의 문서를 사용하여 프로세스를 더욱 더 세밀하게 제어할 수 있도록 설치 및 구성 단계마다 별도의 연결을 생성하겠습니다.

먼저 CloudWatch 에이전트 설치를 위한 연결을 생성합니다.
State Manager 콘솔에서 다음 값을 사용하여 생성합니다:

이름: LinuxCloudWatchInstall (원하는 이름을 사용할 수 있습니다)
문서: AWS-ConfigureAWSPackage
파라미터:
1. Action: Install
2. Name: AmazonCloudWatchAgent
대상 선택: 원하는 인스턴스 선택
일정 지정: 적절한 대로 선택 (나중에 수정할 수 있습니다)

연결 생성을 선택합니다. State Manager 연결 목록으로 돌아가게 되며, 생성한 연결(LinuxCloudWatchInstall)을 찾아 상태가 “대기 중(Pending)”에서 “성공(Success)”으로 변경될 때까지 기다립니다.

CloudWatch 에이전트 구성을 위한 또 다른 연결을 생성합니다.
State Manager 콘솔에서 다음 값을 사용하여 생성합니다:

이름: LinuxCloudWatchConfig (원하는 이름을 사용할 수 있습니다)
문서: AmazonCloudWatch-ManageAgent
파라미터:
1. Action: configure
2. Mode: ec2
Optional Configuration Source: ssm
Optional Configuration Location: cloudwatch-config-forcollectd (또는 CloudWatch 에이전트 구성을 위해 이전에 생성한 파라미터의 이름)
Optional Restart: yes
대상 선택: 원하는 인스턴스 선택
일정 지정: 적절한 대로 선택 (나중에 수정할 수 있습니다)

연결 생성을 선택하십시오. 이전과 마찬가지로 State Manager 연결 목록으로 돌아가게 되며, 생성한 연결(LinuxCloudWatchConfig)을 찾아 상태가 “대기 중(Pending)”에서 “성공(Success)”으로 변경될 때까지 기다립니다.

단계 5: 지표가 수집되는지 확인

CloudWatch 지표는 네임스페이스, 측정기준 및 지표 이름의 고유한 조합으로 정의됩니다. CloudWatch 에이전트에서 온 지표는 CWAgent라는 사용자 정의 네임스페이스 아래에 나타납니다(기본 Amazon EC2 지표는 AWS/EC2 네임스페이스 아래에 있습니다). 이를 CloudWatch 에이전트 구성의 metrics 섹션 내에서 namespace 속성을 사용하여 제어할 수 있습니다.

CloudWatch 콘솔로 이동하고 지표(Metrics) > 모든 지표(All Metrics)를 선택합니다. CWAgent라는 사용자 정의 네임스페이스를 선택합니다. 다음으로 지표가 가지는 다양한 측정기준(지표가 그룹화되는 방법)을 볼 수 있습니다. 이 예제에서는 host, type, type_instance가 표시됩니다. 이 안에 수집된 모든 collectd 지표를 볼 수 있습니다. 만약 지표가 표시되지 않으면 몇 분을 기다린 후 콘솔을 새로 고쳐보십시오.

한 개 이상의 지표를 선택하여 지표의 그래프를 볼 수 있습니다. 아래에서는 두 개의 EC2 인스턴스에 대한 열린 파일 수가 선택되었습니다. 이 지표는 지표 이름(Metric name)=collectd_fhcount_value, type=file_handles, type_instance=used입니다. 그런 다음 작업(Actions) > 대시보드에 추가(Add to dashboard)에서 이를 CloudWatch 대시보드에 추가할 수 있습니다.

그림 2: 그래프용으로 선택된 지표가 표시되는 CloudWatch 콘솔

AWS 문서에는 CloudWatch 대시보드에서 지표 데이터를 그래프로 표시하는 데 대한 자세한 정보가 포함되어 있습니다. 또한 지표 숫자 위젯, 게이지 위젯, 지표 라인(시간 차트) 위젯 및 텍스트 위젯 등을 생성하는 방법 등을 포함한 CloudWatch 대시보드에서 위젯을 생성하고 작업하는 방법으로부터 CloudWatch 대시보드의 다른 기능에 대해 더 알아볼 수 있습니다.

단계 6: 경보/대시보드 생성

이제 CloudWatch에 데이터가 있으므로 다른 지표들과 마찬가지로 사용할 수 있습니다. 예를 들어 데이터를 쿼리하고 집계할 수 있으며, 경보를 설정하고 대시보드에서 데이터를 시각화할 수 있습니다.

CloudWatch 대시보드에서는 지표 수학 표현식 및 Metrics Insights 쿼리를 사용하여 데이터의 시각화를 생성할 수 있습니다. CloudWatch 지표 데이터를 검색, 집계 및 결합하는 방법을 알아보려면 AWS의 Amazon CloudWatch 지표 사용 문서를 참조하십시오.

그림 3: collectd에서 수집된 열린 파일 데이터에 대한 여러 시각적 표현을 표시하는 CloudWatch 대시보드

CloudWatch 대시보드에 사용할 몇 가지 예제 쿼리를 보여드리겠습니다.

이 모든 예제에서는 지정된 호스트의 열린 파일 개수를 나타내는 지표 이름(Metrics name)=collectd_fhcount_value, type=file_handles, type_instance=used로 구성된 지표를 사용합니다. 다른 지표를 사용하여 유사한 쿼리를 작성할 수도 있습니다.
지표 수학 표현식 쿼리에는 300초 또는 5분의 기간을 사용하는 점을 참고하세요.

전체 인스턴스에서의 최대 열린 파일 수.
Metric Insights
SELECT MAX(collectd_fhcount_value) FROM SCHEMA(CWAgent, host, type, type_instance) WHERE type = 'file_handles' AND type_instance = 'used'
지표 수학 표현식
MAX(SEARCH('{CWAgent, host, type, type_instance} MetricName="collectd_fhcount_value" type="file_handles" type_instance="used"', 'Maximum', 300))
위 대시보드에서 이 데이터는 세 가지 다른 디스플레이 스타일로 표시됩니다 – 스파크라인이 있는 숫자 위젯, 라인 차트, 경고 임계값이 1500으로 설정된 게이지 위젯입니다.

각 인스턴스의 최대 열린 파일 수.
최대 값은 각 기간마다 표시됩니다. 기간 값은 그래프 지표 탭의 기간 드롭다운에서 변경 가능합니다.
Metric Insights
SELECT MAX(collectd_fhcount_value) FROM SCHEMA(CWAgent, host, type, type_instance) WHERE type = 'file_handles' AND type_instance = 'used' GROUP BY host
지표 수학 표현식
SEARCH('{CWAgent, host, type, type_instance} MetricName="collectd_fhcount_value" type="file_handles" type_instance="used"', 'Maximum', 300)

상위 10개 인스턴스의 최대 열린 파일 수.
Metric Insights
SELECT MAX(collectd_fhcount_value) FROM SCHEMA(CWAgent, host, type, type_instance) WHERE type = 'file_handles' AND type_instance = 'used' GROUP BY host ORDER BY MAX() DESC LIMIT 10
지표 수학 표현식
SORT(e1, MAX, DESC, 10)
e1은 다음과 같습니다.
SEARCH('{CWAgent, host, type, type_instance} MetricName="collectd_fhcount_value" type="file_handles" type_instance="used"', 'Maximum', 300)

또한 지표 데이터에서 CloudWatch 경보를 생성할 수 있습니다. 정적 임계값으로 경보를 생성하거나(단일 지표 또는 Metrics Insights 쿼리 결과를 기반으로 할 수 있음), 이상 감지를 사용할 수도 있습니다.

이상 감지 경보의 경우 CloudWatch는 지표의 과거 동작을 기반으로 모델을 생성하며, 동작이 정상 범위를 벗어날 때 알림을 보낼 수 있습니다. 이는 특정 임계값이 없지만 동작의 변경 시에 대응해야 하는 지표에 유용할 수 있습니다. 열린 파일 예시가 이러한 이상 감지 경보를 사용하는 좋은 예입니다.

모든 CloudWatch 경보에서는 경보 상태 변경을 기반으로 작업을 생성할 수 있습니다. 이메일 알림 또는 오토스케일링 작업과 같은 여러 유형의 작업을 사용할 수 있습니다. 또한 CloudWatch 경보 이벤트를 Amazon EventBridge를 사용하여 캡처하고 AWS Lambda와 같은 서비스로 자동화를 실행하는 데 사용할 수 있습니다.

CloudWatch 대시보드에 경보 위젯을 추가하여 현재 경보 상태를 볼 수도 있습니다. 위의 예시 대시보드에는 이러한 예제가 포함되어 있습니다.

다음 단계

더 자세히 살펴볼 수 있는 몇 가지 영역이 있습니다.

데이터를 분리하기 위해 지표 이름을 사용자 정의 이름으로 변경하기

수집하는 지표의 이름은 collectd에 의해 정의됩니다. 우리의 예시에서는 collectd_로 시작하는 것을 알 수 있습니다. CloudWatch 에이전트 구성의 name_prefix 필드를 사용하면 이를 자체 사용자 정의 접두사로 바꿀 수 있습니다. 아래 예시에서는 데이터가 속한 응용 프로그램을 나타내기 위해 ecom_ 접두사가 사용되었습니다.

개별 collectd 지표에 append_dimensions 옵션을 사용하여 사용자 정의 측정기준을 추가할 수는 없지만, name_prefix를 사용하여 데이터를 다른 소스로 부터 구분할 수 있습니다.

물론 append_dimensions 필드를 사용하여 모든 필드에 특정 측정기준을 추가할 수 있습니다 – 아래 예시에서는 InstanceId에 대한 측정기준을 추가합니다.

{
    "metrics": {
        "metrics_collected": {
            "collectd": {
                "collectd_security_level": "none",
                "metrics_aggregation_interval": 60,
                "name_prefix": "ecom_"
            }
        },
        "append_dimensions": {
            "InstanceId": "${aws:InstanceId}"
        }
    }
}

연결 실패를 확인하는 방법

State Manager 콘솔에서 원하는 연결을 선택하고 세부 정보 보기(View details)를 선택합니다. 마지막 연결 실행의 상태가 여기에 표시됩니다.
실패 원인을 보려면 또는 이전 실행을 확인하려면 실행 내역(Execution history) 탭을 선택하고 적절한 실행 ID를 선택하십시오. 이 실행 내에서 작동한 모든 리소스와 해당 상태 목록이 표시됩니다. 각 항목의 Output을 선택하여 출력과 오류를 모두 볼 수 있습니다.

일반적인 오류

출력이나 오류 없음
- Parameter Store, Amazon EC2 및 State Manager 연결의 리전이 모두 동일한지 확인하십시오.
Error: amazon-linux-extras: command not found
- Amazon Linux 2 AMI를 사용하거나, collectd 설치/구성을 담당하는 State Manager 연결의 명령어를 AMI에 맞게 업데이트하십시오.
CloudWatch 에이전트 구성 실행 중 실패. 연결 출력에 ‘Error: Error running agent: Error loading config file /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml: error parsing socket_listener, open /usr/share/collectd/types.db: no such file or directory’가 표시됨
- 존재하지 않는 collectd 파일을 찾고 있습니다. CloudWatch 에이전트에서 collectd를 구성하기 전에 collectd가 설치 및 실행 중인지 확인하십시오. collectd에 대한 연결을 실행하고 CloudWatch 에이전트 구성 연결을 다시 실행할 수 있습니다.

비용 및 정리

계정에 비용이 발생하지 않도록 생성한 리소스를 삭제하십시오:

EC2 인스턴스 삭제
EC2 인스턴스용으로 추가한 IAM 정책 제거 또는 IAM 역할 삭제
1. CloudWatchAgentServerPolicy 및 AmazonSSMManagedInstanceCore
Systems Manager 파라미터 삭제
1. collectd-config 및 cloudwatch-config-forcollectd
State Manager 연결 삭제
1. LinuxCollectdSetup, LinuxCloudWatchInstall 및 LinuxCloudWatchConfig
CloudWatch 대시보드 삭제
1. 대시보드에서 작업(Actions) > 대시보드 삭제(Delete dashboard) 선택
CloudWatch 경보 삭제

CloudWatch 지표는 삭제할 수 없습니다. 지표는 FAQ의 보존 기간 설명에 따라 만료됩니다. 모든 지표의 보존 기간이 어떻게 되는지에 대한 설명은 FAQ, 모든 지표의 보존 기간은 어떻게 되나요?(What is the retention period of all metrics)에서 확인하십시오. 지표 저장에 대한 비용은 없으며, 인입만 비용이 발생합니다.

결론

이 글에서는 Amazon EC2 Linux 인스턴스에서 collectd와 Amazon CloudWatch 에이전트의 기본 설정을 수행하여 열린 파일에 대한 지표를 수집하는 방법을 안내했습니다. 또한 CloudWatch 대시보드와 경보에서 이 데이터로 수행할 수 있는 몇 가지 예제를 공유했습니다.

자신의 사용 사례를 살펴보고 어떤 시각화나 조치를 취하고 싶은지, 그리고 이를 지원하기 위해 필요한 데이터는 무엇인지 고려해보시기를 권장합니다. CloudWatch에서 여러 다른 리소스에서 수집되는 기본 데이터 및 collectd와 함께 사용할 수 있는 다른 플러그인도 살펴보시기 바랍니다.

다음과 같은 자료에서 유용한 정보를 얻을 수 있습니다.

AWS를 활용한 관찰 가능성에 대해 더 알아보고 싶으시다면 다음 자료를 추천합니다.

One Observability Workshop을 통한 CloudWatch 실습 탐색
AWS 관찰 가능성 모범 사례

AWS 기술 블로그