솔직히 여태 모니터링과 관련해서는 지식이 전무하다.
왜 해야하는지는 대강알고있었지만, 어떻게 해야하고 정확히 왜 필요한지는 모른다.
모니터링이 필요한 이유
내부적으로 테스트를 진행하고 문제가 없어 배포를 하였지만, 실제로 사용화 작업 후 실제로 사용을 하다보면 어디선가 문제가 생긴다.
이러한 문제가 생긴다면 개발자는 어디서 문제가 발생했는지 빠르게 적절한 조치를 취해야 한다.
이러한 조치를 취하기 위해서는 구축환경 자체를 모니터링하여야 하며 이것이 바로 모니터링이 필요한 이유이다.
모니터링 방법
실제로 우리가 직접 애플리케이션이 구동되는 화면을 보고 할 수 있지만, 이는 한계가 있다. 그저 로그만 보며 어디서 어떠한 문제가 생기는지밖에 알 수 없는데, 이런 단점을 보완하기 위해 모니터링 도구를 사용하게 된다.
모니터링 도구
모니터링 도구는 다양하지만, 대표적으로 프로메테우스와 그라파나 이 두가지의 도구가 존재한다.
여기서 이 도구는 모두 오픈소스이며, 한 단일 도구에서 단일 기능만을 구현하는것을 선호하는 도구이다.
프로메테우스
프로메테우스는 대상 시스템으로부터 각종 모니터링 지표를 수집하여 저장하고 검색할 수 있는 시스템이다.
특징으로, 그라파나를 통해 시각화를 할 수 있으며, 많은 시스템을 모니터링할 수 있는 다양한 플러그인이 존재한다. 추가로 쿠버네티스의 메인 모니터링 시스템으로도 사용이 되며, 주기적으로 Exporter(모니터링 대상 시스템)으로부터 pulling방식으로 메트릭을 읽어서 수집한다.
그라파나
그라파나는 프로메테우스를 비롯한 여러 데이터들을 시각화 해주는 모니터링 툴이다.
어라? 그러고보니 저번에 배웟던 ELK 의 Kibana와 비슷한 역할을 하는것같다.
Kibana VS Grafana
Kibana는 주로 로그 메세지 분석에 쓰이는 반면, Grafana는 시스템 관점의 메트릭 지표를 시각화하는데 특화되어있다.
또, Kibana의 경우 ElasticSearch에 묶여있어 아쉽지만 Grafana는 다양한 데이터베이스를 선택할 수 있다는 장점과 알림 기능을 무료로 사용할 수 있는 장점을 가지고 있다.
메트릭
위에서 메트릭이라는 단어가 좀 자주 나왔는데, 메트릭이 무엇일까?
시스템의 상태를 알 수 있는 측정값이다.
컨테이너 인프라 환경에서는 크게 2가지의 메트릭을 구분하는데,
CPU와 메모리 사용량을 나타내는 System Metric,
HTTP 상태 코드 같은 서비스의 상태를 나타내는 Service Metric으로 구분된다.
출처
