프로메테우스

헬름으로 프로메테우스 설치

• 저장소 추가(프로메테우스는 stable 저장소나 bitnami 저장소에 존재하지 않는다.)
  • helm repo add 저장소이름 URL
    • helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
  • helm repo update
  • helm repo list
• 네임스페이스 추가(프로메테우스는 따로 분리된 네임스페이스에 설치하는 것이 일반적이다.)
  • kubectl create namespace monitoring
• Install
  • helm install prometheus prometheus-community/prometheus --namespace monitoring
• 설치
  • helm 목록 확인: helm list --namespace monitoring
  • 파드 확인: kubectl get pods -n monitoring
    • 파드 설치가 제대로 되지 않는 경우
      • 리소스 부족 발생
        • 확인: kubectl describe pod 파드이름 -n monitoring
        • 0/3 nodes are available 메시지가 보이면 리소스 부족이다. 클러스터 노드 스펙을 확장하거나 노드를 추가할 수 있고 values.yaml 파일에서 resources 값을 줄여도 된다.
        • values.yaml를 수정하는 경우
          • helm show values prometheus-community/prometheus > values.yaml
          • helm install prometheus prometheus-community/prometheus -f values.yaml -n monitoring
      • PVC 문제
        • PVC가 생성되지 않으면 Pod가 제대로 생성되지 않을 수 있다.
        • 확인: kubectl get pvc -n monitoring
        • PVC가 pending인 상태에 있으면 스토리지 클래스가 없거나 바인딩 불가 상태
        • 클래스 확인: kubectl get sc
          • 클래스가 없다면 hostPath, nfs, local-path-provisioner와 같은 Storage를 만들어주거나 Helm을 설치할 때 PVC를 사용하지 못하도록 설정

          helm install prometheus prometheus-community/prometheus \\
            --namespace monitoring \\
            --set server.persistentVolume.enabled=false \\
            --set alertmanager.persistentVolume.enabled=false \\
            --set pushgateway.persistentVolume.enabled=false
          

          • local-path-provisioner 생성
            • kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
          • local-path-provisioner 확인
            • kubectl get pods -n local-path-storage
            • kubectl get storageclass
          • 이전에 만들어진 것이 있으면 삭제: helm uninstall prometheus -n monitoring
          • 재설치

          helm install prometheus prometheus-community/prometheus \\
            --namespace monitoring \\
            --set server.persistentVolume.enabled=true \\
            --set alertmanager.persistentVolume.enabled=true \\
            --set server.persistentVolume.storageClass="local-path" \\
            --set alertmanager.persistentVolume.storageClass="local-path"
          

      • 네임스페이스 리소스 제한 문제
        • kubectl describe quota -n monitoring
• 포트포워딩
  • prometheus server가 ClusterIP로 설정되어 있어서 외부에서 접속이 안된다.
  • kubectl port-forward -n monitoring deploy/prometheus-server 9090:9090

Prometheus + Grafana + AlertManager를 한 번에 설치

helm uninstall prometheus -n monitoring
kubectl delete pvc --all -n monitoring

• PVC 스토리지 클래스를 기본값으로 설정
  • kubectl get storageclass 으로 클래스 이름 확인 (local-path)
  • kubectl patch storageclass 클래스이름 -p '{"metadata": {"annotation":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
    • kubectl patch storageclass local-path -p '{"metadata": {"annotation":{"storageclass.kubernetes.io/is-d efault-class":"true"}}}'
• All in One 패키지도 stable 저장소에 없어서 저장소를 추가해줘야 한다.
  • helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
  • helm repo update
• PVC를 위한 클래스 추가(local-path를 기본값으로 설정)
• namespace 추가(monitoring)
• 설치
  • helm install 이름 헬름차트 -n 네임스페이스
  • helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring
• 확인
  • helm list -n monitoring
  • kubectl get pods -n monitoring
  • kubectl get svc -n monitoring
• grafana 포트 포워딩 (3000번으로 포트 포워딩)
  • kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80
  • ID는 admin이고 비밀번호는 prom-operator
• Prometheus UI 포트포워딩(9090 번으로 포트 포워딩)
  • kubectl port-forward -n monitoring svc/monitoring-kube-prometheus-prometheus 9090:9090
