Datadog 서버 모니터링 살펴보기

BackEnd🌱/Etc

Datadog 서버 모니터링 살펴보기

dkswnkk 2024. 4. 1. 23:30

이미지를 클릭하면 큰 화면에서 더욱 자세하게 확인할 수 있습니다.

Logs

먼저 가장 기본적인 로그 확인입니다. 좌측 메뉴에서 Logs를 선택하면 Datadog과 연동된 모든 서비스의 로그를 한눈에 볼 수 있습니다. 여기서 원하는 특정 서비스를 선택하여 그 서비스의 로그만을 상세하게 조회할 수도 있습니다.

로그 항목을 클릭하면 해당 로그에 대한 더 자세한 정보를 확인할 수 있습니다. 이때 Trace와 Metrics 기능이 매우 유용한데, 로그가 생성되기까지의 경로와 로그 발생 시점의 CPU 사용량, 메모리 사용량, 디스크 I/O 등의 중요한 메트릭을 상세하게 파악할 수 있습니다(Trace와 Metrics 화면은 아래에서 나올 화면과 동일하기에 아래에서 살펴보겠습니다).

APM

APM(Application Performance Monitoring)의 기능을 통해 애플리케이션의 성능을 모니터링하고, 애플리케이션에서 수행되는 요청들을 상세하게 추적하고 분석할 수 있습니다. 제가 생각하기에 APM은 Datadog의 핵심 기능이자 꽃이라고 생각합니다.

0. Service Summary

APM의 메인 화면에서는 가장 먼저 Service Summary를 확인할 수 있는데, 애플리케이션의 성능을 빠르게 파악하고 분석하는 데 도움이 되는 핵심 지표를 제공합니다.

해당 그래프 위에 마우스를 올려놓으면 4가지의 모든 지표에서 동일한 시간대의 데이터를 확인할 수 있습니다.

좌측 상단부터 해당 칸이 의미하는 바는 다음과 같습니다.

Requests and Error: 특정 시간 동안 서비스로 들어온 요청의 총 수와 그중 에러로 응답된 요청의 비율을 보여줍니다.
Errors: 서비스에서 발생한 모든 에러의 수를 집계합니다.
Latency: 지연 시간(또는 대기 시간) 지표로써 서비스가 요청을 받고 응답을 완료하는 데 걸린 평균 시간을 측정합니다. 밀리초(ms) 단위로 표시됩니다.
% of TIme Spent: 서비스가 처리하는 요청 중에서 특정 유형의 작업(DB 쿼리, 외부 API 호출)에 소요된 시간의 비율을 나타냅니다.

그리고 APM의 Service Summary 아래에서는 다양한 카테고리를 통해 애플리케이션의 성능을 더욱 상세하게 분석할 수 있습니다. 그중에서 저는 Resources, JVM Metrics, Traces를 주로 확인하는 만큼 이 세 가지에 대해 살펴보겠습니다.

1. APM Resources

먼저 Resources 카테고리입니다. 여기서 애플리케이션의 각 API의 지표와 성능들을 API별로 더욱 상세하게 확인할 수 있습니다.

해당 API를 클릭하면 조금 더 세부적으로 Resources 사용 현황을 알 수 있는데, Dependencies란에서는 위 이미지처럼 해당 API가 어떤 외부 리소스와 의존 관계에 있으며, 몇 번의 요청이 오가는지 한눈에 확인할 수 있습니다.

2. APM JVM Metrics

다음은 JVM Metrics에 대한 설명입니다.

Heap Usage: JVM에서 객체를 저장하는 데 사용되는 힙 메모리의 총량과 사용량을 나타냅니다. 힙 메모리 사용량이 지속적으로 높은 상태를 유지한다면, 메모리 누수나 GC 이슈가 있을 가능성을 암시합니다.
Non-Heap Usage: JVM에서 클래스 메타데이터, 컴파일된 코드 등을 저장하는 데 사용되는 비힙 메모리 영역의 사용량을 나타냅니다. 비힙 메모리 사용량이 증가하는 것은 클래스 로딩이나 JIT 컴파일 과정에서 발생하는 문제를 의미할 수 있습니다.

