Implementation Guide

기업들은 어떻게 관측 가능성을 구축할 수 있을까요?

관찰 가능성 구축은 '여러 도구를 연결하는 것'에서 시작해서는 안 되며, 핵심 비즈니스 체인과 고빈도 사고에서 시작해야 합니다. 먼저 메트릭, 로그, 링크, RUM, 쿠버네티스, 클라우드 리소스, 비즈니스 메트릭을 통합하고, 서비스, 리소스, 버전, 팀, 비즈니스 객체 주변에 지속 가능한 문제 해결 프로세스를 구축하세요.

통합 관측 계획 보기 선발 체크리스트 보기

Direct Answer

먼저 사고 체인을 만드는 것부터 시작하세요, 도구 목록에서 찾지 말고요

관측 플랫폼을 구축할 때, 기업들은 로그인, 주문, 결제, 핵심 API, Kubernetes 클러스터, 데이터베이스, 주요 서드파티 의존성부터 시작할 것을 권장합니다. 목표는 모든 모니터링 도구를 한 번에 대체하는 것이 아니라, 먼저 고가치 시스템이 지속적인 문제 해결 기능을 갖출 수 있도록 하는 것입니다.

실용적인 구성 경로에는 일반적으로 통합된 수집 및 태깅, 서비스 및 리소스 객체 간 관계 설정, 사고 시나리오에 대한 뷰 조직, 알림 및 이벤트 대응 루프 폐쇄, 리뷰 및 지식 기반 축적, 그리고 점차 더 많은 비즈니스 라인으로 확장하는 작업이 포함됩니다.

Foundation

관찰 가능한 플랫폼을 구축하기 전에 준비해야 할 것은 무엇인가요?

핵심 비즈니스 체인 목록

로그인, 주문, 결제, 쿼리, 푸시, 결제 등 주요 링크뿐만 아니라 각 링크에 포함된 API 게이트웨이, 애플리케이션 서비스, 데이터베이스, 캐싱, 메시지 큐, 제3자 의존성을 명확히 정의하세요.

통합 라벨링 표준

서비스, 환경, 버전, 팀, 지역, 호스트, 팟, 클러스터, 비즈니스 등과 같은 태그는 사전에 통합되어야 합니다; 그렇지 않으면 이후 지표, 로그, 링크, 알림을 연관짓기 어려울 수 있습니다.

기존 도구 및 데이터 소스

Prometheus, ELK, SkyWalking, OpenTelemetry, 클라우드 벤더 콘솔, 로그 수집기, 비즈니스 모니터링 시스템을 검토하여 어떤 것을 유지하고 어떤 것을 통합적 접근을 위해 접근할지 결정하세요.

경보 및 대응 절차

경고 등급, 업무 규칙, 책임자 명확화, 업그레이드 경로 및 검토 메커니즘을 명확히 하여 관찰 가능한 플랫폼이 문제 해결을 촉진하지 않고 새로운 쿼리 진입점이 되는 것을 방지합니다.

Roadmap

관측 가능한 플랫폼 건설의 다섯 단계

통합 컬렉션
DataKit, OpenTelemetry, Prometheus, 로그 수집, 클라우드 벤더 통합, 오픈 API 접근 지표, 로그, 링크, RUM, 이벤트, 비즈니스 지표를 통해 가능합니다.
통합 목표
서비스, 호스트, 팟, 컨테이너, 데이터베이스, 클라우드 자원, 버전, 팀, 비즈니스 객체 간의 관계를 구축하여 단일 알림으로 관련 증거를 더 깊이 파악할 수 있도록 합니다.
통합 씬
느린 인터페이스, 증가하는 오류율, Pod 재부팅, 저하된 페이지 경험, 비정상적인 로그, 비즈니스 지표 이상 등 고빈도 문제 해결 시나리오를 우선순위로 처리하세요.
통합 대응
이상 감지, 경보 알림, 이벤트 관리, 책임 배분, 기록 처리 및 검토 등을 동일한 프로세스에 통합하여 반복되는 경보와 정보 격차를 줄입니다.
지속적인 거버넌스
태깅, 샘플링, 로그 보존, 권한, 둔감화, 비용, SLO를 지속적으로 최적화하여 관측 가능한 플랫폼을 장기 안정성 프로젝트의 일부로 만듭니다.

Team View

각 팀은 관측 가능성을 구축할 때 어떤 점에 집중하나요?

팀 문제에 집중하세요 플랫폼이 제공해야 할 기능들

