Kubernetes 모니터링을 위한 Prometheus, Grafana 개념 정리

안녕하세요. J4J입니다.

 

이번 포스팅은 kubernetes 모니터링을 위한 prometheus, grafana 개념에 대해 적어보는 시간을 가져보려고 합니다.

 

 

 

Kubernetes 모니터링이 필요한 이유

 

kubernetes 환경에서 여러 개의 pod를 띄우며 서비스를 제공하는 경우는 요즘 개발 환경에서 흔히 발생할 수 있는 상황입니다.

 

개별적인 vm 서버들을 별도로 구성하는 것보다 kubernetes에 관리를 모두 위임하여 container 기반으로 관리하게 되면 리소스를 효율적으로 사용하며 유연한 확장과 자동 복구 등 다양한 이점들을 얻을 수 있기 때문입니다.

 

그래서 kubernetes 환경을 구축하여 서비스를 관리하는 클러스터 구성을 하고, 클러스터 내부에 서비스 동작을 위한 다양한 pod들이 분산되어 1개의 클러스터 안에서 수 십 개, 수 백개의 pod들이 관리되는 상황도 발생합니다.

 

 

 

이와 같은 방식으로 서비스를 운영하다보면 가장 필요하다고 느끼는 것은 kubernetes에 올라간 서비스 동작을 위한 pod들이 정말 잘 동작하고 있는가를 확인하고 싶은 것입니다.

 

pod들은 vm과는 구성 방식이 다르기 때문에 모니터링에 대해 더욱 필요하다고 느끼게 됩니다.

 

왜냐하면 다음과 같은 이유가 있기 때문입니다.

 

• pod는 자동으로 생성/삭제가 이루어지기 때문에 한번 배포를 한 뒤 동작 여부를 확인하는 vm과 다르게 수시로 환경이 달라짐
• vm과 달리 많은 수의 pod 들이 서로 소통하여 서비스가 운영되기 때문에 pod 들을 개별적으로 확인할 수 없음
• pod가 문제가 발생한 경우 kubernetes에 의해 자동으로 복구가 되기 때문에 문제 확인을 놓칠 수 있음
• 등등...

 

이 외에도 kubernetes가 현재 사용하고 있는 리소스는 어느 정도이며, 추가적인 container를 동작시키고 싶은 경우에 어느 정도까지 허용되는지도 알고 싶을 수 있습니다.

 

 

 

물론 vm을 사용하는 환경에서도 모니터링을 하는 것은 서비스 안정성을 위해 필수적인 요소가 됩니다.

 

하지만 kubernetes를 이용하는 경우 kubernetes 환경 안에는 내가 배포해야 되는 서비스를 제외하고도 다양한 설정과 서비스들이 동작하고 있기 때문에 어떤 상황들이 발생하고 있는지 확인할 수 있는 방법이 명확하지 않습니다.

 

실제 개인적인 사례로 kubernetes를 이용한 서비스 개발을 한지 얼마 되지 않았을 때 kubernetes의 리소스 사용량에 대해 명확히 확인되지 않은 상황에서 과도한 pod를 배포했던 경험이 있습니다.

 

그 결과로 kubernetes 내부에서 동작하고 있는 모든 worker node들이 죽으면서 클러스터 내부에 배포되어 있는 모든 container의 동작이 멈췄었습니다.

 

단순히 서비스를 배포하는 개발자 입장에서 클러스터에 배포가 올바르게 이루어졌기에 아무 문제없다고만 생각했지만, 클러스터 내부에서는 리소스 부족으로 인해 위험한 상황들을 마주할 수 있었던 것이었습니다.

 

이런 사례에서도 모니터링을 올바르게 수행하고, worker node 들의 현재 상태에 대해서 명확히 확인을 했다면 발생하지 않았을 문제였습니다.

 

 

 

결론적으로 kubernetes를 이용하여 서비스 운영을 하는 곳에서는 다음 이점들을 얻기 위하여 모니터링을 도입하는 것이 올바른 선택이 될 수 있습니다.

 

