20P by ironlung 8달전 | favorite | 댓글 8개
  • Observability 개념:

    • 시스템 외부 출력의 결괏값(지식)에서 시스템 내부 상태를 얼마나 잘 추론하는지 나타내는 척도
    • 출력값 측정에서 시스템 상태를 추정하도록 설계된 동적 시스템
    • 클라우드 환경이 대중화되고, 도커화된 앱과 마이크로서비스 아키텍처가 보편화되면서 Observability 필요
  • Observability와 모니터링 차이점:

    • 모니터링: 사용자가 수행하는 무엇. 무엇이 잘못됐는지 보여줌
    • Observability: 모니터링을 포함하는 상위 개념. 내부 동작 배경 정보를 풍부하게 제공하고, 심층적인 시스템 문제를 해결. 무엇이 ‘왜’ 잘못됐는지까지 보여줌
  • 조직에서 Observability가 필요한 상황:

    • 프로덕션에 이슈가 생기면 ‘문제 원인을 파악하는 데이터는 무엇이고, 이는 어디에 있으며, 데이터를 어떻게 봐야 하는가?’라는 의문이 들 때
    • 1분 전까지 괜찮던 서비스에 문제가 생겨 ‘근본 원인을 어디서 찾아야 하는가?’란 문제를 맞닥뜨릴 때
    • 조직에서 ‘개발팀이 고객이나 지원/운영팀보다 서비스 이상 증상을 먼저 알려면 어떻게 해야 할까?’ 를 고민할 때
    • 마이크로서비스의 서비스 오류, 성능 오류를 효과적으로 추적할 방법이나 ‘로그 또는 애플리케이션 성능 모니터링(APM) 형태로 이를 확인할 수 있을지’ 궁금할 때
  • Observability 도구 발전 과정:

    • 2010년대 이후로 IT 업계에 다양한 Observability 도구가 나옴
    • 2010년 구글이 대규모 분산 시스템 추적 인프라 ‘Dapper’를 선보임
    • 이후 우버와 트위터에서 분산 추적 시스템 ‘Jaeger’(우버)와 ‘Zipkin’(트위터)을 각각 만듦
    • 분산 시스템 동작을 계속 모델링하고, 설명하는 표준 API 세트인 ‘Open Tracing’이 나옴
    • ‘Open Census’ 공개: 애플리케이션 지표와 분산 추적을 수집한 다음, 백엔드에 데이터를 실시간 전송하는, 다양한 언어용 라이브러리 세트
    • 이어서 ‘프로메테우스’가 나옴
    • 2019년에는 Open Tracing과 Open Census를 통합한 ‘Open Telemetry(OTel)’라는 도구, API, SDK 모음 공개
  • Open Telemetry:

    • 벤더 중립 오픈 소스 Observability 프레임워크
    • 소프트웨어 성능과 동작을 분석하도록 돕는 원격 측정 데이터로 로그, 지표, 추적이 있는데 Open Telemetry는 이를 계측, 생성, 수집하고 내보내는 데 쓰임
      • 로그: 타임스탬프 메타데이터. 이슈의 근본 원인을 판단하는 데 쓰임
      • 지표: 서비스에서 측정한 키/밸류 태그를 갖는 통계 또는 집계 데이터. 런타임에 포착한 서비스의 측정값
      • 추적: 사용자와 애플리케이션에 발생한 이벤트 기록. 개별 리퀘스트가 전파되는 경로 기록
    • 사용방식: Observability 도구에서 알림 보냄->알림 내용 확인하고, 대시보드로 가서 문제 지점 확인->이 문제 지점에서 특정 부분을 상세하게 쿼리->로그를 찾아 확인->이 로그와 관련된 추적 데이터를 찾아 패턴화->여기서 문제 확인하고, 고치며 Observability 구현
    • 요즘 만든 대부분의 Observability 도구는 Open Telemetry를 기본 지원
  • Open Telemetry가 나온 이유:

    • 과거에는 각 Observability 백엔드가 도구로 데이터를 전송하는 자체 계측 라이브러리와 에이전트가 있었고, 코드를 계측하는 방식이 여러 가지였음
    • Observability 백엔드로 데이터를 보내는 표준화된 데이터 형식이 없음
    • 이후, 하나의 표준을 만들기 위해 Open Tracing과 Open Census가 통합돼 Open Telemetry가 나옴
  • SigNoz: 오픈 소스 APM 도구

    • 애플리케이션을 모니터하고, 문제를 해결하도록 도움
    • 분산 추적 기술을 사용해 사용자 소프트웨어 스택 파악
      • latency, requests per second, error rates 같은 애플리케이션 지표를 모니터링
      • CPU 이용이나 메모리 사용 같은 인프라 지표도 관찰
      • 서비스 전반에 사용자 리퀘스트 추적
      • 지표에 알림 설정
      • 문제를 일으키는 정확한 추적에 가서 문제 근본 원인을 찾을 수 있음
      • 개별 리퀘스트 추적의 자세한 flame 그래프도 볼 수 있음

좋은 글 감사합니다!

댓글 감사드려요! :)

좋은 글 고맙습니다~

댓글 감사합니다! :)

모니터링이 잘 동작하는 건 어떻게 모니터링하지?

왓치맨이라는 만화에서 나오는 고민 비슷한 걸 했었는데 옵저버빌리티라는 말이 있었군여 감사합니다

감사합니다! 요즘 AI로 Observability를 간소화하는 도구를 개발하는 곳들도 눈에 띄더라고요. 더 알고 싶은 분야에요! :)

좋은 글 감사합니다 :)

고맙습니다! :D