• Grafana의 Service Type을 변경해서 외부에서 접속이 가능하도록 설정
  • values.yaml 파일을 추출
    • helm show values prometheus-community/kube-prometheus-stack > values.yaml
  • values.yaml 파일을 열어서 grafana의 service type을 수정하고 포트 정보를 수정
  • 수정한 내용 적용
    • helm upgrade monitoring prometheus-community/kube-prometheus-stack -n monitoring -f values.yaml
• Prometheus 의 Service Type을 변경해서 외부에서 UI에 접근하도록 설정
  • values.yaml 파일을 열어서 Pprometheus의 service type을 수정하고 포트 정보를 수정
  • 수정한 내용 적용
    • helm upgrade monitoring prometheus-community/kube-prometheus-stack -n monitoring -f values.yaml
• 운영환경이라면 ServiceType은 LoadBalancer가 될 것

테스트

• namespace 생성

kubectl create namespace custom-metrics

• 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:
      - image: luxas/autoscale-demo:v0.1.2
        name: metrics-provider
        ports:
        - name: http
          containerPort: 8080

• Service

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

• ServiceMonitor

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

• HPA(일반 metric을 이용한 HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: sample-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sample-app
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

• HPA(프로메테우스 metric을 이용한 HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: sample-app-custom
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: prometheus-server
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: External
    external:
      metric:
        name: http_requests_per_second
      target:
        type: Value
        value: "100"

• HPA(프로메테우스 metric & CPU와 Memory를 이용한 HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: sample-app-custom-basic
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: prometheus-server
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target: 
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target: 
        type: Utilization
        averageUtilization: 75
  - type: External
    external:
      name: http_requests_per_second
      target: 
        type: Value
        value: 50

운영 아키텍쳐

• 샤딩(Shading) 아키텍쳐
  • 샤딩:대규모의 데이터를 여러 조각(shard)으로 나누어 분산 저장/처리하는 방법을 의미
  • 프로메테우스 구성을 위한 기본적인 가이드라인은 높은 카디널리티 메트릭 생성을 피하는 것 과 샤딩을 구성하는 것
  • 샤딩을 구성하는 방법은 수직 샤딩 과 수평 샤딩이 있음
  • 수직 샤딩은 프로메테우스 서버가 기준이고 수평 샤딩은 샤드를 기준으로 메트릭을 수집
    • 수직 샤딩
      • 타겟1 <-> 프로메테우스 서버1 타겟2 <-> 프로메테우스 서버2
    • 수평 샤딩
      • 타겟1 ---- 샤드1 타겟1 ---- 샤드2 타겟1 ---- 샤드3
  • 수직 샤딩
    • 스크래핑 작업을 논리 그룹으로 분할 한 후 그룹을 다른 프로메테우스 인스턴스에 할당하는 것
    • 중앙에서 프로메테우스를 통제하지 않는 경우 수직으로 샤딩하는 것이 일반적입니다.
    • 논리 그룹은 아키텍쳐(프론트엔드, 백엔드, 데이터베이스), 내부 조직별, 팀별을 기준으로 함
    • 수직 샤딩인 경우는 여러 프로메테우스 서버가 동일한 서비스의 메트릭을 수집하지는 않습니다.
    • 수직 샤딩을 구현하기 위해서는 서비스의 분리가 명확해야 합니다.
  • 수평 샤딩
    • 하나의 프로메테우스 서버가 여러 인스턴스를 갖는 것을 의미하는데 각 인스턴스는 주어진 작업에 대한 타깃 하위 세트를 스크래핑
    • 하나의 데이터 섹터 안에 여러 개의 스크래핑 타깃 작업이 있는 경우 논리적으로 분리할 수 없기 때문에 동일한 작업을 여러 프로메테우스 서버에 분산해서 수평으로 분할하는 것
  • 대규모 환경에서는 수평 샤딩이 수직 샤딩에 비해서 유연하게 확장이 가능
    • 수평 샤딩은 구성이 복잡해서 관리가 어렵다는 단점이 있음
• Federation 아키텍쳐
  • 프로메테우스 서버가 다수 인 경우 특정 메트릭을 쿼리할 서버를 파악하는 것과 더불어서 여러 데이터 센터에서 여러 인스턴스의 데이터를 집계하는 것이 어려움
  • Federation 아키텍쳐는 계층적 연합 방식
  • 이 방식을 이용하면 하위 레벨 인스턴스의 메트릭을 좀 더 포괄적인 시계열로 집계할 수 있습니다.
    • 함께 알아볼 교차 서비스 패턴을 사용하면 페더레이션의 동일한 레벨의 인스턴스에서 일부 메트릭을 선택해 레코딩 과 알람 규칙을 적용할 수 있습니다.
  • 상위 프로메테우스 글로벌을 배치하고 그 하위에 프로메테우스 서비스들이 배치되는 구조입니다.
    • 각각의 프로메테우스 서비스들이 메트릭을 측정합니다.
  • 교차 서비스
    • 이 구조는 한 서비스의 프로메테우스 서버에서 다른 서비스의 프로메테우스 서버가 선택한 데이터를 스크랩 하도록 구성해서 단일 서버 내에서 두 데이터 셋에 대한 경고와 쿼리를 가능하는 것

타노스 운영

• 아키텍쳐
  • 프로메테우스를 기술적으로 평가하면 시계열 데이터베이스를 포함하고 있으며 다양한 API를 서비스로 제공하는 애플리케이션으로 구성되어 있는 것
  • 프로메테우스는 클러스터링을 위해 만들어진 것 이 아니고 무엇보다도 안정성 과 성능을 목표로 합니다.
    • 이러한 디자인 선택이 프로메테우스가 성공한 이유인데 그 덕분에 소수의 타깃을 처리하는 간단한 배포에서 초당 수백만 건의 샘플을 처리하는 거대한 인스턴스까지 확장할 수 있었지만 문제점도 가지고 있습니다.
  • 프로메테우스 확장을 시작하면 그라파나는 동일한 대시보드 패널에 여러 데이터 소스를 추가할 수 있지만 여러 팀이 서로 다른 요구 사항을 제시하면 유지관리가 어려워집니다.
  • 프로메테우스는 클러스터링을 지원하지 않고 로컬 스토리지의 한계로 인해서 데이터를 장기관 보관하는데 적합하지 않습니다.
  • 프로메테우스는 CNCF에서 중요한 프로젝트이고 다양한 오픈소스와 함께 프로메테우스 생태계를 구축해 나가며 클라우드 네이티브에서 중요한 역할을 수행
    • 기존에는 Telegraph 와 InfluxDB를 사용해서 메트릭을 관리했지만 지금은 프로메테우스 기반으로 메트릭을 관리하는 추세입니다.
    • 프로메테우스는 기본적으로 자체 TSDB를 사용해 로컬 메트릭 스토리지 관리 작업을 수행
    • 스토리지는 프로메테우스 인스턴스에서 로컬로 사용 가능한 디스크 공간의 양에 의해 제한되며 수 년에 이르는 대규모 보관 기간이나 그 양을 초과하는 대용량 데이터 볼륨에는 적합하지 않음
    • 시계열을 위한 프로메테우스의 기본 제공하는 스토리지 솔루션은 단순이 로컬 스토리지
    • 이는 이해하기 쉽고 관리하기가 쉬우며 단일 디렉토리에 데이터베이스가 있기 때문에 백업, 복원 또는 필요한 경우 파기하기 용이
  • 로컬 스토리지 솔루션의 단점
    • 내구성 부재: 컨테이너 오케스트레이션 배포에서 영구 볼륨을 사용하지 않을 경우 컨테이너가 다시 스케쥴링 될 때 이전 데이터가 삭제되고 현재 데이터가 새로 시작되어 수집된 데이터가 삭제됨
  • 수평적 확장 불가
    • 로컬 스토리지를 사용하면 데이터 셋의 크기가 인스턴스에서 사용할 수 있는 디스크 공간 크기이하 이어야 함
    • 로컬 스토리지가 올바른 메트릭 기준 과 카디널리티 제어, 장기 보관을 위해 설계되지 않음
• 타노스 도입의 장점
  • 글로벌 뷰를 제공: 반환된 시계열을 집계하고 중복을 제거하면서 동일한 위치에서 모든 프로메테우스 인스턴스를 쿼리
  • 다운 샘플링: 수개월 또는 수년간의 데이터를 쿼리할 때 샘플이 전체 해상도로 나오면 문제가 되므로 다운 샘플링 된 데이터를 자동으로 생성함으로써 오랜 기간에 걸치 데이터를 쿼리하는 것이 가능
  • 규칙: 다른 프로메테우스 샤드의 메트릭을 혼합하는 글로벌 알람 규칙 과 레코딩 규칙을 생성할 수 있음
  • 장기 보관: 로컬 스토리지 대신에 객체 스토리지를 활용해서 스토리지의 내구성, 신뢰성, 확장성 문제를 모니터링 스택 외부에 위임
• 대규모 운영환경에서는 타노스를 같이 사용