간혹 JVM Metrics을 보더라도 해석하지 못하는 분들이 있는데, 위 이미지처럼 그래프가 일정한 시간 간격으로 높이가 낮아지는 패턴을 보인다면 이는 가비지 컬렉션이 정상적으로 작동하고 있음을 의미합니다. 만약 위 이미지와 달리 메모리 사용량이 일정 시간 간격으로 높이가 낮아지지 않고 계속해서 증가하는 패턴을 보일 때는 메모리 누수를 의심해봐야 합니다.

3. APM Traces

다음은 Traces입니다. Traces를 통해 애플리케이션 내부에서 수행되는 개별 요청의 경로와 성능을 상세하게 추적할 수 있습니다. 저는 주로 Traces를 통해 성능 저하를 일으키는 API를 식별하고 개선하며, 개선 후의 성능 변화도 여기서 확인합니다.

DURATION 순으로 정렬하면 가장 오래 걸리는 API를 손쉽게 식별할 수 있습니다.

https://medium.com/@ricardomalias/configuring-datadog-on-local-environment-688711933cb2

위와 같이 검색 필터링을 통해 원하는 정보만 선별할 수 있으며, 해당 로그를 클릭하면 해당 요청의 경로와 성능에 대한 더욱 상세한 정보를 확인할 수 있습니다.

위 이미지는 A 프로젝트에서 GET /v2/xxx API를 호출할 때 발생하는 모든 내부 경로를 보여주고 있습니다. 위 막대그래프를 통해 코드가 병렬로 실행되는지, 아니면 순차적으로 실행되는지 확인할 수 있습니다. 그리고 잘 보면 현재 루트 API인 GET /v2/xxx는 A 프로젝트 내에서 B 프로젝트를 호출하는 로직을 포함하고 있습니다. 이때 만약 B 프로젝트도 Datadog에 연결되어 있다면, A 프로젝트의 경로 추적을 통해 B 프로젝트의 경로까지 확인할 수 있습니다.

또한 Error 로그를 통해 Flame Graph에 접근했을 경우에는 에러가 발생한 그래프가 빨간색으로 표기되어 내부의 어떤 로직에서 에러가 발생했는지 손쉽게 파악할 수 있습니다.

다음으로 Span List에서는 호출되는 내부 로직(경로) 들을 보다 확실하게 전부 확인할 수 있는데, 각 경로에서 소요된 시간, 전송된 쿼리의 총 횟수, 그리고 어떤 쿼리가 전송되었는지도 확인가능합니다.

이전의 Flame Graph와 Span List를 함께 확인하면 로직의 병목지점을 보다 쉽게 파악하여 개선할 수 있습니다.

그리고 Map에서는 해당 API를 호출했을 때 일어나는 과정들을 마인드맵 형식으로 제공해 주어 전체적인 흐름을 시각적으로 빠르게 파악할 수 있습니다.

여기까지 APM을 애플리케이션을 기준으로 출발점으로 설정하고 추적했는데, 반대로 DB를 출발점으로 삼아 역순으로 추적할 수도 있습니다. 아래는 역으로 DB로부터 호출하는 로직을 선별하는 과정입니다.

Infrastructure

만약 컨테이너 환경에서 동작하고 있는 애플리케이션의 CPU 사용량을 확인하고 싶다면 Infrastructure의 Container에서 확인 가능합니다.

Metrics

DB의 컴퓨팅 CPU 사용률을 확인하고 싶으면 Metrics에서 확인 가능합니다.

정리

제가 주로 사용하는 기능들을 중심으로 설명했기 때문에, 데이터독에는 제가 언급하지 않은 더 많은 유용한 기능들이 있을 수 있습니다. 또한 제가 직접 데이터독을 연동하는 과정을 거치지 않아 다른 회사의 사용자들도 저와 동일한 구성으로 정보를 확인할 수 있을지는 모르겠으나, 이 글이 어느 정도 데이터독을 활용하는 데 있어 가이드가 되었기를 바라며 피드백이 있다면 언제든지 댓글 남겨주시면 감사하겠습니다.

저작자표시