프로메테우스

프로메테우스 기능

프로메테우스 서버 ↔ 프로메테우스 어댑터 → HPA → 디플로이먼트 → 파드

• 파드의 정보를 프로메테우스 익스포터를 이용해서 수집한 후 프로메테우스 어댑터에게 전송한다.
• 파드는 쿠브 프록시를 이용해서 관리 프로메테우스 오퍼레이터가 쿠브 프록시를 감시한다.

프로메테우스 오퍼레이터

• 쿠버네티스에서 프로메테우스를 구성할 때 자원 관리와 프로비저닝을 수행한다.
  • 일반적으로 쿠버네티스에서는 헬름이나 오퍼레이터로 프로메테우스를 설치할 수 있다.
  • 그라파나는 현재는 헬름으로만 설치가 가능하다.
• 쿠버네티스에서 동적으로 증가하는 파드와 서비스를 발견
  • 프로메테우스 오퍼레이터 내부의 Service Monitor와 Pod Monitor가 서비스 디스커버리 역할을 수행한다.
  • 오퍼레이터가 서비스와 파드의 증감 발생 시 프로메테우스 구성 파일을 업데이트한다.

프로메테우스 익스포터

• 특정 메트릭을 수집해서 엔드포인트에 노출시키는 소프트웨어 혹은 에이전트
  • 데이터베이스, 하드웨어, 메시지 시스템, 저장소 등 여러 시스템에 대한 익스포터 등과 기존의 서버 모니터링에 사용되는 에이전트와 통합 가능하다.
• 기본적으로 제공해주는 익스포터 외에 도메인에 적합하게 개발된 마이크로서비스의 메트릭을 측정하고자 하는 경우는 커스텀 익스포터를 개발하면 되는데 이 경우에 사용할 수 있는 API와 SDK를 제공한다.

프로메테우스 어댑터

• 메트릭이 익스포터를 통해서 제공되면 프로메테우스 서버가 이를 스크래핑한 후 증가하는 시스템 부하에 대응하기 위해서 HPA(Horizontal Pod Autoscaler)를 통해 파드를 오토스케일링한다.
• 기존 메트릭 서버는 기본 케트릭만 측정할 수 있으며 복잡한 커스틱 메트릭을 지원하지 못했는데 프로메테우스 어댑터로는 복잡한 커스텀 매트릭을 측정하고 HPA와 연계해서 신속하게 오토스케일링을 지원한다.

프로메테우스 자체로 생태계를 구성하고 쿠버네티스와 긴밀한 연계를 통해서 클라우드 네이티브를 구현한다.

• 쿠버네티스의 역할은 애플리케이션을 포함한 컨테이너를 운영하고 스케쥴링 하는 것이고 프로메테우스는 쿠버네티스 기반의 애플리케이션이 원활하게 동작하도록 다양하고 복잡한 역할을 수행한다.

프로메테우스의 라이프 사이클

• 메트릭을 수집하고 시계열로 저장한다.
• 메트릭을 측정하고 리소스를 오토스케일링
• 변경된 리소스를 자동으로 디스커버리
• HPA와 연계해 증가한 리소스로 유저 트래픽을 분배

프로메테우스와 노드 익스포터 설치 메트릭 조회

