GH GambleHub

관찰 가능성: 로그, 메트릭, 추적

관찰 가능성: 로그, 메트릭, 추적

1) 왜 필요한가

관찰 가능성-시스템이 상태에 대한 계획되지 않은 질문에 대답 할 수있는 능력. 세 가지 주요 신호에 의존합니다

메트릭은 SLI/SLO 및 증상 경고를위한 컴팩트 한 집계입니다.
추적-엔드 투 엔드 쿼리 체인.
로그-조사 및 감사를위한 자세한 이벤트.

목적: 오류 예산 내에서 빠른 RCA, 예방 경고 및 관리 된 신뢰성.

2) 건축 원칙

단일 컨텍스트: 모든 곳에서 'trace _ id', 'span _ id', 'tenit _ id', '요청 _ id', 'user _ agent', 'client _ ip _ hash' 를 던집니다.
표준: SDK/에이전트의 OpenTelemetry (OTel), JSON 로그 형식 (표준, 스키마 포함).
증상> 원인: CPU가 아닌 사용자 증상 (대기 시간/오류) 에 의한 경고.
신호 통신: → 메트릭에서 예시까지 → 'trace _ id' 로 특정 로그까지.
보안 및 개인 정보 보호: 로그에서 PII 마스킹, 운송 중 암호화/휴식 시간, 불변의 감사 로그.
멀티 테넌시: 네임 스페이스/키/정책 분리.

3) 신호 분류 및 체계

3. 1 메트릭

서비스에 대한 RED (속도, 오류, 지속 시간) 및 인프라에 대한 사용 (활용, 포화, 오류).
계산기, 게이지, 히스토그램/요약. 대기 시간의 경우 고정 버킷이있는 히스토그램입니다.
Exemplars: "hot" 히스토그램 빈에서 'trace _ id' 에 대한 참조.

미니 스킴의 메트릭 (논리. 모델):

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3. 2 흔적

Span = '이름', '시작/끝', '속성', '이벤트', '상태' 가있는 작업.
내약성에 대한 W3C 추적 컨텍스트.
샘플링: 기본 (머리) + 동적 (꼬리) + "중요도" 규칙 (오류, 높은 p95).

3. 3 로그

구조화 된 JSON 만; 레벨: DEBUG/INFO/WARN/ERROR.
필요한 필드는 'ts _ utc', '수준', '메시지', 'trace _ id', 'span _ id', 'tenit _ id', 'env', 'service', 'region', 'host', 'laces {}' 입니다.
금지: 비밀, 토큰, PAN, 암호. PII-토큰 화/마스크 만.

로그 문자열 (JSON) 의 예:
json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4) 수집 및 운송

에이전트/내보내기 (daemonset/sidecar) → → 버스/가장 많이 사용되는 노드 (SL/mSL) 의 버퍼 → 신호 저장소.
요구 사항: 역압, 배상, 중복 제한, 카디널리티 제한 (라벨!), "로그 폭풍" 에 대한 보호.

메트릭: OTLP를 통해 풀 (Prometheus 호환) 또는 푸시.
추적: OTLP/TH (gRPC), 수집기의 테일 샘플러.
로그: 로컬 컬렉션 (journal/docker/board) → parser → normalizer.

5) 보관 및 보존 (계층)

지표: 뜨거운 TSDB 7-30 일 (다운 샘플 포함), 더 긴 기간 (90-365 일) 동안 집계.
흔적: 1-7 일이 가득 찬 다음 "중요한" 서비스의 집계/범위; '서비스', '상태', '오류' 에 대한 저장 색인.
로그: 핫 인덱스 7-14 일, 따뜻한 3-6 개월, 최대 1-7 년 (규정 준수) 보관. 감사-WORM.

비용 최적화: 다운 샘플링, 판매 DEBUG 필터링, 라벨 할당량, 트랙 샘플링.

6) SLI/SLO, 경고 및 의무