• 클러스터 내부에 존재하는 node, pod, service, storage 등이 현재 어떠한 상태인지를 실시간으로 확인
• 리소스 사용량을 추적하여 리소스 부족인 경우 리소스를 확장하고, 과도한 리소스가 분배되는 경우 리소스 제한 설정 가능
• 서비스가 다운되는 상황이 발생했을 때 어떤 문제 때문에 동작이 멈췄는지 확인하여 이슈 대응
• 리소스 사용량에 대한 계획을 세우고 사용되는 비용을 최적화하는 지표 확인 가능

 

 

반응형

 

 

Prometheus 개념

 

prometheus는 시계열 데이터를 기반으로 한 시스템 모니터링 및 알림 처리를 제공하는 툴킷입니다

 

여기서 시계열 데이터라고 하는 것은 시간의 경과에 따라 순서대로 변화들을 나열한 데이터들을 의미합니다.

 

말 그대로 시간의 변화에 따라 측정되는 값들을 수집하여 모니터링과 알림 처리를 위한 데이터 자료로 사용이 되는 구조입니다.

 

그래서 데이터를 수집할 때 시간에 맞는 타임스탬프 정보가 함께 저장되며 key-value 형태로 구성되어 있는 label 정보들을 함께 저장하여 단순히 데이터 수집하는 것이 아닌 어떤 정보에 대한 시계열 데이터인지를 표현할 수도 있습니다.

 

 

 

prometheus를 사용하다 보면 metric이라는 단어도 쉽게 접할 수 있습니다.

 

metric이라고 하는 것은 수치적으로 측정할 수 있는 데이터 값들을 의미합니다.

 

예를 들면, 애플리케이션의 부하를 판단하기 위해 사용자가 애플리케이션에 요청하는 요청 수에 대한 metric을 얘기해 볼 수 있고 또는 서버에서 사용되는 cpu 사용량에 대한 metric에 대해서도 얘기해볼 수 있습니다.

 

이처럼 어떠한 주제 및 관심사에 대해서 수치적으로 표현되어 있는 값들이 metric이 될 수 있습니다.

 

 

 

위의 내용들로만 정리해서 prometheus가 어떤 기능을 수행하는지에 대해 얘기해 보면 다음과 같이 정리할 수 있습니다.

 

시계열 데이터들을 타임스탬프 정보와 key-value 형태의 label 정보들로 저장하고, 이를 기반으로 다양한 metric 정보들을 수집/조회/분석한다.

 

 

 

이렇게 수집된 metric 정보들은 prometheus에서 제공하는 PromQL query를 이용하여 쉽게 조회할 수 있습니다.

 

예를 들어 애플리케이션 동작을 위해 사용되는 서버들의 cpu 사용량과 memory 사용량 등 prometheus가 관리하고 있는 metric 정보라면 쉽게 조회할 수 있도록 기능을 제공하고 있습니다.

 

또한 함께 저장되어 있는 label 정보들을 이용하여 원하는 데이터들을 filter 할 수도 있고, 다양한 집계 처리를 위한 함수들도 제공되기 때문에 편리하게 원하는 metric 정보에 대한 연산 처리를 할 수 있습니다.

 

그리고 prometheus에는 alert manager를 통해 알림 처리를 제공할 수 있는데, 알림을 제공할 때도 PromQL을 이용합니다.

 

 

 

 

PromQL을 사용하는 예시를 적어보면 다음과 같습니다.

 

만약 jvm memory 사용량에 대한 시계열 데이터가 수집되는 jvm_memory_usage_bytes라는 metric이 존재한다고 가정하겠습니다.

 

이럴 때 해당 metric에 담겨 있는 모든 데이터들의 평균값에 대해 조회하고 싶다면 다음과 같은 PromQL을 작성할 수 있습니다.

 

avg(jvm_memory_used_bytes)

 

 

 

그리고 해당 query를 이용하여 알림을 관리하는데 바로 사용할 수 있습니다.

 

jvm memory 사용량의 평균값을 측정했을 때 10MB 이상이 도달하는 경우 알림을 등록하고 싶다면 다음과 같은 PromQL을 활용하여 알림도 등록할 수 있습니다.

 

