PV
PVC, PV Mount
현재 생성되어 있는 PV와 Prometheus pod가 scheduling된 Node의 AZ이 동일해야 함
PVC 크기
retention, System 크기(Metric 수집량)에 따라 PVC 용량을 잘 선정해야 함
경험에 의하면, retention 30d이면 최소 30G 이상은 해야 함 (50G 이상을 추천)
Resource
Prometheus 예약 resource
특히, Grafana에서 Prometheus에 날리는 Query가 복잡하면 Resource 사용량이 늘기 때문에 더더욱 limit을 크게 잡아두고 사용해야 함
request를 적게 주더라도 limit은 크게 주고 운영하다가 추후에 사용량을 기반으로 다시 request와 limit을 최적화하는 것을 추천
정리하면, 순서대로
- 운영용 NodeGroup에 Prometheus를 배치하도록 하고, request, limit 모두 여유를 많이 주고 배포(limit을 아예 안주는 것도 방법)
- Grafana의 Dashboard를 띄우고 Resource 사용량 확인
- Resource request, limit 최적화
Servicemonitor
Servicemonitor target missing
addon, ecosystem의 특정 메트릭을 수집하기 위해 Servicemonitor(혹은 podmonitor)를 생성했는데, 메트릭 감지가 되지 않는 경우
해당 메트릭 데이터가 없을 수도 있고, prometheus가 servicemonitor를 감지 못 한 것일 수도 있음
따라서, prometheus service를 브라우저에서 띄운 다음, status-target에 들어가서 생성했던 Servicemonitor가 감지된 상태인지 확인
Prometheus의 target에서 Servicemonitor가 안보이면, 아주 높은 확률로 label 문제일 수 있음
(Prometheus에서 Servicemonitor를 검색하고 감지해서 target으로 설정하는 과정에서, prometheus의 label이 꼭 붙어야만 target으로 지정하게 하는 것이 default 설정이기 때문)
두 가지 해결 방안
- Prometheus 설정에서 label과 상관 없이 모든 Servicemonitor를 감지하도록 변경 : helm chart를 보면 serviceMonitorSelectorNilUsesHelmValues 이런 변수가 있는데 이걸 true 로 설정
- Prometheus의 특정 label을 Servicemonitor에 적용 : prometheus를 helm으로 설치했다면, Servicemonitor의 label에 release: kube-prometheus-stack를 추가해야 함
'Monitoring' 카테고리의 다른 글
Prometheus-adapter를 이용한 custom.metrics.k8s.io API 사용 (for HPA v2beta2 target) (1) | 2023.08.28 |
---|---|
Loki Deployment to k8s (0) | 2023.02.14 |
TSDB의 데이터 수집 방식 (polling, trapping) (0) | 2023.02.14 |
Prometheus Recording Rule (0) | 2023.02.14 |
prometheus relabeling (0) | 2023.02.14 |