지난달 27일 GitLab 코리아 15번째 밋업이 온라인으로 진행됐습니다. 이날 밋업 주제는 **‘GitLab이 옵저버빌리티(Observability)를 만드는 방식’**이었는데요. Observability는 ‘외부 데이터에서 시스템 내부 상태를 얼마나 잘 유추할 수 있는지’ 나타내는 척도이죠.
밋업은 세션 1, 2로 나눠 진행됐습니다. 세션 1에서는 유인철 GitLab 코리아 이사가 ‘Observability를 향한 GitLab의 새로운 여정’을 주제로 발표했고요. Observability 개념과 GitLab의 Observability 전략, 원칙, 올해 출시할 기능을 공유했습니다.
세션 2에서는 신철호(Dexter) 인포그랩 이사가 ‘오픈 소스로 시작하는 Observability’를 주제로 발표했고요. Observability를 바라보는 엔지니어 관점과 Observability 필요성, 발전 과정을 소개했습니다. 또 Observabilit 도구인 Open Telemetry, SigNoz를 알아보고, SigNoz 데모도 선보였죠. 이 글에서는 지난 밋업의 주요 발표내용을 살펴보겠습니다.
Observability 개념과 특징
세션 1에서는 Observability 개념과 GitLab의 Observability 전략, 원칙, 올해 출시할 기능을 다뤘는데요. 유인철 GitLab 코리아 이사는 먼저 Observability 용어 정의와 필요성 등을 짚었습니다. 앞서 언급했듯 Observability는 ‘시스템 외부 출력의 결괏값(지식)에서 시스템 내부 상태를 얼마나 잘 추론하는지’ 나타내는 척도인데요. 다시 말하면, ‘출력값 측정에서 시스템 상태를 추정하도록 설계된 동적 시스템’을 Observability라고 하죠. 유 이사는 Observability가 필요한 이유를 “클라우드 환경이 대중화되고, 도커화된 앱과 마이크로서비스 아키텍처가 보편화됐기 때문”이라고 설명했고요.
아울러 유 이사는 Observability와 모니터링을 비교하며 Observability 특징을 소개했습니다. 모니터링이 ‘사용자가 수행하는 무엇’이라면 Observability는 ‘시스템 속성’인데요. Observability는 ‘모니터링을 포함하는 상위 개념’이라고도 하죠. 이는 내부 동작 배경 정보도 풍부하게 제공하고, 심층적인 시스템 문제를 해결할 수 있습니다. 참고로 미국 소프트웨어 기업 뉴렐릭은 Observability를 **‘지표, 이벤트, 로그, 추적을 수집, 시각화, 분석하는 행위’**라고 설명하기도 해요. 이로써 시스템 운영을 포괄적으로 이해하도록 돕는다고 하죠. 모니터링은 ‘무엇이 잘못됐는지’ 보여주지만 Observability는 ‘무엇이 ‘왜’ 잘못됐는지’까지 보여주는데요. Observability가 내부 동작 배경 정보를 풍부하게 제공하고, 문제를 심층적으로 파악하는 이유도 이런 특징 때문으로 풀이됩니다.
GitLab의 Observability 구현 전략
이어서 GitLab의 Observability 전략을 알아봤는데요. 유 이사는 그 일환으로 지난해 GitLab이 Opstrace라는 회사를 인수한 일을 언급했습니다. Opstrace는 미국 오픈 소스 Observability 솔루션 기업인데요. GitLab은 Opstrace와 시너지 효과를 내 Observability 강화를 도모하고 있죠. 현재 Opstrace의 여러 기술이 GitLab으로 옮겨가고 있고요. UI를 통일하는 작업도 1차로 진행하고 있습니다. 이미 Error Tracking, Trace, Logging 등 여러 기능이 GitLab에도 들어가고 있죠.
유 이사는 GitLab의 Observability 구현 전략을 세 가지 공유했습니다. 첫째, 모든 데이터를 한곳에 저장하고요. 둘째, 단일 인터페이스로 데이터에 접근하도록 구성합니다. 셋째, GitLab의 다양한 기능과 긴밀히 연동하죠. GitLab은 다음 원칙에 따라 Observability를 구현하는데요. 첫째, 누구나 기능을 쓸 수 있도록 활성화합니다. 둘째, 데이터를 한곳에 저장하고요. 셋째, UI를 통합합니다. 넷째, 커뮤니티에서 다양한 피드백과 기여자들의 공헌을 GitLab 제품에 녹이려 하죠. 다섯째, SaaS(Software-as-a-service) 고객에게 기능을 먼저 제공하고요.
GitLab에 도입될 Observability 기능
GitLab에 현재 도입됐거나, 앞으로 도입될 예정인 Observability 기능도 살펴봤습니다. 유 이사는 ‘Logging’과 ‘Tracing’, ‘Error Tracking’을 중요한 Observability 기능으로 언급했는데요. Error Tracking과 Logging 기능은 현재 초기 수준으로 들어갔습니다. Tracing 기능은 올해 하반기에 구현될 예정이죠. 이들 기능은 DevOps 라이프사이클에서 ‘모니터링’ 단계에 해당하고요. GitLab에서는 기능을 계속 보완한다는 계획입니다.
앞으로 GitLab은 Observability 지원을 더 강화할 예정인데요. 올해 4분기(2023년 11월2024년 1월)에는 Observability UI를 GitLab에 통합합니다. 고객이 로그 등 백데이터를 AWS에 저장하도록 지원할 계획이죠. 내년 1분기(2024년 2월2024년 4월)에는 엔드투엔드 워크플로를 구축하는데요. 이는 소프트웨어 개발부터 운영까지 지원한다는 내용입니다. 또 파이프라인을 수행하면서 여러 빌드 잡(Job), 다양한 배포, 퍼포먼스 테스팅 등이 이뤄지는데요. GitLab은 이와 관련된 인사이트를 볼 수 있도록 서비스할 계획이죠. 이밖에 내년 2분기(2024년 5월~7월)에는 쿠버네티스와 연동하는 작업도 진행하고요.
조직에서 Observability가 필요한 상황
출처=인포그랩 유튜브 채널세션 2에서는 Observability를 바라보는 엔지니어 관점과 Observability 필요성, 발전 과정을 살펴봤습니다. 또 Observability 도구인 Open Telemetry, SigNoz를 알아보고, SigNoz 데모도 선보였죠.
연사인 신철호 인포그랩 이사는 ‘조직에서 Observability가 필요한 상황’을 다음과 같이 설명했는데요. 첫째, 프로덕션에 이슈가 생기면 **‘문제 원인을 파악하는 데이터는 무엇이고, 이는 어디에 있으며, 데이터를 어떻게 봐야 하는가?’**라는 의문이 들 때죠. 둘째, 1분 전까지 괜찮던 서비스에 문제가 생겨 **‘근본 원인을 어디서 찾아야 하는가?’**란 문제를 맞닥뜨릴 때고요. 셋째, 조직에서 ‘개발팀이 고객이나 지원/운영팀보다 서비스 이상 증상을 먼저 알려면 어떻게 해야 할까?’ 를 고민할 때입니다. 넷째, 마이크로서비스의 서비스 오류, 성능 오류를 효과적으로 추적할 방법이나 ‘로그 또는 애플리케이션 성능 모니터링(Application Performance Monitoring·APM)* 형태로 이를 확인할 수 있을지’ 궁금할 때고요.
이처럼 이벤트가 여러 시스템, 로그 안에서 복잡하게 발생하는데요. 이 이벤트를 더 쉽게 관측하고, 예측하며, 계측하도록 지원하는 방식이 필요합 니다. 최근 IT 업계에서 Observability 도구가 발전한 것도 이 때문이죠. 신 이사는 Observability 도구 의미를 이렇게 설명했습니다. “분산화된 마이크로서비스 구조에서는 ‘특정 사용자 요청이 어떤 트랜잭션, 경로를 따라 비즈니스를 처리하는지’ 따라가기가 어렵습니다. 이에 이벤트를 재현하고, 특정 이벤트에 깊이 들어가서 로그를 탐색하거나, ‘탐색 과정 전체에 만들어지는 경로’를 확인하는 기능, ‘애플리케이션 안에서 비즈니스 로직을 따라다니며 파악하는 기능’이 필요하죠. Observability 도구는 이런 일을 잘하도록 돕는 도구고요.”
*애플리케이션 성능 모니터링(Application Performance Monitoring·APM): 실시간 데이터를 사용해 애플리케이션 성능과 최종 사용자의 디지털 경험을 추적하는 관행
Observability 발전 과정
출처=인포그랩 유튜브 채널신 이사는 Observability 발전 과정도 소개했습니다. 2010년대 이후로 IT 업계에 다양한 Observability 도구가 나왔는데요. 2010년 구글이 대규모 분산 시스템 추적 인프라 ‘Dapper’를 선보였죠. 이후 우버와 트위터에서 분산 추적 시스템 ‘Jaeger’(우버)와 ‘Zipkin ’(트위터)을 각각 만들었고요. 그다음, 분산 시스템 동작을 계속 모델링하고, 설명하는 표준 API 세트인 ‘Open Tracing’이 나왔습니다. ‘Open Census’도 공개됐는데요. 이는 애플리케이션 지표와 분산 추적을 수집한 다음, 백엔드에 데이터를 실시간 전송하는, 다양한 언어용 라이브러리 세트입니다. 또 요즘 많이 사용하는 도구인 ‘프로메테우스’가 나왔고요. 2019년에는 Open Tracing과 Open Census를 통합한 ‘Open Telemetry(OTel)’라는 도구, API, SDK 모음이 공개됐죠.
세션 2에서는 Open Telemetry를 자세히 살펴봤는데요. 이 도구는 **‘벤더 중립 오픈 소스 Observability 프레임워크’**입니다. 소프트웨어 성능과 동작을 분석하도록 돕는 원격 측정 데이터로 로그, 지표, 추적이 있는데요. Open Telemetry는 이를 계측, 생성, 수집하고 내보내는 데 쓰이죠. 이 도구를 Observability에 활용하면 ‘왜’에 집중해 로그 등 여러 데이터를 볼 수 있고요. ‘이게 왜 이렇게 만들어졌을까?’, ‘왜 이 상황이 됐을까?’에 집중할 수 있습니다. 요즘 만든 대부분의 Observability 도구는 Open Telemetry를 기본으로 지원하고요.
IT 업계에는 이미 다양한 Observability 도구가 있죠. 그런데도 Open Telemetry가 나온 이유는 뭘까? Open Telemetry는 이렇게 설명합니다.
“시스템을 관찰할 수 있도록 만들려면 이를 계측해야 합니다. 코드는 추적, 지표, 로그를 전송해야 하고요. 그다음, 계측한 데이터를 Observability 백엔드로 보내야 하죠. Observability 백엔드는 자체 호스팅 오픈 소스 도구(Jaeger, Zipkin)부터 상업용 SaaS까지 다양한데요. 과거에는 각 Observability 백엔드가 도구로 데이터를 전송하는 자체 계측 라이브러리와 에이전 트가 있었습니다. 이에 코드를 계측하는 방식이 여러 가지였죠. 이는 ‘Observability 백엔드로 데이터를 보내는 표준화된 데이터 형식이 없다’라는 의미이기도 한데요. … (중략) 표준화가 부족하면 데이터 이식성이 부족합니다. 또 사용자는 계측 라이브러리를 유지 관리하는 부담이 생기죠. 이에 표준화 필요성을 인지하며 클라우드 커뮤니티가 모였는데요. 두 개의 오픈 소스 프로젝트가 탄생했습니다. 클라우드 네이티브 컴퓨팅 파운데이션의 Open Tracing, 구글 오픈 소스 커뮤니티 프로젝트의 Open Census가 그 주인공이죠. 이후, 하나의 표준을 만들기 위해 Open Tracing과 Open Census가 통합돼 Open Telemetry가 나왔고요.”
로그, 지표, 추적…원격 측정 데이터 3대장
앞서 ‘Open Telemetry가 소프트웨어 성능과 동작을 분석하기 위해 로그, 지표, 추적을 계측, 생성, 수집하고 내보내는 데 쓰인다’고 했죠. 세션 2에서는 각 데이터 개념과 특징도 다뤘습니다. 로그는 타임스탬프 메타데이터인데요. Open Telemetry에 따르면, 로그는 이슈의 근본 원인을 판단하는 데 쓰입니다. 이는 일반적으로 변경 결과와 ‘누가 무엇을 바꿨는지’ 정보도 포함하죠. “Open Telemetry에서 분산 추적이나 지표 일부가 아닌 모든 데이터는 로그”라고 합니다. 신 이사는 “로그는 타임스탬프를 포함하는 이벤트의 메시지를 저장한다”며 “보통 시스템에 문제가 생겼을 때 처음 만나는 게 로그 관련 이벤트라서 로그를 추적한다”고 설명했습니다.
지표는 서비스에서 측정한 키/밸류 태그를 갖는 통계 또는 집계 데이터인데요. Open Telemetry에 따르면, 이는 런타임에 포착한 서비스의 측정값입니다. 이론적으로, ‘이 측정값 중 하나를 포착하는 순간’이 지표 이벤트(metric event)고요. 지표 이벤트는 측정값 자체, 포착한 시간, 관련 메타데이터로 구성됐죠. 애플리케이션과 리퀘스트 지표는 가용성과 성능을 나타내는 중요한 지표이고요. 맞춤 지표(커스텀 메트릭)는 ‘가용성 지표가 사용자 경험이나 비즈니스에 영향을 주는 방식’에 통찰을 줍니다. 수집한 데이터는 서비스 중단을 알리거나 수요가 높을 때, 배포를 자동으로 확장하는 일정을 결정하는 데 쓰일 수 있죠.
추적은 사용자와 애플리케이션에 발생한 이벤트 기록이고요. 이는 개별 리퀘스트가 전파되는 경로 기록이기도 합니다. Open Telemetry는 추적을 ‘리퀘스트가 애플리케이션에 이뤄질 때 일어나는 일의 큰 그림을 제공한다’고 설명하는데요. 추적은 리퀘스트가 애플리케이션에서 이뤄지는 전체 경로를 이해하는 데 필수이죠. 신 이사는 “추적은 ‘스팬(Span)’이라는 태그를 달아서 콘텍스트 전체 가정을 추적하도록 만든다”고 설명했는데요. Open Telemetry에 따르면, 스 팬은 작업 또는 운영 단위를 나타냅니다. 이는 추적의 구성요소고요. Open Telemetry에서는 스팬이 이름, Parent 스팬 ID, Start & End 타임스탬프, 스팬 콘텍스트, 속성, 스팬 이벤트, 스팬 링크, 스팬 상태 정보를 포함합니다*.*
세션 2에서는 Open Telemetry 아키텍처와 사용방식도 들여다봤는데요. Open Telemetry 레퍼런스 아키텍처는 이렇습니다. 먼저 애플리케이션에서 원격 측정 데이터를 온라인 트랜잭션 처리(OLTP)*로 컬렉터에 전달하고요. 컬렉터는 이를 처리하고, 내보내죠. 그다음, 데이터를 OLTP로 데이터베이스(DB)에 저장합니다. Open Telemetry 사용방식은 다음과 같은데요. **먼저 Observability 도구에서 알림을 보냅니다. 이어서 알림 내용을 확인하고, 대시보드로 가서 문제 지점을 확인하죠. 이 문제 지점에서 특정 부분을 상세하게 쿼리하고요. 로그를 찾아 확인합니다. 그다음, 이 로그와 관련된 추적 데이터를 찾아 패턴화하는데요. 여기서 문제를 확인하고, 고치며 Observability를 구현하죠.
*온라인 트랜잭션 처리(OLTP): 온라인 뱅킹, 쇼핑, 주문 입력, 텍스트 메시지 전송 등 동시에 발생하는 여러 트랜잭션을 실행하는 데이터 처리 유형
Observability 도구의 신성 ‘SigNoz’
출처=인포그랩 유튜브 채널이어서 Observability 도구 ‘SigNoz’ 이야기로 넘어갔습니다. SigNoz는 오픈 소스 APM 도구인데요. 이는 애플리케이션을 모니터하고, 문제를 해결하도록 돕습니다. 이 또한 분산 추적 기술을 사용해 사용자 소프트웨어 스택을 파악하죠. SigNoz는 비슷한 도구인 ‘Datadog 대안’으로 불리기도 합니다. 신철호 이사는 “벤더에 종속되지 않고 Observability를 만들려는 회사나 개인에게 대안 프로젝트”라며 “개인정보 보호, 보안 문제를 처리하고 싶거나, 개인 신용 정보를 클라우드나 클러스터에 올릴 수 없는 회사가 아니라면 이를 구현하고, 테스트할 수 있다”라고 설명했죠.
SigNoz는 Open Telemetry를 사용해 데이터를 수집하고요. 이는 수집한 데이터를 모두 종합합니다. 사용자는 대시보드로 애플리케이션과 관련된 모든 지표와 추적을 볼 수 있고요. 참고로 SigNoz는 Open Telemetry가 지원하는 모든 프레임워크와 언어를 지원하죠.
SigNoz에 따르면, 사용자는 다음 기능을 이용할 수 있는데요. 첫째, latency, requests per second, error rates 같은 애플리케이션 지표를 모니터링할 수 있습니다. 둘째, CPU 이용이나 메모리 사용 같은 인프라 지표도 관찰할 수 있죠. 셋째, 서비스 전반에 사용자 리퀘스트를 추적할 수 있습니다. 넷째, 지표에 알림을 설정할 수도 있고요. 다섯째, 문제를 일으키는 정확한 추적에 가서 문제 근본 원인을 찾을 수 있죠. 여섯째, 개별 리퀘스트 추적의 자세한 flame 그래프도 볼 수 있습니다.
SigNoz 아키텍처와 상세 데이터
세션 2에서는 SigNoz 아키텍처를 자세히 들여다봤는데요. 신 이사는 “아키텍처를 보면 Open Telemetry에서 본 구조와 같지만, 구성요소는 조금씩 다르다”라고 말했습니다. Open Telemetry에서 제공하는 에이전트 방식이나 라이브러리를 애플리케이션에 직접 연동하는 방식은 같고요.
컬렉터에는 추적, 지표, error event 관련 로그를 ‘SigNoz Otel Collector’ 형태로 저장하죠. 이어서 ‘Click House’라는 데이터베이스(DB)를 켜는데요. 신 이사는 이 DB를 “오픈 소스로 만든 고성능 칼럼 DB”라고 설명했습니다. 이는 온라인 분석 처리(OLAP)* DB 구조고요. “Click House는 칼럼 DB라서 특정 상황에 쿼리하는 속도가 관계형 데이터베이스 관리 시스템(RDBMS)과 비교할 수 없을 정도로 굉장히 빠르다”라고 하죠. 이는 필요할 때, 콜드 데이터를 S3처럼 Long term Storage에 저장하는 옵션을 제공합니다. 이밖에 SigNoz 백엔드에는 ‘Query Service’, ‘Alert Manager’가 있고요. 프론트엔드는 ‘React’로 만들었죠.
이어서 신 이사는 SigNoz에서 볼 수 있는 상세 데이터를 소개했습니다. SigNoz는 단일 뷰에서 지표, 추적, 로그 등을 관장하는데요. 분산 추적 관련 데이터는 이렇게 볼 수 있죠. 보기 화면에는 Span 개수가 나오고요. 하위로 각 Span이 만들어진 걸 확인할 수도 있습니다. 하나의 Span에 들어가면 관련 로그를 추적할 수 있고요. SigNoz는 전체 로그를 탐색하는 UI도 갖췄죠.
또 이는 지표를 분석하는 시간 데이터를 종합해 그래프로 표시하는데요. **선택한 기간의 애플리케이션 Latency(밀리초 단위)**도 보여줍니다. 이는 P99, P95, P50으로 나눠 Latency를 제시하는데요. 예를 들어, P99 latency가 781ms라면 리퀘스트의 99%가 781ms보다 빠른 응답을 받는다는 의미입니다. P95 latency와 P50 latency는 리퀘스트의 95%, 50%의 latency 값을 보여주고요. 이밖에 SigNoz에서는 인프라도 모니터링할 수 있죠. 이때 CPU 이용, CPU 유휴, 평균 CPU 로드를 확인할 수 있습니다.
*온라인 분석 처리(OLAP): 다양한 관점에서 비즈니스 데이터를 분석하는 데 사용하는 소프트웨어 기술. 웹 사이트, 애플리케이션 등 여러 데이터 소스에서 수집, 저장한 데이터를 범주로 결합하고 그룹화해 통찰을 얻을 수 있음.
Open Telemetry, SigNoz, Observability 장점
출처=인포그랩 유튜브 채널세션 2에서는 SigNoz 사용법도 시연했는데요. 신 이사가 샘플 애플리케이션을 쿠버네티스로 직접 배포했고요. SigNoz로 Latency를 분석하고 콜 트레이스, 대시보드, 경보(Alert)를 확인하는 방법도 보여줬습니다. 자세한 시연 장면은 위에 있는 유튜브 영상을 참조해 주세요.
신 이사는 Open Telemetry, SigNoz, Observability로 얻는 장점을 이렇게 짚었습니다. DevOps 측면에서 장점은 다음과 같은데요. 첫째, 운영 환경을 실시간 파악할 수 있고요. 둘째, 이로써 문제를 빨리 해결할 수 있죠. 셋째, 이는 알림을 보내기 때문에 시스템 문제를 파악하고, 해결하는 과정을 체계화할 수 있는데요. 이벤트 시작부터 끝까지 전 과정을 확인할 수 있습니다. 또 애플리케이션을 디버깅하는 워크플로를 간소화할 수 있죠. 이에 DevOps 엔지니어는 개발 내용을 모르더라도 짐작해서 각각 인터페이스 되는 문제를 파악할 수 있고요.
개발자 측면에서는 이런 장점을 얻을 수 있는데요. 첫째, 모니터링과 트러블슈팅 할 수 있는 UI, UX를 제공받아 개발 속도를 단축할 수 있습니다. 둘째, 외부/운영팀과 협업 시간도 단축할 수 있죠. 개발자가 이벤트 처리 과정을 볼 수 있으니 협업 시간을 줄일 수 있습니다. 셋째, 운영 환경을 더 잘 이해할 수 있고요. 이로써 애플리케이션을 배포한 다음에 생길 일을 확인해 운영 환경의 통찰을 얻을 수 있습니다.
저희 DevOps 엔지니어인 Lucas가 최근 회사 블로그에 ‘SigNoz 소개’ 글을 게재했는데요. 이 도구를 더 자세히 알고 싶은 분은 해당 글을 참조해 주세요.
맺음말
지금까지 GitLab 코리아 15번째 밋업 발표 내용을 토대로 Observability 개념과 GitLab의 Observability 전략, 올해 출시할 기능 등을 살펴봤습니다. 아울러 Observability 필요성, 발전 과정, Observability 도구인 Open Telemetry, SigNoz를 알아봤고요. 이 글의 요점은 다음과 같습니다.
1.Observability는 ‘시스템 외부 출력의 결괏값(지식)에서 시스템 내부 상태를 얼마나 잘 추론하는지’ 나타내는 척도입니다. 이는 내부 동작 배경 정보를 풍부하게 제공하고, 심층적인 시스템 문제를 해결할 수 있죠. 모니터링은 ‘무엇이 잘못됐는지’ 보여주지만 Observability는 ‘무엇이 ‘왜’ 잘못됐는지’까지 보여줍니다.
2.분산화된 마이크로서비스 구조에서는 ‘특정 사용자 요청이 어떤 트랜잭션, 경로를 따라 비즈니스를 처리하는지’ 따라가기가 어려운데요. 이에 이벤트를 재현하고, 특정 이벤트에 깊이 들어가서 로그를 탐색하거나, ‘탐색 과정 전체에 만들어지는 경로’를 확인하는 기능, ‘애플리케이션 안에서 비즈니스 로직을 따라다니며 파악하는 기능’이 필요하죠. Observability 도구는 이런 일을 잘하도록 돕습니다.
3.지난해 GitLab은 Opstrace라는 미국 오픈 소스 Observability 솔루션 기업을 인수했습니다. GitLab은 Opstrace와 시너지 효과를 내 Observability 강화를 도모하고 있는데요. 현재 Opstrace의 여러 기술이 GitLab으로 옮겨가고 있습니다. Error Tracking, Trace, Logging 등 여러 기능이 GitLab에도 들어가고 있고요. 앞으로 GitLab은 Observability 지원을 더 강화할 예정입니다.
4.요즘 많이 쓰이는 Observability 도구 중 하나로 Open Telemetry가 있는데요. 이 도구는 ‘벤더 중립 오픈 소스 Observability 프레임워크’입니다. 소프트웨어 성능과 동작을 분석하도록 돕는 원격 측정 데이터로 로그, 지표, 추적이 있는데요. Open Telemetry는 이를 계측, 생성, 수집하고 내보내는 데 쓰이죠. 이 도구를 Observability에 활용하면 ‘왜’에 집중해 로그 등 여러 데이터를 볼 수 있습니다. 요즘 만든 대부분의 Observability 도구는 Open Telemetry를 기본으로 지원하고요.
5.최근 떠오르는 또 하나의 Observability 도구로 SigNoz도 있습니다. SigNoz는 애플리케이션을 모니터하고, 문제를 해결하도록 돕죠. 이 또한 분산 추적 기술을 사용해 사용자 소프트웨어 스택을 파악합니다. 사용자는 SigNoz로 latency, requests per second, error rates 같은 애플리케이션 지표를 모니터링할 수 있고요. CPU 이용이나 메모리 사용 같은 인프라 지표도 관찰할 수 있죠. 또 서비스 전반에 사용자 리퀘스트를 추적할 수 있고요. 문제를 일으키는 정확한 추적에 가서 문제 근본 원인을 찾을 수도 있습니다.
6.Open Telemetry, SigNoz, Observability로 얻는 장점은 다음과 같은데요. DevOps 측면에서 장점은 이렇습니다. 첫째, 운영 환경을 실시간 파악할 수 있고요. 둘째, 이로써 문제를 빨리 해결할 수 있죠. 셋째, 이는 알림을 보내기 때문에 시스템 문제를 파악하고, 해결하는 과정을 체계화할 수 있는데요. 이벤트 시작부터 끝까지 전 과정을 확인할 수 있죠.
7.개발자 측면에서는 이런 장점을 얻을 수 있습니다. 첫째, 모니터링과 트러블슈팅 할 수 있는 UI, UX를 제공받아 개발 속도를 단축할 수 있고요. 둘째, 외부/운영팀과 협업 시간도 줄일 수 있죠. 셋째, 운영 환경을 더 잘 이해할 수 있고요. 이로써 애플리케이션을 배포한 다음에 생길 일을 확인해 운영 환경의 통찰을 얻을 수 있습니다.
<참고자료>
4.Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
10.APM이란 무엇인가요?
11.OLTP란 무엇인가?