메트릭 카디널리티 누수 차단과 수집 주기 60s 조정

[m-a-king]

Situation

• Grafana Cloud 콘솔에 Metrics 무료 티어 한도 도달 배너가 떴다. 실측하니 billable 13,598 / 10,000 (136%) 로, 이 상태가 지속되면 신규 시계열이 드랍되어 대시보드와 알림이 조용히 눈이 먼다. 방금 파싱 실패 알림 체계를 세운 직후라 더 뼈아프다.
• 그런데 활성 시계열 자체는 5,814 로 한도의 58% 였다. 즉 "메트릭을 너무 많이 만들어서"가 아니라 수집 설정 문제였고, 셋으로 갈렸다.

Task

• 한도 아래로 내리되, 다시 차오르지 않게 원인을 막는다. 감시 능력은 잃지 않는다.

Action

1. 카디널리티 누수 차단 (핵심)

감축보다 이쪽이 본질이다. 아래 둘은 시간이 갈수록 저절로 불어나는 구조여서, 막지 않으면 정리해도 다시 한도에 닿는다.

대상	실측	왜 누수인가	조치
네트워크 인터페이스 12종	veth7730075·veth7a96d8f·veth18e7998 등 veth 9개 + docker0·br-*·lo·ens5	veth 는 컨테이너마다 생기고 배포마다 이름이 바뀐다. 배포 한 번에 시계열 한 벌이 영구히 쌓인다	netdev.device_exclude 로 veth·docker0·br-*·lo 제외
파일시스템 마운트 13개	/snap/snapd/26869·/snap/snapd/27595·/snap/snapd/27406 등 /snap/* 10개 + /·/boot·/boot/efi	snap 업데이트마다 경로 번호가 바뀐다. 읽기 전용 이미지라 용량이 고정이고 감시 가치도 없다	mount_points_exclude 에 /snap/.+ 추가 (+ squashfs 타입 제외로 이중 방어)

컨테이너 트래픽은 어차피 docker0·주 NIC 를 통과하며 합산되므로 개별 veth 를 볼 이유도 없다. 주 NIC 이름은 박스·AMI 마다 다를 수 있어(ens5·eth0) include 화이트리스트 대신 exclude 로 두어, 이름이 달라도 주 NIC 은 항상 남게 했다.

2. collector 41개 → 12개

기본 활성 collector 대부분이 우리 박스에 없는 장치를 긁고 있었다. 근거는 24시간 내 "수집 실패" 목록이다:

tapestats(테이프 드라이브) · fibrechannel(SAN 스토리지) · bonding(NIC 본딩) · nfs · nfsd

EC2 에 테이프 드라이브가 있을 리 없다. 이 실패들은 고장 신호가 아니라 "해당 없음" 이고, 진짜 수집 실패를 가리는 노이즈였다. 반면 실제로 쓰는 cpu·meminfo·filesystem 은 실패한 적이 한 번도 없다.

분류	끈 것
물리적으로 없는 장치	tapestats · fibrechannel · bonding · mdadm · bcache · nvme · hwmon · thermal_zone · powersupplyclass · rapl · edac · cpufreq
쓰지 않는 기능	nfs · nfsd · selinux (스토리지는 EBS·S3, Ubuntu 는 AppArmor)
커널 네트워크 내부 통계	netclass · netstat · sockstat · softnet · udp_queues · conntrack (트래픽 자체는 netdev 가 냄)
정적 메타·미사용	arp · dmi · os · time · timex · schedstat · entropy · processes

남긴 것: cpu · meminfo · filesystem · diskstats · netdev · loadavg · stat · vmstat(swap 의존 박스라 필수) · pressure · filefd(fd 고갈은 실제 장애 원인) · uname · textfile.

textfile 은 처음에 "커스텀 지표를 안 쓴다"고 판단해 제거 목록에 넣었다가, config 주석에서 DB 백업 지표가 이 경로로 들어온다는 것을 확인하고 되돌렸다. 껐다면 백업 알림(#909 트랙)이 조용히 죽었을 자리다.

collector 를 끄면 그 메트릭뿐 아니라 collector 당 2개씩 붙는 scrape_collector_success/duration 도 함께 줄어든다. 그러면서 남은 collector 의 success 는 그대로라, "진짜 수집 실패" 감시는 오히려 선명해진다.

3. 수집 주기 30s → 60s

billable 은 활성 시계열 × DPM(분당 샘플 수)으로 환산되므로, 30초 수집은 시계열을 하나도 안 늘리고도 청구량을 2배로 만든다. 이것이 active 5.8k 인데 billable 13.6k 였던 이유다.

• 잃는 것: 메트릭 해상도 1분. 30초짜리 짧은 스파이크를 놓친다.
• 그래도 택한 이유: 알림은 전부 로그 기반이고, 대시보드는 추세 관찰이며, 장애 단건 추적은 트레이스가 담당한다. 30초 해상도가 실제로 쓰이는 자리가 지금 없다.
• 되돌리는 법: 부하테스트처럼 정밀 관찰이 필요할 때만 config 한 줄로 30s 로 돌리고 재프로비저닝한다(몇 분).

검토했으나 택하지 않은 안

30초를 유지하고 정리만 하는 안도 계산했다. billable 약 9,500 으로 한도 안에 들어가긴 하지만 여유가 5% 뿐이라, API 엔드포인트 몇 개 추가(http_server_requests_seconds_bucket 이 URI 수에 비례)나 박스 하나 추가(약 200 시리즈)로 곧장 다시 넘친다. 그때 이 조사를 반복하게 되므로 버렸다.

Result

	전	후(예상)
active series	5,814	약 4,070
billable	13,598 (136%)	약 4,760 (48%)
node_* 시리즈	2,774	약 1,030

• 지연 히스토그램 등 그동안 한도 때문에 막아 둔 계측을 추가할 여유가 생긴다.
• 검증: 운영 버전(v1.16.1)으로 alloy validate 통과. 이 버전에 netdev·device_exclude 인자가 실재하는지 확인하려고 인자명에 오타를 주입해 validation failed 가 나는 것까지 역검증했다(검증이 실제로 인자를 검사한다는 증거).
• 적용 시점: 각 박스의 다음 배포 때 프로비저닝으로 반영된다. 반영 후 billable 추이를 확인해 예상치와 대조해야 한다.

---

연관 이슈

• close 메트릭 한도 초과 해소 - 카디널리티 누수 차단과 수집 주기 조정 #42

[coderabbitai]

Warning

Review limit reached

@m-a-king, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 116 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: fbd6775e-09fd-4b45-baa0-f8869d337c0e

📥 Commits

Reviewing files that changed from the base of the PR and between 9359ba2 and f89755e.

📒 Files selected for processing (1)

• blocks/alloy/config.alloy

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}