• 노드 익스포터: 유닉스 계열으 ㅣ커널을 가진 하드웨어와 OS의 시스템 메트릭을 수집해주는 소프트웨어
• 프로메테우스 바이너리 설치
  • 다운로드: wget https://github.com/prometheus/prometheus/releases/download/v3.5.0/prometheus-3.5.0.linux-amd64.tar.gz
  • 압축 해제: tar xvzf prometheus-3.5.0.linux-amd64.tar.gz
  • 프로메테우스 사용을 위한 유저 추가: sudo useradd --no-create-home --shell /bin/false prometheus
  • 디렉토리 생성
    • sudo mkdir /etc/prometheus
    • sudo mkdir /var/lib/prometheus
  • 디렉토리의 소유자 변경
    • sudo chown -R prometheus /etc/prometheus
    • sudo chown -R prometheus /var/lib/prometheus
  • 프로메테우스 실행 파일 이동
    • sudo cp prometheus-3.5.0.linux-amd64/prometheus /usr/local/bin/
    • sudo cp prometheus-3.5.0.linux-amd64/promtool /usr/local/bin/
  • 실행 파일의 소유자 변경
    • sudo chown prometheus /usr/local/bin/prometheus
    • sudo chown prometheus /usr/local/bin/promtool
  • 설정 파일 생성
    • cd /etc/prometheus
    • vi prometheus.yaml

  global:
    scrape_interval: 15s
    evaluation_interval: 15s
  
  scrape_configs:
    - job_name: "prometheus"
      static_configs:
        - targets: ["localhost:9090"]
  
    - job_name: "node"
      static_configs:
        - targets: ["localhost:9100"]
  

  • prometheus 서비스의 유저를 prometheus로 등록하기 위한 설정 파일 생성

  [Unit]
  Description=Prometheus
  Wants=network-online.target
  After=network-online.target
  [Service]
  User=prometheus
  Group=prometheus
  Type=simple
  ExecStart=/usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yaml --storage.tsdb.path /var/lib/prometheus/ --storage.tsdb.max-block-duration=1m --storage.tsdb.min-block-duration=1m --web.enable-lifecycle --web.enable-admin-api --log.level=info
  [Install]
  WantedBy=multi-user.target 
  # 서버가 실행될 때 서비스도 같이 실행되도록 해주는 옵션 # 일반 서버 서비스는 이 옵션을 선택, GUI까지 실행>된 후 서비스를 실행시키고자 하면 graphical.target 이라고 설정하고 default.target으로 설정해도 된다. 이 옵션의 적용은 enable 명령을 수행하면 적용된다.
  

  • 서비스 파일을 서비스를 시작할 수 있는 디렉토리(/etc/systemd/system)로 이동: sudo mv prometheus.service /etc/systemd/system/
  • ls /etc/systemd/system/prometheus.service #결과: /etc/systemd/system/prometheus.service
  • 서비스 시작: sudo systemctl start prometheus
  • 서비스 확인: sudo systemctl status prometheus
    • curl http://localhost:9090/-/ready
    • 결과로 Prometheus Server is Ready. 가 나올 것이다.
  • vm에서 포트포워딩

• node_exporter 설치
  • node_exporter 바이너리 파일 다운로드
    • 다시 ~/prometheus 폴더로 돌아가서 (그 전까진 계속 /etc/prometheus에 있었다.) wget https://github.com/prometheus/node_exporter/releases/download/v1.9.1/node_exporter-1.9.1.linux-amd64.tar.gz
    • 압축 해제: tar xvzf node_exporter-1.9.1.linux-amd64.tar.gz
  • 유저 추가
    • sudo useradd --no-create-home --shell /bin/false node_exporter
      • 이때 node_exporter는 유저 이름
  • 실행 파일 복사: sudo cp node_exporter-1.9.1.linux-amd64/node_exporter /usr/local/bin/
  • 소유자 변경: sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter
  • 서비스 등록: sudo vi /etc/systemd/system/node_exporter.service

  [Unit]
  Description=Node Exporter
  Wants=network-online.start
  After=network-online.target
  [Service]
  Type=simple
  User=node_exporter
  Group=node_exporter
  ExecStart=/usr/local/bin/node_exporter
  Restart=on-failure
  [Install]
  WantedBy=multi-user.target 
  

  • 서비스 실행: sudo systemctl start node_exporter
  • sudo systemctl status node_exporter
  • 확인: http://localhost:9100/metrics

프로메테우스 시계열 데이터베이스

