로그 중앙화

1) 로그를 중앙 집중화 한 이유

• 사고 근에 대한 검색 속도 향상 (요청 -id/추적 ID에 의한 상관 관계);
• 증상 (오류, 이상) 에 대한 신호 경보를 구축 할 수 있습니다.
• 감사 흔적을 제공하십시오 (누가/언제/무엇을했는지).
• 보존 및 보관 통일로 인한 비용 절감.

2) 기본 원칙

1. 키가없는 "무료 텍스트" 는 없습니다 (JSON/RFC5424).
2. 키의 균일 한 체계: 'ts, 수준, 서비스, env, 지역, 테넌트, trace _ id, span _ id, 요청 _ id, user _ id (마스크), msg, kv...'.
3. 기본 상관 관계: 게이트웨이에서 백엔드 및 로그로 플립 트레이스 _ id.
4. 소음 최소화: 올바른 수준, 샘플링, 반복 중복 제거.
5. 설계 별 안전: PII 마스킹, RBAC/ABAC, 불변성.
6. 경제: 뜨거운/따뜻한/차가운, 압축, 집계, TTL 및 재수 화.

3) 전형적인 아키텍처

EFK/ELK: (Fluent Bit/Fluentd/Filebeat) → (Kafka-о → (ElasticSearch/OpenSearch) → (Kibana/OpenSearch 대시 보드). 보편적 인 검색 및 집계.
Loki와 같은 (레이블로 로그 인덱싱): Promtail/Fluent Bit → Loki → Grafana. 대량의 저렴한 라벨 필터 + 선형보기.
클라우드: CloudWatch/Cloud Logging/Log Analytics + 콜드 스토리지 (S3/GCS/ADLS) 및/또는 SIEM으로 내보냅니다.
데이터 레이크 접근 방식: 지난 N 일 동안 배송 업체 → 객체 스토리지 (parquet/iceberg) → 저렴한 분석 쿼리 (Athena/Bigquery/Spark) + 온라인 계층 (OpenSearch/Loki).

권장 사항: 재수 화 능력이있는 호수에 온라인 계층 (7-14 일 더운) 과 보관 (달/년) 을 유지합니다.

4) 다이어그램 및 로그 형식 (권장 사항)

json
{
"ts":"2025-11-01T13:45:12.345Z",
"level":"ERROR",
"service":"payments-api",
"env":"prod",
"region":"eu-central",
"tenant":"tr",
"trace_id":"0af7651916cd43dd8448eb211c80319c",
"span_id":"b7ad6b7169203331",
"request_id":"r-7f2c",
"user_id":"",        // masked
"route":"/v1/payments/charge",
"code":"PSP_TIMEOUT",
"latency_ms":1200,
"msg":"upstream PSP timeout",
"kv":{"provider":"psp-a","attempt":2,"timeout_ms":800}
}

표준: 시간에 대한 RFC3339는 snake _ case의 키 'TRACE/DEBUG/INFO/WARN/ERROR/FATAL' 세트에서 수준입니다.

5) 로그 레벨 및 샘플링

DEBUG - 개발/단계에서만; 깃발과 TTL로 제작.
INFO-요청/이벤트의 수명주기.
WARN-SLO에 영향을 미치지 않는 의심스러운 상황.
ERROR/FATAL-요청/사용자에게 미치는 영향.

• 반복되는 오류에 대한 속도 제한 (예: 1/sec/key).
• 흔적의 꼬리 샘플링 ("나쁜" 요청에 대해서만 전체 로그/흔적을 남기십시오).
• 동적: 오류가 발생하면 세부 사항을 줄이고 요약을 저장하십시오.

6) 통나무 배달 (에이전트 및 배송 업체)

노드에서: Fluent Bit/Filebeat/Promtail은 표준 파일/정션, 파싱, 마스킹, 버퍼링을 수집합니다.
네트워크 대기열: 피크 스무딩, 배상 및 주문을위한 Kafka/NATS.
신뢰성: 역압, 디스크 버퍼, 전달 확인 (적어도 한 번), dem 등원 인덱스 (키 해시).
가장자리에서 필터링: 그물을 치기 전에 "채터" 와 비밀을 버립니다.

7) 인덱싱 및 스토리지

시간 분할 (일일/주간) + 'env/region/tentent' (색인 템플릿 또는 레이블을 통해)

• 핫 (SSD, 3-14 일): 빠른 검색 및 경고.
• 따뜻한 (HDD/냉동고, 30-90 일): 때때로 우리는 본다.
• 콜드/아카이브 (객체, 개월/년): 규정 준수 및 드문 조사.
• 압축 및 회전: ILM/ISM (수명주기 정책), ggip/zstd, 다운 샘플링 (집계 테이블).
• 재수 화: 조사를 위해 보관 된 배치를 "핫" 클러스터에 임시로드합니다.

8) 검색 및 분석: 샘플 쿼리

사건: 시간 필터 × '서비스 =...' × '레벨> = ERROR' × 'trace _ id '/' 요청 _ id'.
제공자: '코드: PSP _' 및 'kv. 공급자: psp-a '는 지역별로 그룹화되었습니다.
Anomalies: 메시지 빈도 증가 또는 현장 분포 변경 (ML 검출기, 규칙 기반).
감사: '범주: 감사' + '행위자 '/' 자원' + 결과.

9) 지표 및 추적과의 상관 관계