SLI: 가용성 (% 성공적인 요청), 대기 시간 (p95/p99), 5xx 공유, 데이터 신선도, 성공적인 작업 공유.
SLO: SLI 대상 (예: 99. 9% 성공하면 400ms입니다.
오류 예산: 0. 1% "오차 한계" → 픽션/실험 규칙.

증상에 의한 경고 (예):
  • 'ALERT HighLatency' есл19 'p99 (http _ server _ guide _ seconds {route = "/pay "})> 1s' 5
  • 'ALERT ErrorRate' есл달러 '속도 (http _ insts _ total {코드 = ~ "5"..} [5m] )/rate (http _ insers _ total [5m])> 0. 02`.
  • Silo 경고 (CPU/디스크) -페이징없이 보조 기능으로 만 가능합니다.

7) 신호 상관

메트릭은 "빨간색" → 모범을 클릭하여 특정 'trace _ id' → "느린" 스팬 → 동일한 'trace _ id' 로 로그를 엽니 다.
릴리스와의 상관 관계: 속성 '버전', 'Image _ sha', 'flag _ flag'.
데이터/ETL: 'dataset _ urn', 'run _ id' 의 경우 계보에 링크하십시오 (해당 기사 참조).

8) 샘플링 및 카디널리티

메트릭: 레이블 제한 ('user _ id', 'setion _ id' 없이); 등록시 할당량/검증.
추적: 헤드 샘플 (입력시) 과 테일 샘플 (콜렉터에서) 을 "5xx, p99, 오류 인 모든 것-100%" 규칙과 결합합니다.
통나무: 레벨 및 스로틀 링; 빈번한 반복 오류-이벤트 집계 (dedupe key).

테일 샘플링 예 (개념적으로 OTel Collector):
yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9) 보안 및 개인 정보 보호

대중 교통/휴식 중: 암호화 (SL 1. 3, AEAD, KMS/HSM).
PII/비밀: 선적 전 소독제, 토큰 화, 마스킹.
액세스: 읽을 ABAC/RBAC; 생산자/독자/admins 역할의 분리.
감사: 로그/추적에 대한 액세스 로그의 변경되지 않음; 수출-암호화 된 형태로.
멀티 테넌시: 정책이있는 네임 스페이스/테넌트 레이블; 암호화 키 격리.

10) 설정 프로파일 (조각)

프로메테우스:
yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']
slo. 규칙. yaml (예: RED):
yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m
OpenTelemetry SDK (의사 코드):
python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

(PHP 3 = 3.0.6, PHP 4)

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11) 데이터/ETL 및 스트리밍

데이터 용 SLI: 신선도 (최대 지연), 완전성 (행 대 기대), "품질" (유효성 검사기/복제본).
경고: 창 건너 뛰기, 소비자 지연, DLQ 성장.
상관 관계: 'run _ id', 'dataset _ urn', 계보 이벤트; 파이프 라인 추적 (배치/파티션 당 스팬).
Kafka/NATS: 생산자/소비자 지표, 지연/고장; 헤더로 추적 ('추적' 포함).

12) 프로파일 링 및 eBPF (추가 신호)

저수준 핫 경로 CPU/alloc/IO; 사고 당 프로필.
eBPF 원격 측정 (네트워크 지연, DNA, 시스템 호출) 은 'trace _ id '/PID에 연결됩니다.

13) 관찰 가능성 테스트

신호 계약-CI에 대한 메트릭/라벨/히스토그램 수출을 확인하십시오.
합성 프로브: 외부 SLI에 대한 RUM 시나리오/시뮬레이션 클라이언트.
혼돈/화재 훈련: 종속성 비활성화, 저하-경보와 승무원의 반응 방식을 살펴 봅니다.
연기: 배포 후 새로운 엔드 포인트에 지표와 흔적이 있는지 확인하십시오.

14) 비용 및 부피 제어

신호/명령에 의한 예산; 대시 보드 "신호 당 비용".
예산에 따른 카디널리티 (카디널리티의 SLO), 새로운 레이블의 제한.
감사를위한 다운 샘플링, 데이터 클래스 프레젠테이션, 콜드 아카이브 및 WORM.

15) 관측 가능성 플랫폼의 작동 및 SLO

플랫폼 SLO: 99. 성공적인 섭취의 9%; 미터법 인덱스로 지연되고, 로그는 지정 2 분, 지시는 1 분입니다.
플랫폼 경고: 주입 지연, 낙하 성장, 서명/암호화 오류, 버퍼 오버플로.
DR/HA: 다중 영역, 복제, 설정/규칙 백업.

16) 점검표