연구 및 개발 느린 요청, 오류 스택, 의존성 병목 현상, 그리고 릴리스 회귀 현상 APM 추적, 프로파일링, 로그 연관, 버전 비교 및 코드 수준 단서

SRE / 운영 및 유지보수 자원 수위, 경보 소음, 고층 영향, 복구 경로 인프라 모니터링, 쿠버네티스 이벤트, 알림 수렴, 이벤트 대응, SLO

플랫폼 팀 데이터 수집, 권한 거버넌스, 데이터 보존 및 접근에 대한 통합 표준 DataKit, OpenTelemetry, 통합 태그, 파이프라인, 권한, 익명화, 비용 거버넌스

비즈니스 팀 거래 영향, 경험 감소, 전환 이상 현상, 고객 불만 비즈니스 지표, RUM 실제 사용자 경험 모니터링, 대시보드, 비즈니스 영향 분석

관측 플랫폼 건설 계획을 계속 진행하세요

옵저버빌리티 플랫폼이란?

관측 가능성 플랫폼의 정의, 데이터 유형, 전통적 모니터링과의 차이점, 선정 기준을 이해하세요.

플랫폼과 전통 감시의 관측 가능성 차이점

팀이 왜 전통적인 모니터링에서 관측 플랫폼으로 업그레이드해야 하는지 파악하세요.

관측 플랫폼 선택 체크리스트

실제 사고 체인, 데이터 커버리지, 거버넌스 비용, 팀 협업 기준을 평가하는 플랫폼을 활용합니다.

풀링크 모니터링과 관측 플랫폼의 차이점

트레이스, 로그, 메트릭, RUM, 쿠버네티, 비즈니스 데이터가 어떻게 완전한 문제 해결 체인을 형성하는지 명확히 하세요.

관측 가능한 플랫폼과 통합 모니터링

메트릭, 로그, 링크, RUM, 쿠버네티스, 비즈니스 데이터를 통합하는 방법을 Guance 확인하세요.

650+ 기술 스택 및 데이터 통합

DataKit, OpenTelemetry, Prometheus, 클라우드 서비스, 그리고 주류 기술 스택의 접근 기능을 탐색해 보세요.

가격 및 버전

데이터 규모, 배포 방법, 유지 주기, 팀 요구사항 평가 버전 및 청구 방식을 결합합니다.

FAQ

자주 묻는 질문

기업들은 어디서부터 관측 가능성을 구축해야 할까요?

로그인, 주문, 결제, 핵심 API, Kubernetes 클러스터, 데이터베이스 등 핵심 비즈니스 체인과 고빈도 장애 시나리오부터 시작하여 수집, 태깅, 알림, 문제 해결을 위한 통합 프로세스를 이어가는 것이 권장됩니다.

관측 가능한 플랫폼을 구축하려면 기존 모니터링 도구를 교체해야 할까요?

반드시 그렇지는 않습니다. 대부분의 기업은 Prometheus, ELK, SkyWalking, OpenTelemetry와 같은 기존 수집 및 로컬 도구를 유지한 후, 관측 플랫폼을 통해 컨텍스트, 권한, 경고 폐쇄 루프, 장기적 거버넌스를 통합할 수 있습니다.

관찰 가능한 플랫폼을 구축할 때 가장 가능성 높은 실패는 어디일까요?

흔한 실패는 통합 태그, 객체 관계, 응답 프로세스 없이 데이터에 접근하는 경우로, 이는 팀이 도구에 걸쳐 증거를 수동으로 조각 배치해야 하므로 결함 현지화와 협업 비용을 진정으로 줄이는 것이 불가능합니다.

통합 모니터링 플랫폼의 구축과 관측 가능한 플랫폼의 구축 사이에는 어떤 관계가 있나요?

통합 모니터링 플랫폼 구축이 보통 첫 단계로, 지표, 로그, 링크, 알림을 중앙집중화하는 데 사용됩니다; 관찰 가능한 플랫폼의 구축은 객체 관계를 보완하고, 비즈니스 영향 탐색 및 분석, 팀 협업, 폐쇄 루프 검토를 계속해야 합니다.

관측성 구축의 효과는 어떻게 측정되나요?

효과성은 MTTR, 알림 노이즈, 반복 실패율, 코어 링크 가용성, 릴리스 롤백 횟수, 로그 저장 비용, 팀 간 협업 시간, SLO 성과를 통해 측정할 수 있습니다.