StatsD는 측정항목 제출을 위한 프로토콜이자 측정항목 데이터 집계를 위한 데몬입니다. Monitoring 에이전트의 StatsD 플러그인을 구성하여 에이전트가 Monitoring에 측정항목을 쓰는 StatsD 데몬으로 작동하게 합니다.
기본 구성으로 StatsD 플러그인을 사용하는 것이 Monitoring으로 사용자 정의 측정항목을 가져오는 가장 쉬운 방법입니다. StatsD 플러그인은 Linux Stackdriver Monitoring 에이전트에서만 사용할 수 있습니다.
Monitoring 에이전트는 다른 collectd 측정항목도 사용자 정의 측정항목으로 내보내지만 단순 기본 구성은 없습니다. 자세한 내용은 에이전트의 사용자 정의 측정항목을 참조하세요.
이 기능은 Linux에서 실행되는 에이전트에만 사용할 수 있습니다. Windows에서는 사용할 수 없습니다.
탐색
Monitoring은 StatsD를 자동으로 감지하지 않습니다. StatsD 측정항목을 사용하려면 다음 섹션에 설명된 대로 StatsD 플러그인을 구성합니다.
StatsD 플러그인 구성
기본 요건
StatsD 플러그인에는 버전 5.5.2-356 이상의 Monitoring 에이전트가 필요합니다. 에이전트를 업데이트하려면 에이전트 업데이트하기를 참조하세요.
플러그인 사용 설정
Linux를 실행하는 지원되는 VM 인스턴스에서 다음을 수행하세요.
statsd.conf를 다운로드하고 다음 명령어를 사용해서 이를
/etc/stackdriver/collectd.d/에 저장합니다.(cd /etc/stackdriver/collectd.d/ && sudo curl -O https://raw.githubusercontent.com/Stackdriver/stackdriver-agent-service-configs/master/etc/collectd.d/statsd.conf)기본 구성 파일이 기본 StatsD 포트 8125에서 StatsD 측정항목을 수락하도록 에이전트에 지시합니다.
일부 측정항목은 자체 StatsD 데몬으로 전송하고 다른 측정항목은 에이전트의 StatsD 데몬으로 전송하려는 경우 구성 파일에서 포트 설정을 변경합니다.
다음 명령어를 실행하여 Monitoring 에이전트를 다시 시작하고 StatsD 구성을 가져옵니다.
sudo service stackdriver-agent restart
collectd statsd 플러그인에 대한 자세한 내용은 플러그인:StatsD를 참조하세요.
사용자 정의 측정항목에 대한 기본 매핑
빠르게 시작할 수 있게 에이전트의 StatsD 플러그인은 StatsD 측정항목에서 Stackdriver 사용자 정의 측정항목으로 매핑되는 기본 collectd 구성과 함께 제공됩니다.
StatsD 플러그인의 모든 측정항목은 collectd
plugin구성요소에statsd가 있습니다.collectd
type구성요소에 보관된 각 StatsD 측정항목 유형에는 해당하는 사용자 정의 측정항목 유형 이름이 있습니다.collectd
type_instance구성요소에 보관하는 StatsD 측정항목 이름은metric라는 라벨의 값으로 저장됩니다.측정항목 유형
Timer의 경우metric라벨의 값이 다릅니다. 여기에는 측정항목 이름과 카운터 이름(평균, 상한값, 하한값, 합계, 백분위수-50, 백분위수-95)이 모두 포함됩니다.
예를 들어 다음 표에는 지원되는 StatsD 측정항목 유형과 측정항목의 이름이 Monitoring 사용자 정의 측정항목에 어떻게 매핑되는지 보여줍니다.
| StatsD 유형 | StatsD 이름 | Stackdriver 측정항목 유형 | 측정항목 종류 | 값 유형 | 측정항목 라벨 |
|---|---|---|---|---|---|
| 카운터 | my.counter | custom.googleapis.com/statsd/derive | 누적 | Int64 | metric:my.counter |
| 게이지 | my.gauge | custom.googleapis.com/statsd/gauge | 게이지 | 실수 | metric:my.gauge |
| 집합 | my.set | custom.googleapis.com/statsd/objects | 게이지 | 실수 | metric:my.set |
| 타이머1 | my.timer | custom.googleapis.com/statsd/latency | 게이지 | 실수 | metric:my.timer-average |
| (동일) | (동일) | (동일) | metric:my.timer-upper | ||
| (동일) | (동일) | (동일) | metric:my.timer-lower | ||
| (동일) | (동일) | (동일) | metric:my.timer-sum | ||
| (동일) | (동일) | (동일) | metric:my.timer-percentile-50 | ||
| (동일) | (동일) | (동일) | metric:my.timer-percentile-95 | ||
| custom.googleapis.com/statsd/gauge | 게이지 | (동일) | metric:my.timer-count |
참고:
1 동일한 이름의 statsd 타이머 측정항목이 수신됩니다. 에이전트가 StatsD 타이머 측정항목을 집계하고 7개의 시계열로 요약 데이터를 내보냅니다.
StatsD 유형에 대한 자세한 내용은 StatsD 사양을 참조하세요.
내보낸 측정항목 맞춤설정
기본 StatsD 구성은 사용자가 빨리 시작할 수 있도록 설계되었습니다. 이 섹션을 통해 더 복잡한 요구에 맞게 구성을 맞춤설정할 수 있습니다.
사용자 정의 측정항목을 잘 알고 있어야 합니다. 측정항목에 대한 자세한 내용은 측정항목, 시계열, 리소스를 참조하세요. 자세한 내용은 사용자 정의 측정항목 개요를 참조하세요.
다음 항목을 맞춤설정할 수 있습니다.
기본
metric라벨에 할당된 값을 변경할 수 있습니다. 사용하는 라벨 값 수에 비례하여 사용자 정의 측정항목의 시계열 수가 늘어나거나 줄어듭니다.사용자 정의 측정항목 유형을 변경할 수 있습니다. 기본 구성에서 제공하는 사전 정의된 유형을 사용하지 않아도 됩니다. 예를 들어 특정 이름의 측정항목을 식별하고 해당 측정항목에 다른 사용자 정의 측정항목 유형을 사용할 수 있습니다.
사용자 정의 측정항목 유형을 변경하는 경우 각 유형과 연결된 라벨도 변경할 수 있습니다. 기본 구성에 있는 라벨은 1개지만 라벨을 더 추가하거나 라벨 키를 변경할 수 있습니다.
측정항목 유형을 변경하는 경우 Monitoring API에서 새 사용자 정의 측정항목 유형을 정의해야 합니다. 자세한 내용은 다음 측정항목 유형 설계 섹션을 참조하세요.
예
StatsD를 사용하여 두 서비스인 my_service_a 및 my_service_b로 구성된 애플리케이션을 모니터링한다고 가정합니다. 각 서비스에 대해 실패한 요청 수를 나타내는 카운터 측정항목을 Monitoring으로 내보내려고 합니다. 기본 StatsD 측정항목 유형은 사용하지 않으려고 합니다.
수신 collectd 측정항목
사용자 정의 측정항목 유형을 직접 정의하기 전에 collectd 측정항목의 구조와 StatsD 측정항목이 기본적으로 어떻게 사용자 정의 측정항목에 매핑되는지 이해하는 것이 중요합니다.
StatsD 측정항목 등의 collectd 측정항목은 다음 구성요소를 포함합니다.
Host, Plugin, Plugin-instance, Type, Type-instance
이 예에서 내보내려는 StatsD 측정항목은 collectd에 다음 식별자를 갖고 있습니다.
| 구성요소 | 필요한 값 |
|---|---|
| 호스트 | 모두 |
| 플러그인 | statsd |
| 플러그인 인스턴스 | 설정되지 않음1 |
| 유형 | derive2 |
| 유형 인스턴스 | [SERVICE_NAME].GET.[CODE]3 |
[VALUE] |
모든 값4 |
참고:
1 StatsD 플러그인은 현재 이 구성 요소를 비워둡니다.
2 StatsD 카운터 측정항목이 collectd derive 유형에 매핑됩니다.
3 예를 들어 유형 인스턴스는 my_service_a.GET.500가 될 수 있습니다.
4 [VALUE]는 대개 타임스탬프와 배정밀도 숫자입니다.
다음 표에서는 이 측정항목이 기본적으로 어떻게 매핑되는지 보여줍니다.
| StatsD 유형 | StatsD 이름 | Stackdriver 측정항목 유형 | 측정항목 종류 | 값 유형 | 측정항목 라벨 |
|---|---|---|---|---|---|
| 카운터 | my_service_a.GET.500 | custom.googleapis.com/statsd/derive | 누적 | Int64 | metric:my_servce_a.GET.500 |
| 카운터 | my_service_b.GET.403 | custom.googleapis.com/statsd/derive | 누적 | Int64 | metric:my_servce_b.GET.403 |
기본 매핑 사용 시 다음과 같은 어려움이 있을 수 있습니다.
이 특정 카운터 측정항목(
[SERVICE_NAME].GET.[CODE])은 다른 모든 카운터 측정항목과 동일한 사용자 정의 측정항목 유형에 속합니다. Stackdriver는 현재 라벨에 대한 정규 표현식 검색을 지원하지 않기 때문에 이 측정항목의 데이터만 쉽게 가져올 수 없습니다.개별 서비스의 데이터나 데이터의 개별 응답 코드를 쉽게 가져올 수 없습니다. 예를 들어
my_service_a에서 발생한 모든 유형의 오류 합계를 쉽게 가져올 수 없습니다.기본 구성은 모든 StatsD 측정항목을 Stackdriver로 내보냅니다. 따라서 특정 측정항목만 필요한 경우에도 모든 항목을 내보내므로 비용이 많이 듭니다.
측정항목 유형 설계
측정항목 유형 만들기에 대한 자세한 내용은 사용자 정의 측정항목 유형 만들기를 참조하세요.
다음 사용자 정의 측정항목 유형은 사용자가 원하는 StatsD 측정 항목만 보관하며 라벨 선택으로 데이터를 더 잘 구성할 수 있으므로 이 예시의 데이터에 합리적인 선택입니다.
- 유형:
custom.googleapis.com/http/request_errors - 라벨:
service_name(STRING): 서비스의 이름입니다.response_code(INT64): HTTP 응답 코드입니다.
- 종류: 누적
- 값 유형: INT64
다음 표에서는 StatsD에서 Stackdriver로의 적절한 매핑을 보여줍니다.
| StatsD 유형 | StatsD 이름 | Stackdriver 측정항목 유형 | 측정항목 종류 | 값 유형 | 측정항목 라벨 |
|---|---|---|---|---|---|
| 카운터 | my_service_a.GET.500 | custom.googleapis.com/http/request_errors | 누적 | Int64 | service_name:my_service_a, response_code:500 |
| 카운터 | my_service_b.GET.403 | custom.googleapis.com/http/request_errors | 누적 | Int64 | service_name:my_service_b, response_code:403 |
측정항목 유형을 설계했으면 metricDescriptors.create를 사용하여 해당 유형을 만듭니다. Monitoring에서 측정항목 유형 자동 생성에 대한 자세한 내용은 측정항목 설명 자동 생성을 참조하세요.
매핑 구성
StatsD 측정항목을 새 사용자 정의 측정항목 유형으로 내보내려면 기본 StatsD 플러그인 구성 /etc/stackdriver/collectd.d/statsd.conf의 콘텐츠를 다음 코드로 바꿉니다.
<Plugin statsd>
Host "127.0.0.1"
Port "8125"
DeleteSets true
TimerPercentile 50.0
TimerPercentile 95.0
TimerLower true
TimerUpper true
TimerSum true
TimerCount true
</Plugin>
LoadPlugin match_regex
LoadPlugin target_set
LoadPlugin target_replace
# Insert a new rule in the default "PreCache" chain, to divert your metrics.
PreCacheChain "PreCache"
<Chain "PreCache">
# The following rule does all the work for your metric:
<Rule "rewrite_request_errors">
# Do a careful match for just your metrics; if it fails, drop down
# to the next rule:
<Match regex>
Plugin "^statsd$"
TypeInstance "^.*\\.GET\\..*$" # Match on type instance.
</Match>
<Target "set">
# Specify the metric descriptor type:
MetaData "stackdriver_metric_type" "custom.googleapis.com/http/request_errors"
# Initialize the labels from the "type_instance" label; clean the values up in the next Target below.
MetaData "label:service_name" "%{type_instance}"
MetaData "label:response_code" "%{type_instance}"
</Target>
<Target "replace">
# Remove ".GET.[code]" to get the real service name.
MetaData "label:service_name" "\\.GET\\.[0-9]*$" ""
# Remove "[service].GET." to get the real response code.
MetaData "label:response_code" "^[^\\.]*\\.GET\\." ""
</Target>
</Rule>
</Chain>
에이전트 다시 시작
VM 인스턴스에서 다음 명령어로 에이전트를 다시 시작하여 새 구성을 가져옵니다.
sudo service stackdriver-agent restart
사용자 정의 측정항목 정보가 Monitoring으로 즉시 전송되기 시작합니다.
다음 단계
StatsD 플러그인 맞춤설정은 Monitoring에 대해 collectd 측정항목을 맞춤설정하는 것과 동일합니다. 자세한 내용은 에이전트의 사용자 정의 측정항목의 참조 및 문제 해결 섹션을 참조하세요.