Micrometer 입문 9편 시리즈 마무리. 1~8편 핵심 압축(벤더 중립 facade·Meter 타입·Timer percentile·카디널리티·Actuator 통합·Registry 백엔드·IaC·OTel·운영 함정) + 신규 도입 30일 체크리스트(의존성 → 기본 메트릭 → 비즈니스 계측 → 카디널리티 정리 → 대시보드·SLO) + 백엔드 개발자 일/주/월/분기 routine + 무료·유료 학습 자원 + Observability maturity 5단계 + 다음 학습(Grafana·OpenTelemetry·진로).
이 글은 Micrometer 입문에서 운영까지 시리즈 마지막 9편이에요. 1~8편이 쌓아온 계측 지식을 일상 운영 리듬으로 굳히는 자리입니다. Micrometer 의 자리(메트릭 facade)부터 운영 함정까지 한 줄씩 다져온 깊이가 이 글에서 큰 그림으로 모입니다.
이번 글의 범위
[1~8편 핵심 압축]
↓
[신규 도입 30일 체크리스트]
↓
[백엔드 개발자의 일·주·월·분기 routine]
↓
[학습 자원 (무료 · 유료)]
↓
[Observability maturity 5단계]
↓
[다음 학습 — 어디로 가나]
1~8편 핵심 압축
1편 — 벤더 중립 facade · 큰 그림
1편 — Micrometer 입문·메트릭의 벤더 중립 facade·큰 그림
벤더 중립 facade ("메트릭의 SLF4J"):
앱 코드 → Micrometer API (한 번 작성)
의존성 교체 → Prometheus / Datadog / CloudWatch / New Relic / OTLP
MeterRegistry:
Counter — 단조 증가 (요청 수·에러 수)
Timer — count + totalTime + max (latency)
Gauge — 현재 순간 값 (큐 크기·스레드 수)
DistributionSummary — 크기·건수 분포 (페이로드·배치)
Observation API (Micrometer 1.10+):
한 번 계측 → Metrics + Traces 동시 생성
구 Spring Cloud Sleuth 대체 (Spring Boot 3.x)
Observability 3 pillar 속 위치:
Metrics 생산 계층 담당 (수집은 Prometheus, 시각화는 Grafana)
2편 — Meter 타입 깊이
2편 — Counter·Gauge·Timer·DistributionSummary
Counter:
단조 증가만 가능 (감소 X)
increment() / increment(double amount)
Reset = 재시작 뿐
Gauge:
현재 순간 값을 람다로 관찰
강한 참조 주의 (GC 방해 함정)
Gauge.builder("name", obj, obj -> obj.size())
Timer:
count · totalTime · max 세 값 동시 관리
record(Runnable) / record(Duration) / recordCallable()
publishPercentiles(0.5, 0.95, 0.99) — 클라이언트 사이드
DistributionSummary:
시간 외의 수량 분포 (bytes · 건수 · 금액)
Timer 와 혼동 금지
LongTaskTimer:
진행 중인 장기 작업의 현재 경과 시간
@Scheduled / 배치 작업에 유용
FunctionCounter · FunctionTimer:
외부 라이브러리의 카운터/타이머를 Micrometer 에 래핑
3편 — Timer percentile · histogram · SLO
3편 — Timer percentile·histogram·SLO
평균 latency 의 맹점:
99% 사용자가 10ms, 1% 사용자가 10s → 평균 109ms
평균은 느린 사용자를 숨긴다
클라이언트 사이드 percentile:
publishPercentiles(0.95, 0.99)
서버에서 계산 후 단일 값 전송
분산 환경에서 합산 불가 (각 인스턴스 percentile 의 산술평균 = 통계적 오류)
서버 사이드 histogram:
publishPercentileHistogram()
Prometheus histogram_quantile() 로 정확한 집계
분산 환경에서도 합산 가능 (컨테이너 N개 → histogram 합산 → 정확한 p99)
SLO 버킷:
serviceLevelObjectives(Duration.ofMillis(100), Duration.ofMillis(300))
SLO 위반 비율을 Prometheus 에서 직접 집계
4편 — 태그 · 차원 · 카디널리티
태그 = 차원:
이름 + Tag 조합 = 고유 시계열
태그로 필터·집계 가능 (PromQL where clause)
Common Tags:
MeterRegistryCustomizer 로 전 메트릭에 application · env · region 일괄 주입
카디널리티 폭발:
userId · requestId 같은 동적 값 → 시계열 무한 증가 → Prometheus OOM
URI 는 반드시 템플릿으로 정규화 (/api/orders/{id} 로)
MeterFilter:
deny(name) — 특정 메트릭 차단
maximumAllowableTags(name, tag, max, fallback) — 카디널리티 상한
방어 첫 번째 수단
네이밍 컨벤션:
소문자 + 점(.) 구분자 (orders.created, http.server.requests)
Spring Boot 자동 Meter prefix — http. · jvm. · system. · tomcat.
5편 — Spring Boot Actuator 통합
5편 — Spring Boot Actuator 통합 깊이
의존성 두 줄:
spring-boot-starter-actuator
micrometer-registry-prometheus
자동 계측 (공짜로 따라오는 메트릭):
JVM — jvm.memory.used · jvm.gc.pause · jvm.threads.live
HikariCP — hikaricp.connections.active · hikaricp.connections.pending
Tomcat — tomcat.sessions.active · tomcat.threads.busy
HTTP — http.server.requests (uri · method · status · outcome)
Logback — logback.events (level 태그)
@Timed:
메서드에 붙이면 자동 Timer 생성
TimedAspect @Bean 등록 필수
클래스 레벨 적용 주의 (모든 public 메서드)
Observation API:
observationRegistry 를 활용한 계측 → Metrics + Traces 동시
WebMVC · WebFlux · RestClient 자동 계측
6편 — Registry · 백엔드 · push vs pull
6편 — Registry·백엔드·push vs pull 깊이
Pull (Prometheus):
/actuator/prometheus 노출 → Prometheus 가 주기적으로 scrape
스크랩 주기 = 데이터 resolution
Push (Datadog · CloudWatch · StatsD · InfluxDB):
StepMeterRegistry 의 step 주기로 밀어냄
step 불일치 → 데이터 유실 함정 (step 보다 짧은 스파이크 소실)
CompositeMeterRegistry:
Prometheus + Datadog 동시 전송
여러 구현체 add() 로 등록
PushGateway 패턴:
단명 잡(배치·CLI) → PushGateway → Prometheus scrape
완료 후 deleteMetrics() 로 stale 데이터 제거
SimpleMeterRegistry:
인메모리 테스트 전용
운영 레지스트리와 혼용 금지
7편 — IaC · OpenTelemetry 연동
7편 — 운영 자동화·IaC·OpenTelemetry 연동
/actuator/prometheus 보안:
포트 분리 (management.server.port: 8081)
internal 네트워크만 접근 허용
Kubernetes Prometheus Operator:
ServiceMonitor / PodMonitor — scrape 설정을 CRD 로 선언
labels: release: prometheus 로 Prometheus 가 자동 발견
OpenTelemetry 연동:
micrometer-registry-otlp — OTLP 프로토콜로 OTel Collector 에 push
micrometer-tracing-bridge-otel — Observation API → OTel Trace
OTel Collector → Prometheus / Jaeger / 다중 백엔드 라우팅
MeterBinder:
외부 라이브러리 상태를 Micrometer 에 연결
사내 라이브러리화 → 팀 전체 표준 메트릭 자동 등록
8편 — 운영 함정 + 사고 케이스
10가지 운영 사고:
1. 카디널리티 폭발 → Prometheus OOM
2. Gauge 강한 참조 → 메모리 누수 (대상 객체 GC 차단)
3. 클라이언트 사이드 percentile 합산 오판 → SLO 붕괴
4. step 레지스트리 카운터 유실 (스텝 주기 내 재시작)
5. @Timed + 수동 Timer 이중 계측 (double-counting)
6. 메트릭 이름·태그셋 충돌 (다른 Meter 에 같은 이름)
7. /actuator/prometheus 인증 없이 공개 노출
8. 테스트에서 SimpleMeterRegistry 를 운영 코드와 혼용
9. reactor/async context 전환 시 태그 손실
10. 고빈도 메트릭 성능 오버헤드 (Timer 남용)
운영 KPI:
카디널리티 추이 · 스크랩 오류율 · 메트릭 누락 갭 · SLO 준수율
신규 도입 30일 체크리스트
Week 1 — 의존성 추가·기본 엔드포인트 확인
□ Day 1-2: 의존성 추가
- spring-boot-starter-actuator
- micrometer-registry-prometheus (또는 팀 백엔드)
- application.yml — management.endpoints.web.exposure.include: prometheus, health, info
□ Day 3-4: 기본 자동 메트릭 확인
- /actuator/prometheus 열림 확인
- jvm.memory.used · http.server.requests · hikaricp.connections.active 확인
- MeterRegistryCustomizer 로 common tags 주입 (application · environment)
□ Day 5-6: 보안 설정
- management.server.port: 8081 로 포트 분리
- 내부 네트워크만 actuator 포트 접근 허용
- 민감 메트릭 MeterFilter.deny() 로 사전 차단 목록 점검
□ Day 7: 팀 컨벤션 정립
- 메트릭 네이밍 컨벤션 문서화 (도메인 prefix 결정)
- 허용 태그 목록 초안 (유한 값 집합만)
- MeterFilter maximumAllowableTags 기본 방어선 설정
Week 2 — 핵심 비즈니스 메트릭 계측
□ Day 8-9: 핵심 Counter 추가
- 비즈니스 핵심 이벤트 Counter 등록 (주문 생성 · 결제 완료 · 에러 등)
- 서비스 필드로 선언 + 생성자 등록 패턴 적용
- .description() 누락 없이
□ Day 10-11: 핵심 Timer 추가
- 중요 API 경로 Timer 등록
- publishPercentileHistogram() + serviceLevelObjectives() 설정
- p50 · p95 · p99 latency 확인
□ Day 12-13: Gauge 추가
- 큐 크기 · 스레드 수 · 커넥션 풀 idle/active Gauge 등록
- 강한 참조 여부 점검 (람다 대상 객체가 GC 안 막히는지)
□ Day 14: 카디널리티 첫 점검
- 등록된 시계열 수 확인 (prometheus_tsdb_head_series 또는 Datadog 대시보드)
- 동적 태그 값 사용 여부 grep (userId · requestId · sessionId 패턴)
Week 3 — 태그·카디널리티 정리·MeterFilter
□ Day 15-16: 태그 감사
- 모든 커스텀 Meter 의 태그 목록 작성
- 태그 값이 유한 집합인지 확인 — 아니면 정규화 또는 제거
- URI 태그 → 반드시 템플릿(/api/orders/{id}) 으로 정규화 확인
□ Day 17-18: MeterFilter 강화
- deny() 로 불필요 자동 Meter 차단 (사용 안 하는 actuator 메트릭)
- maximumAllowableTags() 로 카디널리티 상한 설정
- 팀 MeterFilter 빈을 공통 라이브러리로 이동
□ Day 19-20: Observation API 검토
- @Observed · ObservationRegistry 활용 범위 점검
- tracing bridge 의존성 확인 (micrometer-tracing-bridge-otel 또는 brave)
- async · reactor 컨텍스트에서 태그 전파 여부 확인
□ Day 21: 첫 알림 연결
- Prometheus Alertmanager 또는 Datadog Monitor 첫 룰 설정
- SLO 기준 알림 (p99 latency · 에러율) 설정
- 알림 채널(Slack · PagerDuty) 연결 확인
Week 4 — 대시보드·알림 연결·SLO 버킷
□ Day 22-23: Grafana 대시보드 구성
- 서비스 RED 메트릭 대시보드 (Rate · Errors · Duration)
- SLO 현황 패널 (error budget 소진율)
- JVM · HikariCP · Tomcat 인프라 대시보드
□ Day 24-25: SLO 버킷 정의
- serviceLevelObjectives() 버킷 경계 팀 합의
- histogram_quantile() PromQL 로 p99 집계 검증
- 목표 SLO 수치 명문화 (99.9% 이하 100ms 이내 등)
□ Day 26-27: IaC 전환
- Prometheus scrape 설정 코드화 (ServiceMonitor 또는 file_sd)
- Grafana 대시보드 JSON → Git 보관
- 알림 룰 YAML → Git 보관
□ Day 28-29: 팀 온보딩 문서 작성
- 새 팀원이 메트릭 추가하는 방법 한 페이지로
- 허용 Meter 타입·태그·prefix 컨벤션 표
- 카디널리티 점검 절차
□ Day 30: 30일 회고
- 현재 시계열 수 vs Day 1 비교
- false alert 비율 점검
- 다음 달 개선 우선순위 3개 선정
백엔드 개발자의 routine
일 routine (10~15분)
출근 후 첫 10분:
- 어젯밤 alert 기록 확인 (Slack 알림 채널)
- 현재 활성 alert 여부 Grafana 확인
- 어제 SLO 소진율 — 이상 없으면 패스
개발 중:
- 새 기능 추가 시 Meter 등록 여부 체크 (Counter or Timer)
- PR 리뷰 시 태그에 동적 값 들어가는지 한 번 눈여겨봄
주 routine (1~2시간)
월요일 오전:
- 지난 주 SLO 준수율 확인
- 지난 주 가장 noisy alert — false positive 이면 룰 조정
- 카디널리티 추이 (prometheus_tsdb_head_series 주간 비교)
수요일 오후:
- 새 배포 후 메트릭 이상 없는지 점검
- 시계열 추가·삭제 있었다면 대시보드 업데이트
금요일 마무리:
- 주말 배포·점검 스케줄 있으면 Mute Timing 설정 확인
- 다음 주 기능 개발에 필요한 Meter 설계 미리 정리
월 routine (3~4시간)
월 첫 주:
- SLO compliance 월간 리포트 (error budget 소진율)
- 월중 가장 많이 발생한 alert top 5 — 원인·해결·재발방지
- 카디널리티 급증 구간 있었다면 원인 파악
월 중반:
- 의존성 버전 점검 (micrometer-bom 최신 안정 버전 확인)
- 신규 Meter 추가된 것 팀 공유 (내가 추가한 메트릭이 팀에 알려져 있나?)
- MeterFilter 설정 리뷰 — 차단 규칙 여전히 유효한지
월 끝:
- 다음 달 계획 중인 기능에 필요한 Meter 설계 미리 논의
- 팀 컨벤션 문서 최신화 (새 prefix 추가됐다면)
분기 routine
분기 시작:
- 지난 분기 observability 관련 retrospective
- SLO 목표 수치 재검토 — 현실적인가, 더 엄격하게 가야 하나
- 백엔드 버전 업그레이드 계획 (Spring Boot · Micrometer major 버전)
분기 중반:
- 새 서비스·팀 온보딩 지원 — 컨벤션 전파
- OpenTelemetry 전환 진행 상황 점검
- Cardinality budget 재산정 — 서비스 규모 성장 반영
분기 끝:
- observability maturity 다음 단계로 올라갈 수 있는지 self-check
- 팀 내 메트릭 리터러시 수준 점검 (누가 Grafana 잘 활용하는지, 지원 필요한 팀원은)
무료 학습 자원
Micrometer · Spring Boot 공식
1. Micrometer 공식 docs
https://docs.micrometer.io/
- Concepts: MeterRegistry · Meter 타입 · Tag · MeterFilter
- Implementations: 각 Registry 백엔드 상세 설정
- Observation API 레퍼런스
2. Spring Boot Actuator 공식 reference
https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html
- Auto-configuration 원리
- 지원 메트릭 전체 목록
- application.yml 설정 레퍼런스
3. Spring Micrometer 공식 가이드
https://micrometer.io/docs/guide
- 시작 빠른 예제
- Spring 통합 패턴
OpenTelemetry · CNCF
4. OpenTelemetry 공식 docs
https://opentelemetry.io/docs/
- OTel SDK for Java 레퍼런스
- Collector 설정 가이드
- Signal (Metrics · Traces · Logs) 연동 구조
5. CNCF 공식 자원
https://www.cncf.io/
- CNCF Landscape (observability 카테고리)
- KubeCon 무료 강연 영상 (YouTube)
- Prometheus · Grafana · Jaeger · OTel 프로젝트 공식 링크
Prometheus 공식
6. Prometheus 공식 docs
https://prometheus.io/docs/
- PromQL 완전 레퍼런스
- Storage · Federation · Remote Write 구조
- Alertmanager 설정 가이드
7. Google SRE Books (무료 온라인)
https://sre.google/books/
- Site Reliability Engineering (2016) — SLO · Error Budget · Incident
- The Site Reliability Workbook (2018) — SLO implementation guide
모두 브라우저에서 무료로 읽을 수 있어요.
유료 학습
자격증
1. Prometheus Certified Associate (PCA)
- CNCF 공식 (2023년 출시)
- PromQL · Alerting · Service Discovery · Instrumentation
- Micrometer 와 가장 직접 연결되는 자격증
- $250 전후
2. CKA (Certified Kubernetes Administrator)
- CNCF 공식
- Kubernetes 운영 — Micrometer + Prometheus Operator 환경의 기반
- $395
3. AWS · GCP · Azure 의 DevOps/SRE 자격증
- AWS Certified DevOps Engineer Professional
- Google Cloud Professional Cloud DevOps Engineer
- Microsoft Azure DevOps Engineer Expert
(Micrometer 를 CloudWatch · Datadog 백엔드로 쓸 때 관련)
참고로 Micrometer 전용 공식 자격증은 별도로 존재하지 않아요. "Micrometer 자격증"이라는 이름의 시험은 없고, PCA 와 각 클라우드 DevOps 자격증이 현실적인 선택지예요.
코스 플랫폼
Coursera:
- Spring 관련 코스 다수 (Google · Duke · UC San Diego 등 제공)
- SRE · DevOps 전문화 과정
Udemy:
- Prometheus · Grafana · Spring Boot Actuator 관련 코스 다양
- 세일 기간 이용하면 $10~$20 선
Pluralsight · LinkedIn Learning:
- Observability · Backend Engineering 카테고리
- 구독 모델 (월정액)
A Cloud Guru:
- AWS · GCP · Azure DevOps path
- 월정액 또는 연간 구독
메트릭 성숙도(Observability maturity) 5단계
Stage 1 — Reactive (0~3개월)
특징:
- 사고가 난 뒤에야 로그를 SSH 로 뒤짐
- "서버가 왜 느리지?" 는 팀원 감각으로 파악
- 알림 없음 — 사용자 신고가 첫 신호
- 메트릭이라는 개념 자체가 낯선 상태
팀 상태:
- 개발팀이 로그 파일을 grep 하는 게 전부
- 재발 예방은 "더 조심하자" 수준
Stage 2 — Visible (3~6개월)
특징:
- spring-boot-starter-actuator 추가, /actuator/prometheus 오픈
- Prometheus + Grafana 첫 구성
- JVM · HTTP 자동 메트릭 대시보드 확인 가능
- 첫 CPU · 메모리 · 에러율 알림 설정
팀 상태:
- "사고가 발생했다"를 알림으로 먼저 알 수 있게 됨
- 아직 비즈니스 커스텀 메트릭은 없음
Stage 3 — Proactive (6~12개월)
특징:
- 핵심 비즈니스 Counter · Timer 계측 완료
- RED Method (Rate · Errors · Duration) 기반 대시보드 운영
- SLO 초안 정의 + SLO 기반 알림 첫 도입
- 카디널리티 점검 습관 생김
- MeterFilter 로 방어선 구축
팀 상태:
- 사고 root cause 찾는 시간 줄어듦 (MTTR 개선)
- 개발팀이 자기 서비스 메트릭을 직접 봄
Stage 4 — Predictive (12~24개월)
특징:
- SLO Error Budget 기반 의사결정 (budget 소진되면 신기능 개발 중단)
- multi-window burn rate 알림 (1h × 5m 이중 관찰)
- publishPercentileHistogram() + serviceLevelObjectives() 전면 도입
- Prometheus Operator + ServiceMonitor 로 scrape IaC 완료
- OTel Collector 연동 시작
팀 상태:
- 사고를 예측해서 막는 경험 축적 시작
- 비즈니스 리더가 SLO 숫자를 이해하고 논의함
Stage 5 — Optimized (24개월+)
특징:
- 개발자가 코드 짜듯이 메트릭 추가 (관성화)
- 사내 MeterBinder 라이브러리 — 새 서비스 시작 즉시 표준 메트릭 자동 장착
- OpenTelemetry 표준 전환 완료 — 벤더 lock-in 없음
- 전사 Self-service observability (각 팀이 자기 대시보드 운영)
팀 상태:
- Observability 가 개발 문화의 일부
- Platform 팀이 observability 인프라 담당, 개발팀은 비즈니스 메트릭에 집중
- 회사 KPI 와 메트릭 수치가 같은 언어로 논의됨
다음 학습 — 어디로 가나
시각화·알림은 Grafana 시리즈
Micrometer 가 메트릭을 생산하는 쪽이라면, 그걸 모아서 보여주고 알림을 거는 쪽은 Grafana 예요. PromQL 쿼리로 Grafana 대시보드를 만들고 SLO 기반 알림을 설정하는 흐름은 Grafana 입문에서 운영까지 1편 에서 이어서 다룹니다. Micrometer 로 /actuator/prometheus 를 열었다면 Grafana 에 datasource 추가하는 다음 단계가 자연스럽게 이어져요.
표준 계측 와이어 — OpenTelemetry
Micrometer 와 OTel 은 경쟁이 아니라 협력이에요. Micrometer 를 OTel Collector 로 내보내는 OTLP Registry, 그리고 Observation API + tracing bridge 가 OTel Trace 를 생성하는 구조는 이미 7편에서 봤어요. 다음 깊이는 OpenTelemetry 공식 docs(opentelemetry.io) 에서 Java SDK 와 Collector 설정을 직접 따라가 보는 것을 권장해요. CNCF(cncf.io) 의 OTel 프로젝트 페이지에서 커뮤니티 동향도 볼 수 있어요.
진로 — 어디에 쓸 수 있나
백엔드 개발자
Micrometer 계측 경험이 가장 직접 쓰이는 자리. 서비스의 SLO 를 코드로 표현하고 latency 를 p99 기준으로 개선하는 능력은 시니어 레벨의 핵심 역량이에요.
SRE (Site Reliability Engineer)
SLO · Error Budget · Incident Response 의 실제 구현체가 Micrometer + Prometheus + Alertmanager 스택이에요. Google SRE Book 에서 이론으로 읽은 것을 Micrometer 로 코드화하는 경험이 SRE 전환에 직결돼요.
Platform Engineer
팀 전체가 공통으로 쓸 MeterBinder · MeterFilter · 네이밍 컨벤션 라이브러리를 만들고 운영하는 역할이 Platform 팀이에요. Micrometer 의 확장 포인트(MeterBinder · MeterRegistryCustomizer)를 깊이 이해할수록 platform 역할로 자연스럽게 확장돼요.
Observability Engineer
Datadog · New Relic · Dynatrace · Grafana Cloud 등 여러 백엔드를 운영하면서 회사의 observability 인프라 전체를 책임지는 자리예요. Micrometer 의 registry 추상화를 가장 폭넓게 활용하는 포지션이기도 해요.
9편을 끝까지 따라온 사람이라면 메트릭이 코드 어디에 들어가야 하는지, 카디널리티가 왜 위험한지, p99 를 제대로 측정하려면 histogram 이 필요한 이유가 몸에 배어 있을 거예요. 처음에는 "Micrometer 가 뭔지" 가 막막했을 텐데, 이제는 Counter 하나 추가하고 태그를 어떻게 쓸지 고민하는 게 자연스러운 개발 습관이 됐을 거라 믿어요.
측정하지 않은 것은 개선할 수 없어요. 이 시리즈가 측정을 습관으로 만드는 첫 발걸음이 되길 바랍니다.
시험 직전 한 번 더 — 시리즈 마무리 압축 노트
8편의 자산
- 1편 — 벤더 중립 facade · MeterRegistry · Tag · Observation API · Pull vs Push 개요
- 2편 — Counter(단조 증가) · Gauge(현재 값) · Timer(count+totalTime+max) · DistributionSummary(크기 분포) · LongTaskTimer · Function 계열
- 3편 — 평균 latency 맹점 · 클라이언트 percentile vs 서버 histogram · histogram_quantile · SLO 버킷
- 4편 — 태그 = 차원 · common tags · 카디널리티 폭발 원리 · URI 정규화 · MeterFilter deny·maximumAllowableTags
- 5편 — Actuator auto-configuration · 자동 계측 메트릭 목록 · @Timed · Observation API metrics+traces 동시 생성
- 6편 — CompositeMeterRegistry · step 불일치 데이터 유실 · PushGateway(단명 잡) · SimpleMeterRegistry(테스트 전용)
- 7편 — actuator 포트 분리 · ServiceMonitor/PodMonitor IaC · OtlpMeterRegistry · micrometer-tracing-bridge-otel · MeterBinder 사내 표준화
- 8편 — 카디널리티 OOM · Gauge 강한 참조 누수 · percentile 합산 오판 · step 카운터 유실 · double-counting · 인증 없는 actuator 노출 · async 태그 손실
30일 도입 체크리스트 요약
- Week 1 — 의존성 추가 + /actuator/prometheus 오픈 + 포트 보안 + 팀 컨벤션 초안
- Week 2 — 핵심 Counter · Timer · Gauge 추가 + 카디널리티 첫 점검
- Week 3 — 태그 감사 + MeterFilter 강화 + Observation API 검토 + 첫 알림 설정
- Week 4 — Grafana 대시보드 + SLO 버킷 정의 + IaC 전환 + 팀 온보딩 문서
Routine 요약
- 일 — alert 채널 확인 + PR 리뷰 시 태그 점검 (15분)
- 주 — SLO 준수율 + noisy alert 룰 조정 + 카디널리티 주간 비교 (1~2시간)
- 월 — error budget 리포트 + 의존성 버전 점검 + 컨벤션 문서 최신화 (3~4시간)
- 분기 — SLO 목표 재검토 + OTel 전환 점검 + maturity 다음 단계 self-check
학습 자원 요약
- Micrometer 공식 docs (docs.micrometer.io) — Meter 타입·Registry·Observation API
- Spring Boot Actuator reference — auto-configuration·메트릭 목록
- OpenTelemetry docs — Java SDK·Collector 설정
- Prometheus docs — PromQL·Alertmanager
- CNCF (cncf.io) — OTel·Prometheus·Jaeger·KubeCon 영상
- Google SRE Books 3권 — 무료 온라인 (sre.google/books/)
- 자격증 — PCA · CKA · AWS/GCP/Azure DevOps
- 코스 — Coursera · Udemy · Pluralsight · A Cloud Guru
Maturity 5단계 요약
- Stage 1 Reactive (0~3개월) — 사고 후 SSH grep
- Stage 2 Visible (3~6개월) — /actuator/prometheus · 자동 메트릭 · 첫 알림
- Stage 3 Proactive (6~12개월) — 비즈니스 Counter·Timer · SLO 초안 · MeterFilter
- Stage 4 Predictive (12~24개월) — Error Budget · burn rate · histogram SLO · IaC
- Stage 5 Optimized (24개월+) — self-service · OTel 표준 · 사내 MeterBinder 라이브러리
진로
- 백엔드 개발자 — 시니어 역량: SLO 를 코드로 + p99 기반 개선
- SRE — SLO·Error Budget·Incident 구현체가 Micrometer 스택
- Platform Engineer — MeterBinder·MeterFilter 사내 표준 라이브러리
- Observability Engineer — 다중 registry 백엔드 운영·회사 관측 인프라 전체
공식 자원: Micrometer 공식 docs · OpenTelemetry docs · CNCF · Google SRE Books 에서 무료로 이어서 학습할 수 있어요.
시리즈 다른 편 (앞뒤 글 모음)
이전 글:
- 4편 — 태그·차원·카디널리티 깊이
- 5편 — Spring Boot Actuator 통합 깊이
- 6편 — Registry·백엔드·push vs pull 깊이
- 7편 — 운영 자동화·IaC·OpenTelemetry 연동
- 8편 — 운영 함정 + 사고 케이스 깊이
다음 글: 시리즈 마지막 편이에요.