• 데이터 형식
  • 9100/metrics 경로를 통해서 데이터를 제공하면 프로메테우스 서버는 pull 방식으로 익스포터에서 그 데이터를 수집해서 시계열 데이터베이스에 저장한다.
    • http_requests_total {status="200", method="Get"} @숫자1 숫자2
      • http_requests_total이 메트릭 이름, {status="200", method="Get"} 은 레이블, 숫자1은 타임스탬프 숫자2는 값
    • http_requests_total은 2개의 레이블(status와 method)을 포함하는데 status 레이블은 3종류(200-정상 응답, 400-클라이언트 오류, 500-서버 오류) method 레이블은 GET과 POST 두 종류
      • 실제로는 3*2=6개의 시계열 데이터를 생성한다.
    • 메트릭에 데이터의 개수는 중요한데 이를 통해서 프로메테우스의 성능과 저장 용량이 결정된다.
    • 카디널리티
      • 프로메테우스 인스턴스에 할당되는 컴퓨팅 리소스에 따라 여러 개의 시계열 데이터를 점진적으로 처리한다.
      • 카디널리티는 전체 행에 대한 특정 컬럼의 중복 수치를 나타내는 지표이므로 프로메테우스 서버가 스크래핑을 결정하는 기준이 된다.
      • 주로 메트릭 이름과 연관된 레이블의 이름/값의 조합으로 생성되는 고유 시계열 수를 의미한다.
      • 메트릭에 수없이 조합된 여러 차원은 프로메테우스에서 카디널리티 폭발을 야기하는데 너무 많은 시계열이 생성된다.
      • 중요한 데이터가 아니라면 프로메테우스보다는 로그 기반 시스템에서 처리하는 것이 효율적이다.
• 데이터 관리
  • 위의 형식의 데이터는 프로메테우스 데이터베이스에 저장된다.
  • 프로메테우스 TSDB는 시계열 데이터베이스
  • 특징
    • 프로메테우스 TSDB는 LRU 알고리즘을 사용하는데 이 알고리즘은 가장 오랫동안 참조되지 않은 데이터를 제거하는 교체 알고리즘이다.
    • 프로메테우스 TSDB는 Memory Paging을 사용하는데 이 방식은 프로세스를 일정 크기인 페이지로 분할해서 메모리에 적재하는 방식이다.
    • 샘플을 수집하고 블록 형태로 만들어서 디스크에 저장한다.
    • 프로메테우스에서는 데이터라는 용어 대신 Chunk라는 용어를 사용한다.
    • 하나의 블록은 다수의 청크와 인덱스 그리고 여타 데이터로 구성된다.
    • 데이터 셋은 다수 데이터 그룹을 의미하며 데이터 포인트는 대시보드에서 시계열로 출력되는 개별 데이터이다.
• 데이터 레이아웃
  • 데이터가 프로메테우스에 저장되는 방식은 청크를 포함하는 일련의 디렉토리, 해당 데이터에 대한 LevelDB 인덱스, 사람이 읽을 수 있는 정보가 있는 meta.json 파일과 더 이상 필요하지 않은 데이터에 대한 삭제 표시로 구성된다.
  • 이런 블럭 각각이 데이터베이스를 나타낸다.