판매하기 전에:
  • 모든 곳에서 'trace _ id '/' span _ id' 가 던져집니다. JSON은 다이어그램으로 로그합니다.
  • 히스토그램이있는 RED/USE 지표; 모범 → 정렬.
  • 꼬리 샘플링 활성화; 5xx/p99 규칙 = 100%.
  • 증상에 의한 경고 + 런북; 조용한 시간/플랩 방지.
  • PII 소독제; 감사를 위해 휴식/대중 교통 WORM의 암호화.
  • 볼륨/카디널리티에 대한 보존 및 예산.
작동:
  • 월간 경보 검토 (노이즈/정확도), 튜닝 임계 값.
  • 오류 예산 보고서 및 취한 조치 (변형, 경화).
  • 중요한 경로는 대시 보드/로그/추적 코팅을 확인하십시오.
  • 교육 사건 및 런북 업데이트.

17) 런북

RCA: p99/임금 인상

1. '체크 아웃' 을 위해 RED 대시 보드를 엽니 다.
2. 모범으로 이동 → 느린 트랙 → "좁은 스팬" 을 나타냅니다 (예: '게이트웨이. 전화 ').
3. 'trace _ id' → 타임 아웃/리트레이보기로 로그를 엽니 다.
4. 롤백 기능/RPS 제한을 사용하고 종속성 소유자에게 알리십시오.
5. 안정화 후-RCA, 최적화 티켓, 재생 테스트.

데이터의 변칙적 (로그 DWH):

1. SLI "신선도" 빨간색 → 트랙 작업 → 실패 피치.

2. 브로커/DLQ 로그, 커넥터 오류를 확인하십시오.

3. 재처리를 시작하고 상태 채널을 통해 소비자 (BI/제품) 에게 알리십시오.

18) 빈번한 오류

스키마가없고 'trace _ id' 가없는 로그. 때때로 조사가 지연됩니다.
증상 대신 인프라에 대한 경고. 페이징은 "우유로" 간다.
경계없는 카디널리티 메트릭. 비용 폭발 및 불안정성.
모두 100% 트랙입니다. 비싸고 불필요한; 스마트 샘플링을 가능하게합니다.
로그의 PII/비밀. 소독제 및 빨간색 목록을 포함합니다.
"음소거" 기능. 메트릭/추적/로그가없는 새 코드.

19) FAQ

Q: 로그의 원본 텍스트를 저장해야합니까?
A: 그렇습니다. 그러나 보존 및 보관; 경고 및 SLO의 경우 집계가 충분합니다. 감사-WORM.

Q: 머리 또는 꼬리 샘플링과 같은 트랙에 무엇을 선택해야합니까?
A: 결합: 베이스 코트에 대한 헤드 확률 및 오류 및 이상에 대한 테일 규칙.

Q: 사용자 메트릭과 기술 메트릭을 어떻게 연결합니까?
A: 일반적인 'trace _ id' 및 비즈니스 레이블 ('경로', '테넌트', '계획') 과 트랙과 상관 관계가있는 제품 이벤트 (변환) 를 통해.

Q: 경고에 빠지지 않는 방법?
A: 증상을 극복하고, 조용한 시간을 입력하고, 중복 제거, 그룹화, SLO 우선 순위 지정 및 경고 당 기본값으로 소유자.

관련 자료:
  • "감사 및 불변의 통나무"
  • "대중 교통/휴식 시간에 암호화"
  • "비밀 관리"
  • "데이터 원점 (리니지)"
  • "디자인 별 개인 정보 보호 (GDPR)"
  • "웹훅 배송 보증"
Contact

문의하기

질문이나 지원이 필요하시면 언제든지 연락하십시오.우리는 항상 도울 준비가 되어 있습니다!

통합 시작

Email — 필수. Telegram 또는 WhatsApp — 선택 사항.

이름 선택 사항
Email 선택 사항
제목 선택 사항
메시지 선택 사항
Telegram 선택 사항
@
Telegram을 입력하시면 Email과 함께 Telegram에서도 답변드립니다.
WhatsApp 선택 사항
형식: +국가 코드 + 번호 (예: +82XXXXXXXXX).

버튼을 클릭하면 데이터 처리에 동의하는 것으로 간주됩니다.