9.2. 모니터링 연동

어떨 때 보는가

• "언제부터 느려졌는지" 를 알아야 할 때
• 여러 파드의 로그를 한꺼번에 검색할 때
• 지난 장애를 되짚을 때
• 애플리케이션 내부에서 어느 코드가 느린지 봐야 할 때

Console 이 보여 주는 것의 한계

Console 은 Kubernetes API 를 화면으로 감싼 것입니다. API 는 지금 상태 를 알려 주지, 과거 기록을 보관하지 않습니다.

자료	Console 에서
지금 CPU·메모리 사용량	볼 수 있습니다
한 시간 전 사용량	볼 수 없습니다
지금 떠 있는 파드의 로그	볼 수 있습니다
지워진 파드의 로그	볼 수 없습니다
최근 이벤트	볼 수 있습니다 (보관 기간 내)
지난주 이벤트	볼 수 없습니다
요청 하나가 어느 서비스를 거쳤는지	볼 수 없습니다
어느 SQL 이 느린지	볼 수 없습니다

과거를 보거나 애플리케이션 내부를 보려면 별도로 수집해 보관하는 시스템이 필요합니다.

COP 의 모니터링 제품 두 가지

COP 는 성격이 다른 두 제품을 함께 제공합니다. 둘은 별개 제품이고 화면도 따로입니다.

제품	보는 범위	답하는 질문
OPENMARU Observability	클러스터와 그 위의 워크로드	"클러스터가 건강한가, 어느 서비스가 문제인가"
OPENMARU APM	애플리케이션 내부	"그 서비스 안에서 무엇이 느린가"

Observability 로 범위를 좁히고 APM 으로 원인을 찾는 순서로 쓰는 것이 보통입니다.

OPENMARU Observability

클러스터 관측 제품 입니다. 노드·파드·서비스 같은 Kubernetes 자원과 그 사이의 관계를 시간에 따라 보관하고 보여 줍니다.

Console 과 다른 점은 시간축이 있다 는 것입니다. Console 은 지금 값을, Observability 는 그 값이 어떻게 변해 왔는지를 보여 줍니다.

주요 화면은 이렇습니다.

화면	보이는 것
클러스터 대시보드	자원 사용량 추이, 파드 배치 현황, 이벤트
토폴로지 맵	서비스 사이의 호출 관계
애플리케이션	서비스별 응답 시간·오류율·처리량
분산 추적	요청 하나가 여러 서비스를 거쳐 간 경로
로그 뷰어	여러 파드의 로그를 한 번에 검색
인시던트	장애 이력과 원인 분석
SRE 보고서	기간별 안정성 지표

Observability 대시보드

Console 의 개요 화면(2.1 장)과 비슷해 보이지만 담는 것이 다릅니다.

요소	설명
자원 게이지	CPU·메모리·디스크·파드 사용률
클러스터 요약	노드·파드·워크로드·인시던트 개수
네임스페이스 리소스 배분	어느 네임스페이스가 자원을 얼마나 쓰는지 넓이로 표시
POD 맵	파드 하나를 사각형 하나로 그려 전체 상태를 한눈에
리소스 상위 소비자	가장 많이 쓰는 파드 순위
클러스터 이벤트	최근 이벤트
리소스 추세	시간에 따른 사용량 변화

네임스페이스 리소스 배분과 POD 맵이 Console 에 없는 것 입니다. 수백 개 파드의 상태를 한 화면에서 확인할 수 있고, 어느 팀이 자원을 많이 쓰는지 넓이로 바로 보입니다.

분산 추적

요청 하나가 여러 서비스를 거쳐 간 경로와 각 구간에서 얼마나 걸렸는지 를 보여 줍니다.

마이크로서비스 환경에서 "느리다" 는 신고가 들어왔을 때, 어느 서비스 구간이 원인인지 찾는 데 씁니다. Console 의 파드 로그로는 서비스를 넘나드는 흐름을 볼 수 없습니다.

이럴 때 씁니다	설명
어느 서비스가 병목인지 모를 때	구간별 소요 시간을 비교합니다
특정 요청만 느릴 때	그 요청의 추적을 찾아 경로를 봅니다
오류가 어디서 시작됐는지	오류가 난 구간을 짚습니다

OPENMARU APM

애플리케이션 성능 관리 제품 입니다. 애플리케이션 안에서 벌어지는 일을 봅니다.

Observability 가 "어느 서비스가 느린가" 까지 알려 준다면, APM 은 그 서비스 안에서 무엇이 느린가 를 알려 줍니다.