avg(jvm_memory_used_bytes) > 1024 * 1024 * 10 // 10 MB

 

 

 

추가적으로 PromQL만 사용하는 것으로는 명확히 metric에 담겨있는 데이터의 수치가 어느 정도인지 한눈에 확인하기 어렵습니다.

 

그래서 prometheus에서는 graph를 통해 조회된 데이터에 대한 정보를 시각적으로 제공하고 있습니다.

 

위의 jvm memory 사용량에 대한 평균값에 대해 조회를 하고 graph로 표현하면 다음과 같이 노출되어 확인할 수 있습니다.

 

prometheus graph

 

 

 

prometheus 공식 문서에서는 prometheus를 사용이 적합한 상황과 적합하지 않은 상황을 다음과 같이 분류하고 있습니다.

 

[ 사용이 적합한 상황 ]

 

• 순수하게 수치적인 시계열 데이터를 저장하여 관리하는 상황
• 고도화된 동적인 서비스 지향 아키텍처 모니터링
• msa 환경에서 다방면의 데이터 수집 및 데이터 조회

 

[ 사용이 적합하지 않은 상황 ]

 

• 수집된 데이터에 대해 100% 정확도가 필요한 경우

 

 

 

이 외에도 prometheus에 대한 부가적인 정보들을 더 알고 싶으신 분들은 Promethues 공식 문서를 참고하시면 많은 도움을 받을 수 있습니다.

Overview | Prometheus

 

 

 

 

Grafana 개념

 

grafana는 데이터 시각화 및 모니터링을 제공하는 오픈소스로 저장되어 있는 metric, 로그, trace 정보들을 이용하여 대시보드와 차트 기반으로 표현할 수 있도록 도와줍니다.

 

그래서 일반적으로 많이 사용되는 방식 중 하나가 prometheus를 이용하여 metric 정보를 수집하고, 수집된 정보를 이용하여 grafana를 통해 시각화를 위한 대시보드를 구성하는 것입니다.

 

하지만 prometheus에 대한 개념 숙지가 되었다면 prometheus에서도 graph와 같은 시각화 처리를 할 수 있는데 굳이 grafana를 사용해야 하는 이유에 대해서 궁금할 수 있습니다.

 

우선 prometheus 만을 이용하여 시각화를 하는 것에 문제가 없다면 굳이 grafana를 도입할 이유가 없기는 합니다.

 

하지만 grafana를 사용하게 되면 prometheus만을 사용하는 것과 비교했을 때 다음과 같은 다양한 이점들을 얻을 수 있습니다.

 

 

 

[ 다양한 datasource를 동시 연결하여 관리 ]

 

prometheus의 경우에는 prometheus로 수집된 metric 정보만을 이용하여 시각화 정보를 제공 가능합니다.

 

하지만 grafana는 prometheus를 포함하여 우리가 쉽게 접할 수 있는 elastic search (ES), RDB, NoSQL과 같은 다양한 datasource들이 함께 사용될 수 있습니다.

 

저 같은 경우도 grafana를 광범위하게 사용하고 있지 않음에도 불구하고 influxDB, ES, prometheus 등 벌써부터 다양한 datasource 들을 연결하여 모니터링 정보를 제공하고 있습니다.

 

모니터링을 위한 시각화 처리를 수행하는데 여러 장소에 분산되어 있는 것보다 grafana만을 이용하여 모니터링을 수행하게 된다면 통합된 기능 제공이 가능하기에 prometheus를 사용하는 것보다 더 효율적인 모니터링 정보들을 제공할 수 있게 됩니다.

 

 

 

[ 다양한 대시보드 제공 ]

 

prometheus의 경우 graph를 이용하여 간단한 라인 차트 정도의 대시보드를 제공하고 있습니다.

 

하지만 grafana는 라인 차트를 포함하여 바 차트, 파이 차트, 테이블, 히스토그램, 게이지 등 대시보드 구성을 위한 정말 다양한 시각화 정보를 제공합니다.

 

필요한 시각화 방식에 따라서 정보를 제공할 수 있고, 수집되는 데이터에 적합한 대시보드를 구성하여 더 보기 쉬운 형태로 관리할 수도 있습니다.

 