동일한 식별자: 세 신호 모두에서 'trace _ id/span _ id' (메트릭, 로그, 추적).
그래프에서 링크: 'trace _ id' 를 통해 p99 패널에서 로그로 클릭 가능한 전환.
릴리스 주석: 빠른 바인딩을위한 메트릭 및 로그의 버전/카나리아.

10) 안전, PII 및 준수

현장 분류: PII/비밀/재무-입구에서 마스크 또는 삭제 (Fluent Bit/Lua 필터, Re2).
RBAC/ABAC: 역할 별 색인/라벨 액세스, 행/필드 레벨 보안.
감사 및 규제 요구 사항에 대한 불변 성 (WORM/추가 전용).
보존 및 "잊을 권리": 키에 의한 TTL/삭제, 토큰 화 'user _ id'.
서명/해시: 중요한 저널의 무결성 (관리자 조치, 지불).

11) SLO 및 파이프 라인 로그 메트릭

배송: 99. 핫레이어에서 이벤트의 9%

손실: <0. 24 시간에 01% (참조 표시에 따라).
검색 가용성: 99 이상. 28 일 만에 9%.

요청 대기 시간: 일반적인 필터에서 p95 μ2-5 초

비용: $/1M 이벤트 및 $/storage/GB 레이어.

12) 대시 보드 (최소)

파이프 라인 건강: 배송 업체의 출입/배송, 충전 버퍼, Kafka 지연.
서비스/코드 별 오류: 상위 N, 추세, 백분위 수 '대기 시간 _ ms'.
감사 활동: 관리 작업, 공급자 오류, 액세스.
경제학: 볼륨/일, 인덱스 성장, 계층 별 가치, "고가의" 쿼리.

13) 운영 및 플레이 북

로그 스톰: 에이전트의 공격적인 샘플링/속도 제한을 가능하게하고, 완충액을 올리고, 스트림의 일부를 일시적으로 따뜻하게 옮깁니다.
스키마 드리프트: 새로운 키/유형이 나타나는지 경고하고 스키마 카탈로그 협상을 시작하십시오.
느린 검색: 색인 재건, 복제품 증가, "무거운" 쿼리 분석, 오래된 배치 보관.
보안 사건: 즉각적인 불변 활성화, 아티팩트 오프로드, 역할에 따라 액세스 제한, RCA.

14) FinOps: 통나무를 끊지 않는 방법

verbosity 제거: 멀티 라인 스택 트레이스를 '스택' 필드로 바꾸고 샘플을 재생하십시오.
TTL 사용: 'env '/' 레벨 '/' 범주' 에 따라 다릅니다.
드문 액세스를 위해 Loki/archive + 주문형 재수 화물을 사용하십시오.
당사자 및 압축: 더 큰 당사자는 더 저렴하지만 검색 SLA를 주시하십시오.
빈번한 평가 (일일 집계) 를 재료화하십시오.

15) 악기 예

유창한 비트 (마스킹 및 OpenSearch로 전송)

ini
[INPUT]
Name       tail
Path       /var/log/app/.log
Parser      json
Mem_Buf_Limit   256MB

[FILTER]
Name       modify
Match
Remove_key    credit_card, password

[OUTPUT]
Name       es
Host       opensearch.svc
Port       9200
Index       logs-${tag}-${date}
Logstash_Format  On
Suppress_Type_Name On

(PHP 3 = 3.0.6, PHP 4)

nginx log_format json escape=json '{ "ts":"$time_iso8601","remote":"$remote_addr",'
'"method":"$request_method","path":"$uri","status":$status,'
'"bytes":$body_bytes_sent,"ua":"$http_user_agent","trace_id":"$http_trace_id"}';
access_log /var/log/nginx/access.json json;

OpenSearch ILM 정책 (핫 → 따뜻한 → 삭제)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
"delete":{ "min_age": "90d", "actions": { "delete": {} } }
}
}
}

16) 구현 점검표

• 허용 된 필드 레이아웃 및 로그 레벨; 추적/요청 -id 상관이 활성화됩니다.
• 마스킹 및 버퍼가있는 변형 된 에이전트 (Fluent Bit/Promtail).
• 온라인 레이어 (OpenSearch/Loki/Cloud) 및 아카이브 (S3/GCS + parquet) 를 선택했습니다.
• ILM/ISM + 핫/워밍/콜드 보존 정책, 재수 화 공정.
• RBAC/ABAC, 감사 불변성, 액세스 로그.
• 파이프 라인 대시 보드, 손실 경고/지연/디스크 버퍼.
• 플레이 북: 로그 스톰, 스키마 드리프트, 느린 검색, 보안 사고.
• 재정 한도: $/1M 이벤트, "비싼" 요청에 대한 할당량.

17) 반 패턴

구조없는 텍스트 로그 → 필터링하고 집계 할 수 없음.
INFO → 볼륨 폭발에서 거대한 추적.
모든 서비스에 대한 상관 관계 부족 → "펄럭임".
"모든 것을 영원히" 저장 → 비행기처럼 구름 청구서.
로그의 비밀/PII → 규정 준수 위험.
수동 지수는 판매 → 드리프트 및 긴 검색 다운 타임으로 편집됩니다.

18) 결론

로그 중앙 집중화는 스택뿐만 아니라 시스템입니다. 표준화 된 스키마, 상관 관계, 보안 배송 업체, 계층 형 스토리지 및 엄격한 액세스 정책은 로그를 SRE, 보안 및 제품을위한 강력한 도구로 바꿉니다. 올바른 보류 및 FinOps는 예산을 유지하고 파이프 라인 SLO 및 플레이 북은 조사를 빠르고 재현 가능하게 만듭니다.