보는 것	예
트랜잭션	요청 하나하나의 처리 시간과 상태
SQL	어느 쿼리가 얼마나 걸렸는지
JVM	힙 사용량, GC 발생, 스레드 상태
외부 호출	다른 시스템을 부른 시간
오류	예외가 발생한 지점

APM 대시보드

요소	설명
실시간 활성 사용자	지금 처리 중인 요청 수
트랜잭션 히트맵(T-Map)	응답 시간과 처리량을 점으로 흩어 그린 그림
TPS	초당 처리 건수
평균 응답시간	응답 시간 추이
JVM 힙 사용량	메모리 상태
오류율	실패한 요청의 비율

T-Map 이 APM 의 특징적인 화면입니다. 점 하나가 요청 하나이고, 세로 위치가 응답 시간입니다. 느린 요청이 위쪽에 모이므로 패턴을 눈으로 알아볼 수 있습니다.

트랜잭션 상세

느린 요청 하나를 골라 열면 그 요청 안에서 무슨 일이 있었는지 를 봅니다. APM 이 다른 도구와 가장 크게 다른 화면입니다.

구역	보이는 것
트랜잭션 개요	어느 요청인지, 응답 시간, 호출한 곳, 시작·종료 시각
문제 감지	APM 이 스스로 짚은 원인과 그 근거
시간 분석	응답 시간을 CPU·SQL·외부 호출·데이터 조회로 쪼갠 비율

화면 위쪽 탭에서 더 자세히 볼 수 있습니다.

탭	내용
성능 분석	원인 후보와 시간 배분
호출 흐름	메서드 호출 순서와 각 단계의 소요 시간
헤더 · 쿠키 · 파라미터	요청에 담겨 온 값
AI 성능 진단	원인 추정과 조치 제안

시간 분석이 원인을 좁혀 줍니다. 예를 들어 3초 걸린 요청에서 SQL 이 99.9% 를 차지했다면 애플리케이션 코드가 아니라 데이터베이스 쪽을 봐야 합니다. CPU 시간이 대부분이면 반대입니다.

이 수준의 정보는 Console 이나 Observability 에서 얻을 수 없습니다. 애플리케이션 안에 에이전트가 들어가 있어야 알 수 있는 것입니다.

둘을 어떻게 나눠 쓰나

장애가 났을 때의 순서입니다.

순서	어디에서	알아내는 것
1	Console	파드가 떠 있나, 방금 재시작했나
2	Observability	언제부터인가, 어느 서비스가 느린가
3	APM	그 서비스 안에서 무엇이 느린가 (SQL·GC·외부 호출)

범위를 좁혀 가며 내려갑니다. 처음부터 APM 을 보면 어느 애플리케이션을 볼지 정하지 못합니다.

Console 에서 이동하기

Console 왼쪽 메뉴의 도구 에서 이동합니다(9.3 장). 카드를 누르면 새 탭에서 열립니다.

같은 통합 인증을 쓰므로 다시 로그인하지 않아도 됩니다. 세 화면을 탭으로 열어 두고 오가며 쓰면 됩니다.

두 제품 모두 COP 를 설치할 때 함께 구성됩니다. 별도 설치 작업이 필요하지 않습니다.

무엇을 어디에서 볼지

알고 싶은 것	볼 곳
지금 파드가 떠 있나	Console (3.1 장)
지금 왜 종료됐나	Console 의 파드 로그와 이벤트
배포를 되돌려야 하나	Console (3.2 장)
언제부터 느려졌나	Observability 리소스 추세
어제 종료된 파드의 로그	Observability 로그 뷰어
어느 서비스가 병목인가	Observability 분산 추적
자원을 얼마나 늘려야 하나	Observability 리소스 추세
어느 SQL 이 느린가	APM
메모리가 새는가	APM JVM 화면
특정 사용자 요청만 느린 이유	APM 트랜잭션

장애가 진행 중이면 Console 부터, 지나간 장애면 Observability 부터 보는 것이 빠릅니다.

이벤트 보관 기간

Kubernetes 이벤트는 기본으로 한 시간쯤 지나면 사라집니다. 클러스터 저장소를 이벤트가 가득 채우지 않게 하려는 것입니다.

장애가 났을 때 이벤트를 나중에 보려면 그때 바로 확인하거나, 클러스터 진단으로 수집해 두십시오(2.3 장). Observability 는 이벤트를 따로 수집해 보관하므로 기간이 지난 뒤에도 조회할 수 있습니다.

자세한 사용법은 각 제품의 사용자 매뉴얼을 보십시오.