[NHN FORWARD 22] OpenTelemetry를 활용한 모니터링

사내 전용 프로토콜에 묶인 레거시 모니터링 플랫폼이 멀티클라우드 환경과 재해복구 요구에 대응하기 어려워, 조회·수집 로직을 전부 뜯어고치느니 신규 개발을 택하게 된 배경을 설명한다.

모니터링과 옵저버빌리티(관측성)의 차이를 짚고, 시스템 내부 상태를 이해하는 관측성의 핵심 신호로 메트릭·트레이스·로그 세 가지와 각각이 남기는 데이터의 성격을 정리한다.

여러 컴포넌트를 거치는 요청의 경로와 구간별 소요 시간을 로그만으로 찾기 어려운 문제를 제시하고, 루트 스팬과 자식 스팬으로 병목 구간을 시각화하는 트레이스의 가치를 설명한다.

API·SDK로 계측하고 Collector로 수집해 각 옵저버빌리티 백엔드로 보내는 OpenTelemetry의 전체 파이프라인과, 벤더 중립적 표준으로서의 이점을 소개한다.

여러 리시버로 데이터를 받는 Collector를 에이전트 모드와 게이트웨이 모드로 나눠 설명하고, 서버가 수천 대로 늘어날 때 게이트웨이 모드로 설정을 중앙화하는 장점을 짚는다.

HTTP 클라이언트·서버 요청을 자동 계측할 때 URI 레이블의 카디널리티가 폭증하는 문제와 파라미터를 넘겨 템플릿 규격으로 묶는 대응, 그리고 95·99 퍼센타일 응답시간과 5xx·4xx 모니터링을 다룬다.

gRPC로 메트릭을 보낼 때 수집이 잘 됐는지 확인하는 법, 트레이스만이 아니라 메트릭 인터페이스도 여는지 등 청중 질문에 답하며 프로토콜 버퍼 익스포트 확인 방법 등을 설명한다.