• 블록 관리
  • 샘플
    • 시계열 데이터
    • 수집된 데이터 포인트로 시계열의 수치를 나타낸다.
    • 샘플을 정의하는데 필요한 요소는 float64 값과 타임스탬프
    • 여러 개의 블록들이 병합되어서 더 큰 블록을 생성한다.
    • 시계열을 조회하고 저장 효율성을 향상 시키기 위해서 블록을 병합하여 적당한 크기로 생성한다.
    • 데이터를 저장하기 위한 물리적인 저장소를 효율적으로 사용하고 조회 속도를 향상시키기 위해 블록의 크기와 저장 개수를 신중히 설정해야 한다.
  • 블록 생성
    • 시계열은 시간 순으로 인덱싱되는 숫자 데이터 포인트의 시퀀스로 정의한다.
    • 프로메테우스 데이터 포인트는 일정한 시간 간격으로 수집된다.
    • 이 데이터를 그래픽 형식으로 나타낼 때 x축은 시간이 되고 y축은 데이터 값이 된다.
    • 메모리에 수집된 샘플은 기본 두 시간 단위로 디스크로 플러시되고 블록이 생성된다.
  • 블록 병합
    • 크기가 작은 파일과 데이터가 다수 존재하면 모든 파일에 대한 인덱스를 만들고 검색해야 하기 때문에 조회 속도가 느려진다.
    • 반면에 파일 크기가 너무 크면 효율성이 떨어진다.
    • 파일 크기가 1GB인데 검색 조건에 필요한 데이터의 크기가 1KB라면 1KB를 조회하기 위해서 메모리에 1GB의 데이터를 로딩해야 한다.
    • 이로 인해 불필요한 IO가 발생한다.
    • --storage.tsdb.min-block-duration 옵션이 하나의 블록에 저장되는 데이터의 시간을 의미한다.
      • 기본적으로 2h인데 하나의 블록 디렉토리에 2시간 동안의 데이터가 저장되는 것을 의미한다.
    • --storage.tsdb.max-block-duration 옵션은 하나의 블록에 최대로 저장할 수 있는 데이터의 시간을 의미한다.
      • 기본값은 --storage.tsdb.retention.time (유지율을 설정하는 옵션)의 10%
      • 기본적으로 하나의 블록에는 3개의 블록이 병합된다.
      • --storage.tsdb.min-block-duration이 2h라면 두 시간 단위의 레벨 1블록이 만들어지고 3개의 블록이 만들어지는 순간 레벨 2블록으로 병합된다. 실제로는 하나의 블록이 6h의 데이터를 저장한다.
  • 프로메테우스 로컬 스토리지
    • 프로메테우스에서 데이터를 저장하는 표준 방법
  • 데이터 흐름
    • 메모리에 저장: 최신 데이터 배치는 최대 두 시간동안 메모리에 보관
      • 여기에는 두 시간 동안 수집되는 하나 이상의 데이터 청크를 포함한다.
      • 이 방법은 디스크 IO를 절반 이상 크게 줄인다.
      • LRU 알고리즘을 사용하기 때문에 가장 최근의 데이터는 메모리에 상주를 해서 쿼리 속도가 빨라지고 데이터 청크가 메모리에 생성되므로 반복적인 디스크 쓰기를 방지한다.
    • 로그 선행 기입
      • 메모리에 있는 데이터는 프로세스가 비정상적으로 종료되면 손실될 수 있다.
      • 이를 방지하기 위해 디스크의 로그 선행 기입(write-ahead logging - WAL)은 메모리 내 데이터의 상태를 유지함으로써 프로메테우스가 어떤 이유로든 충돌하거나 재시작하면 이를 재생시킨다.
      • 프로메테우스 운영 시 장애로 인해 메트릭이 유실되는 경우가 자주 발생한다.
    • 디스크
      • 두 시간이 지나면 청크가 디스크에 기록되며 이러한 청크는 불변의 형태
      • 데이터를 삭제하는 것은 가능하며 삭제 시에는 삭제 표시 파일이 생성된다.

프로메테우스 쿠버네티스 구성

• 설치 방식
  • 오퍼레이터를 이용하는 방식
  • 헬름 차트를 이용하는 방식
• 프로메테우스 오퍼레이터를 이용한 구성
  • kube-prometheus를 다운로드: git clone https://github.com/prometheus-operator/kube-prometheus.git
    • git이 없으면 sudo apt install -y git 으로 설치
  • 모든 네임스페이스 안의 리소스 삭제

  kubectl delete all --all --all-namespaces
  kubectl delete pvc --all --all-namespaces
  kubectl delete secret --all --all-namespaces
  kubectl delete ingress --all --all-namespaces
  

  • 설치
    • kubectl create -f manifests/setup
    • kubectl create -f manifests/
  • 확인
    • kubectl get crd -n monitoring
    • kubectl get pods -n monitoring
  • 관리 화면에 접속하기 위해서 포트포워딩을 구성
    • kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090
  • alertmanager를 사용하기 위한 포트포워딩을 구성
    • kubectl --namespace monitoring port-forward svc/prometheus-k8s 9093
  • 파드 확인
    • kubectl get pods -n monitoring

if alertmanger pod가 문제있으면 vi alertmanager.yaml해서

global:
  resolve_timeout: 5m

inhibit_rules:
- equal:
  - namespace
  - alertname
  source_matchers:
  - severity = critical
  target_matchers:
  - severity =~ warning|info
- equal:
  - namespace
  - alertname
  source_matchers:
  - severity = warning
  target_matchers:
  - severity = info
- equal:
  - namespace
  source_matchers:
  - alertname = InfoInhibitor
  target_matchers:
  - severity = info

receivers:
- name: Default
- name: Watchdog
- name: Critical
- name: null

