일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 주피터노트북 설치
- 쉘스크립트
- terraform기초
- terraform기본
- blue/green배포
- cissp
- AWS실습
- 리눅스기초
- AWS CI/CD
- linux명령어
- terraform with aws
- aws기초
- Linux
- opt/anaconda3/bin/jupyter_mac.command
- AWS구축
- aws
- AWS 공격테스트
- 직무분리
- 리눅스
- aws기본
- GDPR
- 리눅스기초명령어
- aws terraform
- aws따라하기
- AWS CodeDeploy
- 최소권한
- terraform따라하기
- AWS배포자동화
- 리눅스명령어
- Cissp sdlc
ysuekkom의 IT study note
[프로메테우스] k8s 쿠버네티스의 쉽고 빠른 모니터링 도구 prometheus 본문
모니터링은 서비스 안정성과 연속성을 보장할 수 있게 도와주기 때문에, 인프라 운영 시 모니터링(분석 도구)이 반드시 필요하다.
쿠버네티스 운영 시 인프라 환경과 서비스 별(application) 모니터링의 중요성이 더 높아졌다.
서비스별 분석 지표와 대시보드를 제공하여 가시성있게 나타내주는 도구들이 많다.
k8s의 각 노드별 분석 지표(로그, CI/CD 배포 등)는 모니터링 파이프라인을 통해 수집 및 업데이트 되며, 이는 모니터링 도구에 반영, 최종적으로 관리자에게 alert되는 구조로 수행된다.
수집 >> 통합 >> 시각화의 단계로 수행되며, 각 단계에서 메트릭을 수집, 가공, 업데이트, 저장, 변환 등의 과정을 거친다.
- 메트릭(metric)이란?
모니터링 지표를 나타내며 수치화된 정보를 나타낸다. 애플리케이션의 처리량, 고유값, 처리속도, 상태값 등이 메트릭의 예로 들 수 있다.
모니터링 대상에 따라 메트릭의 종류는 달라진다. 예를 들어 로그를 수집 할 경우, k8s 각 클러스터에서 도구를 통해 로그가 추출된다.
검색 엔진인 Elastic Search로 전달되어 로그를 검색 및 가공, 의미있는 정보로 분석할 수 있도록 한다. 서버로부터 데이터를 수집하여 실시간 검색/분석을 수행할 수 있다. 이때, 엘라스틱서치와 함께 시각화 도구인 Kibana를 함께 사용해 로그 조회 및 가시성을 높인다.
내부 sevcie account token 정보로 쉽고 빠르게 모니터링 할 수 있는 도구로 프로메테우스를 당연 많이 사용한다.
프로메테우스에 대해 알아보자.
Prometheus?
프로메테우스는 모니터링 및 경고 시스템이다. 클라우드 네이티브 환경에서는 컨테이너를 기반으로 MSA 아키텍처를 가져간다. 따라서 애플리케이션 별 모니터링이 필요하다. 유연성있게 확장 및 축소하는 환경에서 agent기반의 모니터링 플랫폼 사용이 현실적으로 불가능하기 때문에 k8s api를 통해 모니터링을 수행한다.
프로메테우스 특징을 간단히 알아보자.
- 모든 메트릭을 시계열 데이터로 저장한다. 메트릭 정보는 타임스탬프와 함께 저장되며, key-value로 이루어진 메트릭을 수집하여 label로 집계, 시계열 데이터로 제공한다. 식별자는 metric name과 key-value(optional)로 사용한다.
- PromQL을 사용하여 문법 자체가 쉽고 간단하다. 쿼리 사용법은 프로메테우스 공식문서를 참고하면 된다.
- pull 방식을 사용하여, 프로메테우스 서버가 클라이언트(exporter)에 접속하여 데이터를 가져오는 방식을 사용한다. 기존의 push 방식을 주로 사용하는 모니터링 툴들과 차이가 있다. push방식을 사용할 경우, 불필요한 메트릭을 서버단에서 다루지 않는다는 장점이 있으나, 반대로 수집해야 할 메트릭이 많아 질 수록 복잡성이 증가하는 등의 단점이 있다.
프로메테우스의 기본 아키텍처에 대해 알아보자.
- Prometheus Server: 메트릭 데이터를 수집하고, 시계열 데이터를 저장 및 웹 UI로 접속 등의 역할
- 수집 대상: 스크랩 대상으로, 컨테이너, 노드, 클러스터 등의 메트릭을 수집, Service Discovery를 통해 Server와 통신
- Alert Manager: 미리 설정된 규칙에 따라 경고를 발생 시키는 역할
프로메테우스 아키텍처 살펴보기
수집 - 통합 - 시각화 그룹으로 나누어 표기해두었다. 아래 세부 아키텍처에서 살펴봐야 할 컴포넌트들을 알아보자.
Prometheus Server UI 내 Status에서 살펴 볼 Service Discovery, Target, Configuration의 관계성도 살펴보자.
- Expeorter
프로메테우스가 메트릭을 요청하면(앞서 언급한 pull방식) 데이터를 내보내는 역할을 수행한다. 여러 종류의 오픈소스 Exporter가 있다. 예를 들어, k8s 노드 별 node-exporter가 존재한다. 또 k8s api서버의 상태를 전달하는 kube-state-merics 등이 있으며, 개인이 만들어 데이터를 수집할 수 있는 custom metric exporter를 사용할 수 있다. 정상적인 노출이 전제되어야 서비스 디스커버리에서 메트릭을 수집을 위한 동작을 수행할 수 있다.
- Job
scrape config에 metric scrape job을 등록하여 HTTP 엔드포인트에 접근, 모니터링 대상의 메트릭을 수집해 올 수 있다. job은 Target URI에 연결된 인스턴스에서 주기에 따라 메트릭을 수집해 온다.
job_name 기준으로 scrape할 대상을 확인한다.
- Prometheus Server
프로메테우스는 pull 방식으로 프로메테우스 서버가 수집된 대상의 HTTP Endpoint로 접속하여 메트릭을 수집, 서버에 저장하는 구조이다. default 값으로 15day동안 저장하므로, storage.tsdb.retention.time 옵션을 통해 용량을 조절할 수 있다.
- Configuration
Configuration 내 job_name을 기준으로 수집 대상을 인식한다.
Configuration 내 kubernetes_sd_configs: 를 통해 수집 대상을 읽어들여 Service Discovery가 수집 대상 목록을 읽어들이는 구조이다.
>>도달하여 수집할 수 있는 대상을 모아놓은 것이 Target으로 보면 된다.
- Target
수집할 대상이 Target에 등록되어야 프로메테우스 서버가 메트릭을 수집 할 수 있다. Prometheus Server가 수집 대상을 인식했는지 확인 할 수 있는 지표이다.
- Service Discovery
프로메테우스의 모니터링 대상 목록을 가지고 있다. 대상에 대한 정보를 가지고 있으며, 모니터링 대상이 등록되어있는 저장소에서 정보를 받아서 저장하기 때문에, ip변경에도 영향을 받지 않는다.
즉, prometheus server가 메트릭 수집을 위해서는 Service Discovery의 동작이 필요하다.
Prometheus metric 수집 구조를 이해하는데 있어 Service Discovery, Configuration, Target의 이해가 반드시 중요하다!
즉, 수집 대상에 대한 시작은 Configuration에서 시작되며, Service Discovery가 수집 대상을 읽어들여 Target을 생성하게 되는 것!
- Alertmanager
미리 정한 임계치를 Rule로 저장하고, 룰에 따라 알람을 발생시키는 역할을 한다.
//alertmanager-config.yaml
프로메테우스를 배포해보자!
프로메테우스를 설치하고 난 뒤, 프로메테우스 구성을 위해 yaml파일을 사용한다.
메트릭 수집 주기를 default 값인 1min에서 15s로 변경하여 구성한다.
[root@m-k8s 2.2]# ls -rlt
total 8
-rwx------. 1 root root 723 Jul 28 23:06 prometheus-installer-1m-default.sh //주기 1분=default
-rwx------. 1 root root 815 Jul 28 23:06 prometheus-installer-15s.sh //주기 15초
[root@m-k8s 2.2]# ./prometheus-installer-15s.sh //15s로 배포
NAME: prometheus
LAST DEPLOYED: Fri Jul 28 23:15:40 2023
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The Prometheus server can be accessed via port 80 on the following DNS name from within your cluster:
prometheus-server.monitoring.svc.cluster.local
Get the Prometheus server URL by running these commands in the same shell:
NOTE: It may take a few minutes for the LoadBalancer IP to be available.
You can watch the status of by running 'kubectl get svc --namespace monitoring -w prometheus-server'
export SERVICE_IP=$(kubectl get svc --namespace monitoring prometheus-server -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo http://$SERVICE_IP:80
#################################################################################
###### WARNING: Pod Security Policy has been moved to a global property. #####
###### use .Values.podSecurityPolicy.enabled with pod-based #####
###### annotations #####
###### (e.g. .Values.nodeExporter.podSecurityPolicy.annotations) #####
#################################################################################
For more information on running Prometheus, visit:
https://prometheus.io/
[root@m-k8s 2.2]# cat prometheus-installer-1
[root@m-k8s 2.2]# cat prometheus-installer-15s.sh
#!/usr/bin/env bash
# scrape default is 1m
helm install prometheus edu/prometheus \
--set pushgateway.enabled=false \ //pushgateway 사용안함
--set alertmanager.enabled=false \ //alertmanager 사용안함
--set nodeExporter.tolerations[0].key="node-role.kubernetes.io/master" \
--set nodeExporter.tolerations[0].effect="NoSchedule" \
--set nodeExporter.tolerations[0].operator="Exists" \
--set nodeExporter.tolerations[1].key="node-role.kubernetes.io/control-plane" \
--set nodeExporter.tolerations[1].effect="NoSchedule" \
--set nodeExporter.tolerations[1].operator="Exists" \
--set server.service.type="LoadBalancer" \
--set server.global.scrape_interval="15s" \ //프로메테우스 서버의 메트릭 수집 주기 15s로 설정됨
--set server.global.evaluation_interval="15s" \
--set server.extraFlags[0]="web.enable-lifecycle" \
--set server.extraFlags[1]="storage.tsdb.no-lockfile" \ //로그의 시간 정보가 틀어져도 lock 걸리지 않게 설정--실습 환경이라 추가됨
--namespace=monitoring \
--create-namespace
[root@m-k8s 2.2]# kubectl get pod,svc -n monitoring
NAME READY STATUS RESTARTS AGE
pod/prometheus-kube-state-metrics-5c9f756cf8-zg54w 1/1 Running 0 25s
pod/prometheus-node-exporter-48fl8 1/1 Running 0 25s
pod/prometheus-node-exporter-5smq6 1/1 Running 0 25s
pod/prometheus-node-exporter-7fgfz 1/1 Running 0 25s
pod/prometheus-node-exporter-7w54b 1/1 Running 0 25s
pod/prometheus-server-d94b68f64-9dq47 0/2 ContainerCreating 0 25s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/prometheus-kube-state-metrics ClusterIP 10.96.209.148 <none> 8080/TCP 25s
service/prometheus-node-exporter ClusterIP None <none> 9100/TCP 25s
service/prometheus-server LoadBalancer 10.105.157.160 192.168.1.11 80:32303/TCP 25s
[root@m-k8s 2.2]#
[root@m-k8s 2.2]# kubectl get pod,svc -n monitoring
NAME READY STATUS RESTARTS AGE
pod/prometheus-kube-state-metrics-5c9f756cf8-zg54w 1/1 Running 0 2m40s
pod/prometheus-node-exporter-48fl8 1/1 Running 0 2m40s
pod/prometheus-node-exporter-5smq6 1/1 Running 0 2m40s
pod/prometheus-node-exporter-7fgfz 1/1 Running 0 2m40s
pod/prometheus-node-exporter-7w54b 1/1 Running 0 2m40s
pod/prometheus-server-d94b68f64-9dq47 2/2 Running 0 2m40s //모두 올라옴
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/prometheus-kube-state-metrics ClusterIP 10.96.209.148 <none> 8080/TCP 2m40s
service/prometheus-node-exporter ClusterIP None <none> 9100/TCP 2m40s
service/prometheus-server LoadBalancer 10.105.157.160 192.168.1.11 80:32303/TCP 2m40s
[root@m-k8s 2.2]#
service/prometheus-server LoadBalancer 10.105.157.160 >>>192.168.1.11<<< 80:32303/TCP 25s
192.168.1.11로 접속하여 프로메테우스 서버가 잘 배포되었는지 웹ui 뜨는지 확인해보자.
프로메테우스 Web UI 접속하기
192.168.1.11로 접속 확인!
user local time>>korea standard time 잡아주자.
다음으로 promql up전달하여 프로메테우스에서 제대로 정보가 수집되고 적용됐는지 확인해보자.
promql (up)으로 정상 확인하기
마치며
프로메테우스를 설치하고, 배포, 각 구성요소들의 특징과 관계에 대해 간략하게 알아보았다.
다음 포스팅에서는 다양한 Exporter에 대해 알아보고 세부적인 역할과 동작 원리에 대해 정리해보겠다.
각 포스팅 내용은 필요에따라 발행 이후에도 수정/추가 될 수 있음을 참고바란다.
이슈
배포 후 추가 실습 중 VirtualBox가 꼬이면서 뻗는 현상이 발생했다!
워커노드의 상태를 읽어들이지 못했고, "완전히 꼬임" 상태가 표시되었다.
로그를 확인해 보니, Unhandled error 1453 메시지를 확인할 수 있었다. error는 RAM 부족 현상으로 발생하였고, 확인해보니
D:\tinderbox\win-7.0\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(464) int __cdecl RTErrConvertFromWin32(unsigned int): <NULL>
Unhandled error 1453
AIO/win: Request 0x00029fd93d7ef0 returned rc=VERR_UNRESOLVED_ERROR (native 1453
Host RAM Usage가 99%사용되고 있었다. 실습환경이 열악하긴 했지만(8기가라 처음부터 걱정했던 부분)
당장 실습이 불가능한 상태가 되었다. PC로 환경을 재구성하고, 실습을 한 뒤 포스팅을 해야 할 것 같다!!
참고
https://prometheus.io/docs/tutorials/getting_started/#basic-architecture-of-prometheus
https://ooeunz.tistory.com/139
https://www.yes24.com/Product/Goods/102099414
https://www.inflearn.com/users/@kubernetes/courses
https://prometheus.io/docs/instrumenting/writing_exporters/