인프라 모니터링

인프라 모니터링

1) 목표와 프레임

인프라 모니터링은 플랫폼의 건강, 성능 및 가용성에 대한 신호 시스템입니다. 그는 다음과 같이해야합

사용자가 충돌하기 전에 경고합니다 (조기 탐지).
근본 원인 (증상에서 원인으로) 을 진단하십시오.
릴리스 및 자동 롤백의 SLO 게이팅을 지원합니다.
사후 분석 (데이터로 증거) 을 제공하십시오.

지원 원칙: 의도적으로 관찰 가능, 소음 감소-더 많은 신호, 반응 자동화, 단일 진실 패널.

2) 관찰 가능성 트라이어드

타임 시리즈-요율/수요/오류/포화 (USE/RED)

로그: 컨텍스트가있는 이벤트 세부 사항; 비밀/PII가 없습니다.
추적: 인과 관계가있는 분산 된 사례.

• 프로파일 링 (CPU/heap/lock/io), 시스템 수준의 eBPF.
• 이벤트/감사 (K8 이벤트, 구성 요소/비밀의 변경).

3) SLI/SLO/SLA-품질 언어

SLI: '가용성', '오류 _ rate', 'p95 _ latency', '큐 _ lag'.

SLO (대상): "성공적인 요청 30 일 만에 9% "

오류 예산: 내성; 자동 정지 릴리스에 사용됩니다.

yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4) 모니터링 레이어 맵

1. 호스트/VM/노드: CPU/로드/Steal, RAM/Swap, 디스크 IOPS/Latency, 파일 시스템.
2. 네트워크/LB/DNA: RTT, 패킷/방울, 백 로그, SYN/타임 아웃, 건강 프로브.
3. Kubernetes/Orchestrator: API 서버, etcd, 컨트롤러, 스케줄러; 포드/노드, 보류/퇴거, 스로틀 링, kube 이벤트.
4. 서비스/컨테이너: RED (속도/오류/지속 시간), 준비/활력.
5. 데이터베이스/캐시: QPS, 잠금 대기, 복제 지연, 버퍼 적중, 느린 쿼리.
6. 대기열/버스: 소비자 지연, 요청/데드 레터, 처리량.
7. 스토리지/클라우드: S3/Blob 오류 및 대기 시간, 공급자의 429/503.
8. 주변 경계: WAF/Rate Limits, 경로 별 4xx/5xx, CDN입니다.
9. 합성: HTP 스크립트 확인 (예금/출력), TLS/인증서.
10. 경제/용량: 서비스 당 비용, 활용, 헤드 룸.

5) 화이트 박스... 블랙 박스

화이트 박스: 서비스 내 수출 업체/SDK (Prometheus, OpenTelemetry).
블랙 박스: 다른 지역의 외부 샘플 (가용성, 대기 시간, SL 만료).
결합: "외부 표시" + "진단".

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernetes: 키 신호

'apiserver _ 요청 _ total', 'etcd _ server _ has _ leader', etcd fsync.
'container _ cpu _ cfs _ throttled _ settled _ total', 'node _ pressure'.
패드: Pending/CrashLoopBackOff, OOMKilled, 다시 시작합니다.
계획/제한: 요청 대 한계, PodDisruptionBudget, HPA/VPA.
네트워크: NetworkPolicy 드롭, 연결 고갈.

"클러스터 건강", "워크로드 포화", "최고의 오류 서비스".

7) DB 및 대기열

PostgreSQL/MySQL: 복제 지연, 교착 상태, 느린 쿼리%, 체크 포인트 I/O.
Redis/Memcashed: 적중 비율, 퇴거, 거부 된 연결.
Kafka/RabbitMQ: 소비자 지연, 포장 해제, 요청, 중개인 ISR, 디스크 사용.

8) RED/USE 지표 및 비즈니스 상관 관계

RED: 'rate' (RPS), '오류' (4xx/5xx), '지속 시간' (p95/p99).
사용 (리소스 용): 활용, 포화, 오류.
예금/지불 성공, 사기 플래그, 전환-카나리아 릴리스의 "가드" 입니다.

9) 경고 구조

Tier-1 (페이지): SLO에 영향을 미치는 사고 (가용성, 5xx, 대기 시간, 클러스터 중요 구성 요소 장애).
Tier-2 (티켓): 용량 저하, SLO에 영향을 미치지 않는 오류 증가.
3 단계 (정보): 추세, 예측 용량, 지출 인증서.

에스컬레이션 규칙: 침묵 시간/중복 압축, 통화 중 회전, 햇볕에 따라.

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) 프로 메테우스 규칙 예

10. SLO 임계 값이 1 5xx 오류

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10. 2 연소 오류 예산 (다중 창 연소)

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10. 3 시스템 포화 (CPU 스로틀 링)

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11) 로그: 수집, 정규화, 유지

표준화: JSON 로그: 'ts', 'level', 'service', 'trace _ id', 'user/tentent'.
파이프 라인: 에이전트 (Fluent Bit/Vector) → 버퍼 → 인덱스/스토리지.
수정: 가장자리에서 PII/비밀 마스킹.
보존: 빠른 보관 클래스 (7-14 일), 콜드 아카이브 (30-180 일).
시맨틱: 오류 예산/제거-별도의 채널.