route:
  group_by:
  - namespace
  group_interval: 5m
  group_wait: 30s
  receiver: Default
  repeat_interval: 12h
  routes:
  - matchers:
    - alertname = Watchdog
    receiver: Watchdog
  - matchers:
    - alertname = InfoInhibitor
    receiver: null
  - matchers:
    - severity = critical
    receiver: Critical

# 생성한다음 Secret 덮어쓰고
kubectl -n monitoring create secret generic alertmanager-main \\
  --from-file=alertmanager.yaml=alertmanager.yaml \\
  --dry-run=client -o yaml | kubectl apply -f -
# 재시작
kubectl -n monitoring delete pod -l app.kubernetes.io/name=alertmanager

프로메테우스 오퍼레이터

• 헬름 또는 오퍼레이터를 이용해서 구성할 수 있다.
• 쿠버네티스 오퍼레이터 장점
  • 서비스 모니터 다수를 생성해서 멀티 클러스터 등의 복잡한 런타임 환경에 대응하도록 구성할 수 있다.
• 타깃 정보는 프로메테우스 컨피그 파일에서 관리한다.
  • 쿠버네티스에서는 구성 정보를 관리하기 위해서 컨피그맵을 사용한다.
  • 컨피그맵이나 별도의 파일을 이용하는 것은 수동으로 구성 파일을 변경하는 구조라서 실수할 가능성이 있기 때문에 가급적 자동화하는 것을 권장한다.
  • 프로메테우스 오퍼레이터의 서비스 모니터와 파드 모니터는 서비스와 파드의 지속적인 모니터링을 통해 자동화한다.
  • 쿠버네티스에 변경이 발생하면 자동으로 프로메테우스 타깃 정보를 변경한다.
  • 서비스 모니터는 서비스를 모니터링하고 파드 모니터는 파드를 모니터링한다.
  • 프로메테우스 오퍼레이터를 사용하면 프로메테우스 서버를 자동으로 변경하고 타깃으로부터 메트릭 수집을 자동화할 수 있다.
    • 프로메테우스 어댑터 → HPA → Deployment → 파드 ← 인그레스 ← 유저 트래픽
    • 파드는 kubeproxy가 관리하고 이를 서비스 모니터가 모니터링하고 서비스 모니터는 프로메테우스 오퍼레이터의 일부분이고 프로메테우스 컨피그 파일에 의해서 관리한다.
• 서비스 모니터 확인
  • kubectl get servicemonitor -n monitoring
• 서비스 모니터의 구성 내용 확인
  • kubectl edit servicemonitor grafana -n monitoring
• 프로메테우스 서버의 파드 명세
  • kubectl edit pod prometheus-k8s-0 -n monitoring
• 서비스 모니터 생성 순서
  • Deployment 생성

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: sample-app
    labels:
      app: sample-app
  spec:
    replicas: 1
    selector:
      matchLabels:
        app: sample-app
    template:
      metadata:
        labels:
          app: sample-app
      spec:
        containers:
        - name: metrics-provider
          image: luxas/autoscale-demo:v0.1.2
          ports:
          - name: http
            containerPort: 8080
  

  • Service 생성

  apiVersion: v1
  kind: Service
  metadata:
    name: sample-app
    labels:
      app: sample-app
  spec:
    selector:
      app: sample-app
    ports:
      - name: http
        protocol: TCP
        port: 80
        targetPort: 8080
    type: ClusterIP
  

  • Service Monitor 생성

  apiVersion: monitoring.coreos.com/v1
  kind: ServiceMonitor
  metadata:
    name: sample-app
    labels:
      app: sample-app
  spec:
    selector:
      matchLabels:
  	    app: sample-app
    endpoints:
    - port: http
  

  • 리소스 생성
    • kubectl apply -f 디플로이먼트파일경로 -n monitoring
    • kubectl apply -f 서비스파일경로 -n monitoring
    • kubectl apply -f 서비스모니터링파일경로 -n monitoring
• 헬름으로 프로메테우스 설치
  • kubectl create namespace monitoring
  • helm install prom --namespace monitoring stable/prometheus-operator
  • 포트포워딩: kubectl port-forward svc/prom-prometheus 9090:9090 --namespace monitoring