Grafana와 Prometheus

시작하기...

전 회사에서 항상 골치였던 것들 중 하나는 바로 CPU가 뻗어버리는 일이 자주 발생했다는 것이었다. 클라우드 서비스를 이용하는 것이 아닌, 실제 물리 서버에 연결되는 구조였지만, 여러가지 이유로 인해 필요한 성능보다 낮은 부품들로 구성된 서버를 활용한 탓에 새벽마다 CPU 사용률 99%를 찍고 죽어버리기 일쑤였다. (당연히 메모리도 마찬가지였다.) 이렇게 될 경우 가장 끔찍한 것은 원격으로 접근이 되지 않는다는 것이다.

 

안타깝게도 이러한 서버의 상태를 어떻게 모니터링 할 수 있는가에 대한 지식이 전무했던 시절이기도 했고, 아무도 알지 못했다. 그야말로 낭만이 넘치는 야생의 환경이었다. 하지만 인간은 발전하는 동물. 우리는 늘 더 나은 방법을 찾을 수 있다. 물리 서버의 상태를 늘 확인하고 갑작스럽게 뻗어버려 서비스가 멈춰버리는 사태를 제어하기 위해 우리는 Grafana에 대해 배울 필요가 있다. 

 

Grafana? Prometheus?

https://www.devopsschool.com/blog/what-is-prometheus-and-how-it-works/

그라파나를 배우면 반드시 따라붙는 Prometheus는 간단히 말해 대상 시스템의 여러 모니터링 지표를 수집하고 검색하고 저장할 수 있는 시스템이다. 하지만 데이터만 수집하게 되면 모니터링 할 때 불편함이 상당하다. 해당 데이터들이 시각화 되기 전까지는 사실상 어떤 흐름을 가지는지 전혀 알 수 없기 때문이다. 따라서 마치 단짝친구와 같이 Prometheus는 시각화 도구가 필요한데, Grafana가 그 역할을 수행한다고 볼 수 있다.

 

What is Prometheus? | Grafana documentation

 

따라서 우리는 Prometheus를 통해 시스템의 CPU, 메모리 사용률 등의 정보를 수집하여 저장해두면, 해당 정보들을 끌어와 Grafana로 시각화하여 확인할 수 있다. 일반적으로 node exporter을 모니터링하고자 하는 서버마다 설치해서 데이터를 수집할 수 있다.

 

Alloy? Loki? 

Alloy가 터지면 로그들은 어떻게 해야 하죠? Devops에서 질문이 나왔을 때 내 머리속은 'Alloy가 뭔데 터지기까지 하나요...?'였다. 알로이. 내가 아는건 알로에 음료 뿐인데. 나중에 찾아보니 Grafana Alloy와 Grafana는 다른 것이었다. 조금 더 정확히 말하자면, 목적이 다르다. grafana가 시각화 용도라면, Alloy는 데이터 수집 및 전송 도구이다. 당연하지만 데이터를 수집하는 기능을 가진 것은 Prometheus 뿐만이 아니다. 무수한 오픈소스 관측 도구들이 있는 만큼 이것들을 하나로 통합해서 관리할 필요가 있는데, 이 역할을 Alloy가 하는 것으로 보면 된다. 

 

Alloy에서 통합하여 관리할 수 있는 오픈소스에는 Loki와 같은 도구가 있다. Prometheus가 CPU 및 메모리 사용량을 수집한다면, Loki는 로그 수집 및 관리 도구로 사용된다. 웹 애플리케이션에서 에러가 발생할 경우 이를 감지하여 Grafana에서 해당 에러 발생을 확인할 수 있게 모니터링이 가능하다. 클라이언트들이 서비스를 사용하는 동안 발생하는 문제들을 원격으로 확인이 가능하게 된다.

 

어차피 모니터링을 위한 기능일 뿐이고 실서비스에만 영향을 미치지 않으면 될 것이라 생각할 수 있겠지만, 금전적 거래가 이루어지는 서비스를 운영하는 경우, 이러한 데이터와 로그를 수집해오는 작업은 데이터가 누락될 경우 매우 큰 문제로 이어질 수 있다. 하필이면 데이터가 누락된 시점에 고객이 결제를 진행하고 문제가 생긴다면 우리는 언제, 어디서 왜 문제가 생겼는지 알 방법이 없기 때문이다.

 

생각해볼 부분

서버는 강한 동시에 유리처럼 연약하다. 툭하면 용량 부족으로 터지기 일쑤인 만큼, 감당 불가능할 정도의 통신이 일어나는 것을 막기 위해 항상 관리를 하고 제한해야 한다. 문제는 이런 모니터링 데이터는 더 나은 서비스를 제공하기 위한 필수적 요인임에도 불구하고 너무 거대한 데이터 용량을 가진다. 그리고 이 모든 대규모 데이터 통신은 클라우드 서비스에서는 지출로 발생한다. 양날의 검과 같은 것이다. AWS를 사용하면서 이러한 비용적인 부분에 대해서 고려하는 것도 늘 생각해 보아야 할 부분인 듯 하다.

 

다음 시간에는 지난번에 시도했던 docker까지 활용해서 배포 프로세스를 다시 정립하고 grafana로 모니터링 하는 과정 전반을 기록해보려 한다. 웹사이트는 일전에 실습으로 사용했던 Next14로 진행해보고자 한다.