Observability
글 6개
Observability · OpenTelemetry
세 기둥을 하나로 - 실무의 관측가능성
로그·메트릭·트레이스가 따로 놀면 반쪽이다. trace ID가 셋을 하나로 잇고, OpenTelemetry가 한 규격으로 심게 한다. 무엇을 남길지의 비용 문제와 함께 시리즈를 닫는다.
·장애를 어떻게 보나 6편
Observability · Alerting
헬스체크와 알림 - 터지기 전에, 터졌을 때
신호를 모았으면 언제 사람을 부를지 정해야 한다. 살아있음과 준비됨의 차이, 증상에 알리고 원인은 대시보드에 두는 원칙, SLO와 에러 예산, 그리고 알림 피로까지.
·장애를 어떻게 보나 5편
Observability · Tracing
분산 트레이싱 - 요청 하나를 끝까지 따라간다
여러 서비스를 지나는 요청 하나가 어디서 느렸는지, 로그와 메트릭은 못 답한다. 스팬과 트레이스, 폭포수로 병목을 짚는 법, 서비스 경계를 넘는 상관ID까지.
·장애를 어떻게 보나 4편
Observability · Metrics
메트릭 - 지금 시스템이 어떤가
메트릭은 시간에 따른 수다. 카운터·게이지·히스토그램 세 유형, 라벨이 비용이 되는 카디널리티 함정, 그리고 평균이 아니라 분포로 봐야 하는 이유까지.
·장애를 어떻게 보나 3편
Observability · Logging
로그 - 무슨 일이 있었나
로그는 사건의 기록이다. 문자열로 찍으면 사람만 읽고 기계는 못 읽는다. 구조화 로깅으로 필드를 남기고, 상관ID로 흩어진 줄을 한 요청으로 꿰는 법까지.
·장애를 어떻게 보나 2편
Observability · Monitoring
관측가능성이 푸는 문제 - 터졌는데 어디가 문제인지 모른다
서비스가 여러 조각으로 나뉘면 '느리다' 신고 하나에 범인 후보가 수십이다. 모니터링과 관측가능성이 어떻게 다른지, 세 기둥(로그·메트릭·트레이스)이 각자 어떤 질문에 답하는지 본다.
·장애를 어떻게 보나 1편