추가한 컨테이너는 총 세 개임
- cadvisor
- prometheus
- node-exporter
구성은 전부 공식문서들을 참조하엿음
---
prometheus 는 다들 들어본적 잇는 메트릭 모니터링 시스템임
사진은 prometheus 를 정의한 docker-compose 코드임
command 로 밀어넣은 설정들은 공식문서의 node exporter 를 통해 linux host system monitoring 예제에 잇는걸 참고해서 가져왓고, 특이점이 잇다면 retention time 이랑 retention size 임
https://prometheus.io/docs/guides/node-exporter/
나같은 경우 프리티어로 받은 클라우드 컴퓨트 인스턴스의 스토리지가 그렇게 넉넉치가 않아서, 512MB 가 넘으면 / 3일이 넘으면 tsdb (time series db) 에 쌓아놓은 데이터를 비우도록 설정햇음
그리고 prometheus 에서 쌓은 메트릭 데이터들을 저장하기 위해 prometheus 라는 이름의 volume 도 하나 만들어주엇음
이건 prometheus config 파일
어떤 메트릭들을 어떻게 가져올건지 정의하는 부분
나같은 경우 1분 간격으로
- prometheus
- node-exporter
- cadvisor
를 통해 메트릭을 수집하도록 설정함
*nix kernel 을 통해 접근할수 잇는 하드웨어/운영체제 메트릭들을 가져오는 구성요소이고, 설정 자체는 위에 링크한 prometheus 공식문서 예제를 그대로 따름
node-exporter 가 호스트 머신의 메트릭을 가져오는 거라면, cadvisor 는 그 호스트 머신에 구동되고 잇는 컨테이너들의 메트릭을 가져오는 구성요소임
https://prometheus.io/docs/guides/cadvisor/
설정은 위의 글을 보고 참고햇는데, 이미지 버전을 저렇게 특정하게 된 이유가 잇음
일단 내 개발환경은 m1 max 맥북(linux/amd64) 이고, 배포되는 환경은 arm64 아키텍처임
그런데 이전 이미지까지는 arm64, amd64 지원이 제대로 되지 않앗다가, 최근 버전이 되어서야 지원을 제대로 해줌
이슈의 년도를 보면 꽤 오래 전부터 잇엇던 제안이엇음을 알수잇음
가장 최신버전인 0.47.2 버전의 manifast 를 보면 알수잇듯 이제 다양한 아키텍처들을 잘 지원해줌
그리고 이렇게 구성한 prometheus 의 데이터를 grafana dashboard 에 연동시켜줌
이렇게 컨테이너들을 다시 배포하게 되면, grafana 에 prometheus datasource 가 생김
대시보드는 사람들이 고맙게도 예쁘게 만들어줘서, 거기에 잇는 것들을 가져다사용함
처음에 사용한 건 node exporter 를 위한 대시보드
copy id to clipboard 해서 dashboard import 에 그 id 붙여넣고 prometheus datasource 연동하면 끝
그 다음으로 구성한건 cadvisor 를 위한 대시보드
위에 적은것과 마찬가지로 아주 간단하게 연동가능함
그런데 이런 대시보드들을 찾아보면서 느낀건데... 그냥 빨리 K*s 런타임으로 넘어가야겟다는 생각만 들음
K*s 런타임은 다운로드수도 엄청나고 유지보수도 꾸준히 되는반면, docker 로 구성한 사람들을 위한 대시보드들은 대체적으로 다 유기되엇음
---
공식문서를 보고 따라하는 굉장히 기초적인 과정이다만, 혹여나 누군가에게 도움이 되길 바라며 간단하게 작성해봄
K*s 런타임 이 뭐임?
쒸쁘뜨8
요즘 K8s 만 잇는게 아니고 말고 경량화 버전들이 많더라고 K3s, K0s...
k3s k0s도 k8s임 eks가 k8s가 아닌게 아닌것처럼 k3s도 k8s가 아닌건 아님
https://www.cncf.io/certification/software-conformance/
스크랩 주기 1분은 너무 긺. 5초 ㄱ - dc App
감사합니다! 바로 수정 들어가야겠음
디폴트가 분단위인 이유는 메트릭 정보 자체가 실시간성이 필요 없어서임 5초는 넘 짧다고 생각
근데 프로메테우스 왜 많이 쓰는건지 혹시 암? 플루언트디나 로그스태시 같은 매트릭 수집 툴 중에 좋은 이유가 있을거 아녀
일단 뒤에 말한 두개는 중앙에서 로그를 집계하는 역할을 하고, 프로메테우스는 메트릭을 집계하는 역할이라 보음 다름. 그라파나의 Loki 가 그런역할
왜 많이 쓰냐고 묻는다면 OSS 로 나오는 것들 중에서 이만한게 없어서 라고 대답할 듯?
메트릭 수집이 크게 statsd랑 prometheus 정도가 있는데 statsd는 라벨을 못붙이는 방식이라 사용이 불편함. statsd+telegraf+influxdb보다 prometheus+prometheus exporter 쓰는게 훨씬 편하고 쿼리도 좋음. logstash, fluentd는 log forwarder, aggregator고 prometheus는 scraper+timeseries db+기타등등이라고 보면됨. prometheus 성능 개선을 목적으로 한 victoriametrics도 있음
220.94 덕에 잘 모르던것들 많이 알아간다 자세한 설명 너무 고마워
로그스태시면 beat elk스택 같은거 얘기일텐데 관리해야 될 게 너무 많음. 프로메테우스는 로직 자체가 열린 웹서버로 요청을 하는 형식임. 즉 이렇다할 설정이 많이 필요가 없고 타겟에만 추가해주면 됨. 위에 있는 애 얘기처럼 telegraf 같은거 사용하면 골치 아파. 개더링해서 쏴주는 아웃풋 인풋 고려해야되고 로그스태시도 아웃풋 인풋 다 써야됨.(물론 웹서버도 있긴해) 근데 프로메테우스는 설정할 게 타겟 설정 뿐이고 타겟에서는 그냥 웹서버 올려버리면 그만임. 호환성도 좋고 내 스스로 exporter를 만들수도 있어서 다양한 데이터 수집이 가능함. PromQL도 되게 직관적이고 보기 편한 편
그리고 프로메테우스의 장점 중 하나가 federation이라 생각하는데 프로메테우스 1 2 3을 통합해서 또 다른 프로메테우스에서 통합할 수 있음. 메트릭 관리에선 큰 강점일 수 있지 Lan환경을 집약해서 특정한 Wan환경으로 통합해주는게 너무 편하니까. 일종의 간이 data lake로 쉽게 구성할 수 있다는 장점이 큼.
정성글은 추천줘라 게이들아.
강의 찍어도 되겠다
helm한방에 끝나긴함 - dc App