또한 하나의 대시보드 안에 다양한 시각화 자료를 한 번에 노출시켜 연관 정보들을 한 번에 볼 수도 있습니다.

 

grafana 대시보드 sample

 

 

 

그리고 강력한 무기 중 하나는 외부에 오픈되어 있는 대시보드들이 존재합니다.

 

다른 말로는 다른 개발자 분들이 모니터링을 위해 만들어 둔 대시보드 구성 요소들을 간편하게 우리가 모니터링하고 있는 grafana 대시보드로 복사할 수 있습니다.

 

Grafana 공식 문서 대시보드와 같은 곳을 확인하시면 활용할 수 있는 대시보드들을 쉽게 볼 수 있습니다.

Grafana dashboards | Grafana Labs

 

 

 

[ 접근 제어 관리 ]

 

prometheus의 경우에는 접근할 수 있는 사용자 및 팀에 대한 정보들을 관리하는 기능이 제공되지 않습니다.

 

하지만 grafana는 접근 제어를 관리하는 기능이 제공되어 사용자 및 팀 단위로 접근 제어 관리를 통해 더 효과적인 협업 환경을 제공합니다.

 

모든 사용자가 동일한 방식으로 관리하는 것이 아닌 접근 제어 관리를 통해 역할 별 서로 다른 기능 처리하는 상황이 필요하다면 grafana를 사용하는 것은 좋은 선택지가 될 수 있습니다.

 

 

 

[ 그 외... ]

 

위에서 언급한 특징들 말고도 grafana는 정말 다양한 기능이 제공되고 있습니다.

 

alert rule을 설정하여 prometheus처럼 위험 감지 및 알림 기능을 제공할 수 있고 slack, teams와 같은 다양한 메신저들과 연동도 가능합니다.

 

또한 제공되는 다양한 plugin도 존재하기에 필요한 plugin이 있다면 추가적인 설치를 통해 기능 사용도 가능합니다.

 

더 많은 기능에 대해서 알고 싶으신 분들은 Grafana 공식 문서를 확인해 주시면 도움이 되실 겁니다.

Grafana OSS and Enterprise | Grafana documentation

 

 

 

결과적으로 grafana에 모든 애플리케이션 및 kubernetes에서 관리되는 서버 등에 대한 모니터링 체계를 구축하는 것은 가장 좋은 선택지가 될 수 있습니다.

 

특별한 상황에 의해 grafana를 사용할 수 없는 경우도 발생할 수 있겠지만, 일반적인 경우에 prometheus를 사용하지 않더라도 grafana를 활용하여 모니터링 체계를 구축하는 것은 강력하게 권장합니다.

 

 

 

 

Kube Prometheus Stack

 

kube prometheus stack이라고 하는 것은 kubernetes 환경에서 prometheus와 grafana 등을 활용하여 모니터링 환경을 쉽게 구축할 수 있도록 구성되어 있는 패키지입니다.

 

kubernetes 환경에서 모니터링 환경을 구축한다면 다음과 같은 이점을 얻을 수 있기 때문에 kube prometheus stack 활용을 권장하고 있습니다.

 

• 모니터링 환경 구축에 사용되는 서비스들을 개별적으로 설치할 필요가 없음
• prometheus, grafana, alert manager, node exporter 등의 서비스들이 모두 자동 구성
• helm을 통해 손쉽게 설치할 수 있음
• prometheus operator 기반으로 운영 자동화 제공
• ServiceMonitor와 같은 CRD를 통해 서비스 관리

 

 

 

또한 kube prometheus stack을 활용한다면 애플리케이션에서 발생되는 metric에 대한 정보도 편리하게 grafana에서 모니터링 자료로 사용될 수 있습니다.

 

이후에 작성되는 글들을 통해 적용하는 방식과 결과물들을 통해 더 자세하게 관련 정보들을 제공해 드리겠습니다.

 

 

 

 

 

 

 

이상으로 kubernetes 모니터링을 위한 prometheus, grafana 개념에 대해 간단하게 알아보는 시간이었습니다.

 

읽어주셔서 감사합니다.