12) 트레일 및 OpenTelemetry

계측기 입력 지점 (게이트웨이), kliyent → servis 호출, DB/캐시/대기열.
빠른 탐색을 위해 속성 (Exemplars) 을 추적하는 바인드 메트릭.
중앙 게이트웨이 인 OTel Collector: 필터링, 샘플링, 선택한 백엔드로 내보냅니다.

yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13) 합성 및 외부 점검

HTP는 비즈니스 시나리오 (로그인, 예금, 인출, 구매) 를 실행합니다.
TLS/Domain: 인증서 용어/CAA/DNA 상태.
지역: 주요 국가/공급자의 샘플 (라우팅/블록 목록).
녹색 내부 원격 측정을 사용하더라도 사용자가 사용할 수없는 경우 합성에주의해야합니다.

14) 프로파일 링 및 eBPF

지속적인 프로파일 링: 핫 기능 식별, 잠금 장치.

eBPF: 최소한의 오버 헤드로 제품의 시스템 이벤트 (

프로파일은 롤백 신호로 긴장없이 (티켓) 및 출시 후 회귀에 대해 경고합니다.

15) 대시 보드와 "진실 패널"

1. 플랫폼 개요: 주요 서비스 별 SLI/SLO, 오류 예산, 경고.

2. API RED: 경로 별 RPS/ERRORS/DURATION.

3. K8s 클러스터: 컨트롤 플레인,

4. DB/캐시: 지연/잠금/느린 쿼리%, 적중 비율.

5. 대기열: 백 로그/지연, 실패/재 시도.

6. 릴리스 당: 전후 메트릭 (카나리아 창) 의 비교.

7. FinOps: 네임 스페이스/서비스 당 비용, 유휴/대형 реслре.

16) 사건, 경보 소음 및 에스컬레이션

중복 제거-서비스/원인 그룹화, 캐스케이드 억제

침묵/유지 보수: 릴리스/마이그레이션이 모든 것을 "페인트" 해서는 안됩니다.
런북: 진단 단계와 롤백 "버튼" 이있는 각 중요한 경고.
사후: 타임 라인, 그들이 배운 것, 신호가 추가/청소 된 것.

17) 모니터링의 안전

읽기/편집 규칙/데이터 정보를위한 RBAC.
비밀: 비밀 관리자를 통한 수출/에이전트 토큰.

격리: 클라이언트/테넌트 메트릭-별도의 공간/탭으로

무결성: 에이전트/빌드의 서명, GitOps를 통한 구성 (병합 검토).

18) 금융 및 용량 (FinOps)

쿼타와 예산; 비정상적인 성장에 대한 경고.
올바른 크기: 요청/제한 분석, CPU/RAM 활용, 중요하지 않은 작업의 스팟 인스턴스.
성능 KPI로서 "요청 당 비용/임차인".

19) 반 패턴

맞춤형 SLI가없는 인프라 지표.
100 개 이상의 경고는 "모든 것에 대해" → 통화 실명.
로그는 유일한 소스입니다 (메트릭 및 추적 없음).
다양한 검토/검토없이 돌연변이 대시 보드.
합성 부족: "모든 것이 녹색" 이지만 전면을 사용할 수 없습니다.
릴리스와 관련이 없습니다. "현재 X에서 변경된 내용" 에 대답하는 것은 불가능합니다.

20) 구현 점검표 (0-60 일)

0-15 일

3-5 개의 주요 서비스에 대해 SLI/SLO를 정의하십시오.
기본 내보내기/에이전트를 활성화하고 JSON 로그를 표준화하십시오.
Tier-1 알림 설정 (가용성, 5xx, p95).

16-30 일

중요한 시나리오에 대한 합성을 추가하십시오.

입력/중요 서비스에서 OTel 사용하기

대시 보드 "릴리스 당" 및 오류 예산 연소 규칙.

31-60 일

고급 신호로 DB/대기열/캐시를 덮으십시오.
높은 CPU 서비스에 대한 eBPF/프로파일 링을 구현합니다.
규칙/대시 보드/경고, 정기적 인 소음 청소를위한 GitOps.

21) 성숙도 지표

주요 서비스의 SLO 적용 범위는 95% 입니다.
MTTA/MTTR (대상: 최소/수십 분).
자동 동작 또는 빠른 롤백으로 폐쇄 된 Tier-1 경고 비율.
"유용한 "/" 잡음" 경고의 비율은> 3: 1입니다.
모든 "돈" 경로의 합성 범위 = 100%.

22) 응용 프로그램: 미니 템플릿

Prometheus-상태 클래스 별 가용성

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana-카나리아 팁

expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m])) by (le,version))

Alertmanner-의무와 침묵

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) 결론

모니터링은 그래프 세트가 아니라 SRE 운영 체제: 품질 계약으로서의 SLI/SLO, 진실의 원천으로서의 메트릭/트레일/로그, 제어 된 신호로서의 경고, "사용자 음성" 으로서의 합성, GitOps 변경 규칙. 호스트에서 API로 단일 루프를 구축하고 릴리스 및 롤백에 연결하면 플랫폼이 예측 가능하고 빠르며 경제적입니다.