애플리케이션만 모니터링해서는 시스템 전체를 파악하기에 충분하지 않은 경우가 많습니다. 위성 앱(또는 보조 앱)에서 실행되는 서비스가 일상 운영에 결정적인 영향을 미칠 수 있기 때문입니다. 데이터베이스 서버가 대표적인 예이며, 백업 스크립트나 기타 백그라운드 작업 역시 시스템 성능을 저하시키면서도 자주 간과됩니다.
AppSignal의 Node.js용 APM, Ruby용 APM, Elixir용 APM은 애플리케이션 자체를 자동으로 계측합니다. 하지만 AppSignal은 기본적으로 이러한 위성 프로세스까지는 감시하지 않습니다. 모니터링 범위를 시스템 전반으로 확장하고 모든 데이터를 하나의 앱에서 통합 관리하려면 AppSignal의 독립형 에이전트(standalone agent)를 설치하면 됩니다.
AppSignal 독립형 에이전트
독립형 에이전트는 Ruby, Elixir, JavaScript 애플리케이션을 계측할 때 사용하는 것과 동일한 소프트웨어를 기반으로 하며, 독립 실행 모드로도 구동할 수 있습니다.
독립형 에이전트로 다음 항목들을 모니터링할 수 있습니다:
- 인프라: 시스템의 일부이지만 애플리케이션 코드를 실행하지 않는 머신
- 백그라운드 작업: 집약적인 cron 작업이나 장기 실행 데이터 처리 스크립트 등. 지원 언어(Ruby, Elixir, Node.js)로 작성된 경우 표준 통합을 그대로 사용할 수 있습니다.
- 추가 언어: 기본 지원 언어 외의 언어로 작성된 프로그램
예를 들어 독립형 에이전트를 활용하면 Python으로 작성된 머신러닝 모델을 추적하고, 백업 스크립트를 계측하고, Kafka 브로커를 모니터링하거나, 웹 팜의 호스트 메트릭을 수집할 수 있습니다. 이렇게 수집한 정보는 AppSignal에서 기존 메인 애플리케이션의 메트릭과 함께 확인할 수 있습니다.
작동 방식
에이전트는 deb 또는 rpm 패키지로 배포되며 언어 종속성이 전혀 없습니다. Debian/Ubuntu 또는 Red Hat 기반 시스템이라면 어디서든 실행할 수 있습니다. 자세한 설치 절차는 에이전트 공식 문서를 참고하세요.
설치 후 몇 분 만에 설정이 완료되며, 에이전트는 데몬 형태로 상시 실행되면서 조용히 인프라를 감시합니다. 특히 에이전트에는 StatsD 서버가 내장되어 있어, 로깅하는 모든 커스텀 데이터를 AppSignal 대시보드로 전달할 수 있습니다.
StatsD란 무엇인가?
StatsD는 임의의 데이터를 수집하고 집계하기 위한 표준 규격입니다. 메트릭 및 성능 정보 로깅에 특화되어 있으며, UDP 연결 위에서 동작하는 경량 텍스트 프로토콜을 사용하기 때문에 머신에 주는 부담이 거의 없습니다.
StatsD 메시지는 다음과 같은 형식입니다:
여기서 KEY는 임의의 문자열이고, VALUE는 숫자입니다. type 값은 해당 숫자가 어떻게 처리될지를 결정합니다.
지원되는 메트릭 유형은 세 가지입니다:
- c: 호출될 때마다 값이 증가하는 카운터(counter)입니다. 예를 들어
active_users:1|c는active_users카운터에 1을 더합니다. - g: 게이지(gauge)는 숫자 값을 받아 다음 업데이트까지 그 값을 유지합니다. 처리량, 활성 사용자 수, 대기열의 대기 작업 수처럼 시간에 따라 오르내리는 값을 기록하는 데 유용합니다.
- t: 타이밍(timing) 값을 저장합니다. 지속 시간 추적에 적합하며, AppSignal은 기록된 모든 타이밍에 대해 평균, 호출 횟수, 백분위수를 자동으로 계산합니다.
이 외에 지원하지 않는 메트릭 유형은 별도의 오류 없이 조용히 무시됩니다.
StatsD로 데이터 보내기
독립형 에이전트는 8125 포트에서 UDP 패킷을 수신합니다. netcat을 사용하면 명령줄에서 바로 StatsD 형식의 문자열을 전송할 수 있습니다:
UDP를 사용하기 때문에 응답을 기다릴 필요가 없습니다.
socat으로도 동일하게 전송할 수 있습니다:
덕분에 배치 작업이나 cron 작업도 손쉽게 계측할 수 있습니다. 예를 들어 다음 명령은 게이지를 사용해 백업 작업이 생성한 데이터 용량을 기록합니다:
정수에 국한되지 않고 부동소수점 숫자도 지원합니다:
메트릭에 태그를 추가할 수도 있습니다. StatsD 서버는 메시지 끝에 선택적 태그를 붙이는 것을 지원합니다:
하나의 메시지에 여러 태그를 함께 적용하고, 나중에 필터링할 수 있도록 태그에 값을 할당할 수도 있습니다:
AppSignal에서 이 데이터를 확인하는 방법은 잠시 후 살펴보겠습니다.
다양한 언어에서 계측하기
StatsD 서버는 UDP 패킷을 전송할 수 있는 모든 언어와 호환됩니다. 몇 가지 예를 살펴보겠습니다.
Python은 데이터 마이닝과 머신러닝 분야에서 가장 널리 쓰이는 언어 중 하나입니다. 내장 socket 라이브러리를 사용하면 Python 애플리케이션에 간단히 계측을 추가할 수 있습니다:
Java에서는 java.net 라이브러리로 비슷한 결과를 얻을 수 있습니다:
PHP 역시 폭넓게 사용되는 언어입니다. socket_sendto 함수로 UDP 패킷을 전송할 수 있습니다:
StatsD 클라이언트
지금까지는 각 언어에 내장된 네트워킹 기능을 활용했습니다. 하지만 방법은 이것만이 아닙니다. 많은 언어와 제품에 서드파티 StatsD 클라이언트나 애드온이 제공됩니다. StatsD 규격을 준수하는 클라이언트라면 최소한 지원되는 데이터 유형에 한해 어떤 것이든 동작합니다. 사용 가능한 클라이언트 목록은 StatsD 프로젝트 위키에서 확인할 수 있습니다.
AppSignal에서 호스트 데이터 확인하기
호스트 메트릭(Host Metrics) 대시보드에서는 머신의 리소스 사용률을 확인할 수 있습니다:
독립형 에이전트가 실행 중인 모든 머신에 대해 AppSignal이 자동으로 항목을 추가해 줍니다.
대시보드에는 부하(load)와 CPU 평균값, 디스크, 네트워크, 메모리, 스왑 사용량이 표시됩니다:
대시보드 만들기
AppSignal은 전송한 StatsD 값에 대한 대시보드를 자동으로 생성하지 않으므로, 직접 커스텀 대시보드를 만들어야 합니다.
먼저 대시보드 메뉴에서 Add dashboard(대시보드 추가)를 클릭합니다:
대시보드 이름을 입력합니다:
Add graph(그래프 추가) 버튼을 클릭하면 그래프 빌더가 열립니다:
그래프 이름을 정한 뒤 Add metric(메트릭 추가)을 클릭합니다:
메뉴에서 원하는 메트릭을 선택합니다.
필요하다면 태그를 활용해 필터링할 수도 있습니다:
이후 Back to overview(개요로 돌아가기)를 클릭합니다. 표현하려는 데이터에 가장 적합한 그래프 유형과 값 단위를 찾기 위해 여러 옵션을 시도해 보는 것이 좋습니다.
타이밍 데이터는 영역 그래프(area graph)를 사용하면 평균값과 백분위수가 더욱 선명하게 드러납니다.
카운터와 게이지에는 선 그래프(line graph)가 잘 어울립니다.
결과에 만족했다면 Create graph(그래프 만들기)를 클릭해 완성합니다.
참고로 AppSignal을 Node.js용 APM, Ruby(on Rails)용 APM 또는 Elixir용 APM으로 사용하고 있다면, 자동 계측된 다른 메트릭에 대해서도 동일한 방식으로 대시보드를 추가할 수 있습니다.
마무리
이번 글에서는 AppSignal의 독립형 에이전트를 활용해 머신과 위성 코드를 감시하는 방법을 살펴봤습니다. 내장된 StatsD 서버를 활용하면 임의의 성능 데이터를 자유롭게 기록하고 어떤 프로세스든 계측할 수 있습니다.
독립형 에이전트 활용법을 더 깊이 알아보려면 다음 자료들을 확인해 보세요:
- StatsD 레퍼런스
- 커스텀 메트릭 전송 방법
- AppSignal에서 대시보드 만들기
- 독립형 에이전트로 Kafka 문제 식별 및 해결하기
토마스 페르난데스(Tomas Fernandez)
게스트 저자인 토마스 페르난데스는 IBM에서 10년간 근무하며 개발, 서비스 제공, 데이터베이스 관리, 클라우드 엔지니어링 등 다양한 분야의 업무를 수행했습니다. 현재는 독립 컨설턴트이자 테크니컬 라이터로 활동하고 있습니다.
토마스 페르난데스의 모든 글 보기