Istio Metric을 Prometheus로 수집하기: ServiceMonitor/PodMonitor 활용

안녕하세요. J4J입니다.

 

이번 포스팅은 istio metric을 prometheus로 수집하는 방법에 대해 적어보는 시간을 가져보려고 합니다.

 

 

 

관련 글

 

Kubernetes Service Mesh 구축 가이드: Istio에 대한 이해와 Istio Operator 설치 방법

Kubernetes Service Mesh 구축 가이드: Istio에 대한 이해와 Istio Operator 설치 방법

 

Kubernetes 모니터링 구축: Helm으로 kube-prometheus-stack 설치하기 (Docker Desktop)

Kubernetes 모니터링 구축: Helm으로 kube-prometheus-stack 설치하기 (Docker Desktop)

 

Grafana Alert Rule을 활용한 Slack 알림 설정 가이드

Grafana Alert Rule을 활용한 Slack 알림 설정 가이드

 

 

반응형

 

 

Istio Metric을 수집하는 이유

 

istio를 이용한 서비스 메시 환경을 구성하게 된다면 istiod/envoy sidecar 등을 통해 자체적으로 서비스 간 트래픽에 대한 metric 정보들이 수집 됩니다.

 

그리고 이런 metric 정보들에는 다음과 같은 것들이 존재합니다.

 

• 서비스 간 전체 요청 수
• 서비스 요청 지연 시간
• TCP 연결 수
• TCP 발신/수신 크기
• 등등...

 

 

 

이와 같은 metric 정보는 유용하게 활용될 여지가 있습니다.

 

대표적으로 prometheus가 수집한 istio metric 정보들을 grafana가 활용할 수 있게 되고, 이 정보를 토대로 서비스 간 트래픽 흐름의 상태를 나타내는 대시보드를 구성할 수 있습니다.

 

또한 grafana에 대시보드를 구성할 수 있다면 알림도 설정할 수 있습니다.

 

요청 지연 시간이 계속 증가하고 있거나, 요청에 대한 응답이 올바르지 않게 처리되는 경우를 조기에 감지하여 알림으로 전달받아 장애에 대한 신속 대응이 가능하도록 도와줍니다.

 

 

 

수집된 metric 정보는 kiali와 같은 서비스에서도 활용될 수 있습니다.

 

kiali는 서비스 메시 간 트래픽 흐름을 그래프 형태로 시각화하여 제공하며 istio의 설정 적용 사항들을 관리할 수 있는 기능들이 제공됩니다. (추후 정리 예정입니다.)

 

istio는 자체적으로 metric을 관리하지 않기 때문에 kiali를 사용하기 위해서는 istio 설정에 의해 생성되는 metric 정보를 관리하는 곳이 필요합니다.

 

그래서 kiali와 연결되는 곳 또한 가장 대표적인 곳이 prometheus가 될 수 있습니다.

 

결국 prometheus에 의해 관리되는 metric 정보를 kiali와 같은 서비스에서도 활용하면서 서비스 간 트래픽의 흐름을 더 쉽고 편리하게 확인할 수 있는 기능들이 제공될 수 있습니다.

 

 

 

 

Istio Metric 수집 설정 방법 비교

 

istio metric을 수집하기 위해서는 여러 가지 방식이 존재합니다.

 

• service monitor / pod monitor를 설정하여 istiod/envoy sidecar 등의 exporter를 이용한 metric scrape
• prometheus 내부 설정을 적용하여 metric scrape

 

 

 

두 방식에 대해서는 각자의 장단점이 명확히 존재합니다.

 

먼저 service monitor / pod monitor 설정을 해야 하는 경우 다음과 같은 장단점이 확인될 수 있습니다.

[ 장점 ]

• svc / pod label 기반으로 자동 관리 방식을 제공
• prometheus 설정과 별개로 관리 가능
• 원하는 서비스 별 유연한 관리를 제공

 

[ 단점 ]

• prometheus operator 기반의 설정이 적용되어 있어야 함
• service monitor / pod monitor를 사용할 수 있는 환경이 구성되어야 함

 

 

 

반대로 prometheus 내부 설정으로 적용하는 경우 다음과 같은 장단점이 확인될 수 있습니다.

 

[ 장점 ]

• service monitor / pod monitor 등의 추가적인 CRD 들에 대한 이해가 필요하지 않음
• prometheus 설정 내부에서 간편하게 설정 가능

 

[ 단점 ]

• 설정이 변경되는 경우 prometheus 재 시작 등이 필수
• 서비스 별 유연한 관리가 어려움

 

 

 

이러한 장단점들을 확인할 수 있고, 개인적으로 선호하는 방식은 service monitor / pod monitor를 사용하는 것입니다.

 

왜냐하면 prometheus와 독립적인 설정을 통해 유연한 관리를 할 수 있기 때문입니다.

 

설정이 변경될 때마다 매번 재 시작을 하는 행위는 예상치 못한 장애를 발생 시킬 수 있어 다양한 조직에서 1개의 prometheus로 사용하기에는 적절치 않다고 생각합니다.

 

그래도 한 번의 설정이 이루어진 뒤 더 이상 변경이 필요하지 않다면 prometheus 내부 설정이 좋을 수 있습니다.

 

하지만 보통 운영 단계에서 유지 보수를 하는 상황이 불가피하게 발생되는데, 여러 가지 상황을 고려했을 때 유연한 관리가 될 수 있는 service monitor / pod monitor 방식이 적절하다고 보고 있습니다.

 

 

 

 

Istio Metric 수집 설정

 

위에서 얘기한 것을 토대로 service monitor / pod monitor를 이용한 설정 방법에 대해서 적어 보겠습니다.

 

service monitor / pod monitor를 이용하기 위해서는 prometheus operator 기반의 설정이 필수적입니다.

 

만약 kube-prometheus-stack을 이용하여 prometheus 사용 환경 설정이 이루어졌다면 별도 작업 없이 service monitor / pod monitor를 이용한 설정이 가능합니다.

 

하지만 그렇지 않다면 service monitor / pod monitor를 이용할 수 있는 환경 구성이 선행되어야 합니다.

 

"저의 모든 설정은 가장 상단에 남겨 둔 istio-operator / kube-prometheus-stack 을 이용한 환경 설정이 선행되어 있습니다"

 

 

 

istio 설정을 통해 수집할 수 있는 metric 들은 다음과 같이 여러 가지가 있습니다.

 

그래서 수집하고자 하는 metric 정보가 무엇인지에 따라 서로 다른 resource 설정이 이루어져야 합니다.

 

• envoy sidecar >> 서비스 간 트래픽/성능을 위한 metric 정보
• istiod >> 서비스 메시 구성에 대한 metric 정보
• ingress/egress gateway >> 외부 트래픽 진입/처리에 대한 metric 정보
• 등등...

 

 

 

먼저 공통 설정부터 해보겠습니다.

 

Istio 표준 메트릭 정보를 수집하기 위헤서는 이전 글에서 설정 했던 istio-operator의 설정 변경이 필요합니다.

Istio Standard Metrics

 

 

설정 변경은 다음과 같이 meshConfig의 defaultProviders 설정을 추가 해주시기만 하면 됩니다.

 

[ 1. istio-operator 공통 설정 변경 적용 ]

 

// istio-operator.yaml
...
spec:
  # mesh 설정
  meshConfig:
    # 기본적으로 사용될 provider 등록
    defaultProviders:
      metrics:
      - prometheus

 

 

 

[ 2. istio 재 설치 ]

 

$ istioctl install -f istio-operator.yaml

 

 

 

 

Envoy Sidecar Metric 수집 설정

 

[ 1. envoy sidecar 적용 label 확인 ]

 

먼저 envoy sidecar가 적용되어 있는 pod에 label 확인이 필요합니다.

 

sidecar 설정이 된 pod를 1개만 골라서 다음 형식으로 적용된 label을 확인해 봅니다.

 

$ kubectl get pod { pod name } -n { namespace } --show-labels

 

 

저의 경우 다음과 같은 label 들이 조회되는 것을 볼 수 있습니다.

 

• app=app-name
• pod-template-hash=b899bf656
• security.istio.io/tlsMode=istio
• service.istio.io/canonical-name=app-name
• service.istio.io/canonical-revision=latest

 

이 중 pod monitor에 수집 대상을 정하는 데 사용하고 싶은 label을 자유롭게 선택해 주시면 됩니다.

 

 

 

[ 2. istio envoy pod monitor 리소스 작성 ]

 

kube-prometheus-stack을 이용하여 설정하신 분들이라면 다음과 같이 yaml 파일을 구성할 수 있습니다.

 

// istio-envoy-pod-monitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: istio-envoy-pod-monitor
  namespace: monitoring # kube-prometheus-stack 설치할 때 사용한 namespace
  labels:
    release: kube-prometheus-stack # kube-prometheus-stack helm 설치할 때 사용한 helm name 작성
spec:
  selector:
    matchExpressions:
      - key: service.istio.io/canonical-revision # envoy sidecar에 존재하는 label 중 하나 선택
        operator: Exists # 설정한 key가 있는 경우 수집 대상
  namespaceSelector:
    any: true # 모든 namespace에 적용
  podMetricsEndpoints:
    - path: /stats/prometheus
      port: http-envoy-prom # sidecar가 사용되는 port 명 (15090 port)
      interval: 15s

 

 

 

[ 3. pod monitor 리소스 적용 ]

 

$ kubectl apply -f istio-envoy-pod-monitor.yaml

 

 

 

[ 4. 설정 확인 ]

 

pod monitor 설정이 올바르게 되었는지 확인하기 위해서는 prometheus에 접속해 봅니다.

 

{ prometheus 도메인 }/targets 경로로 이동하여 다음과 같이 pod monitor에 의한 scrape 설정 상태가 올바르게 되어 있는지 확인하면 됩니다.

 

prometheus target 경로에 envoy sidecar pod monitor 설정이 올바르게 되어 있는지 확인

 

여기까지 확인이 되었다면 대표적으로 istio_ / envoy_ 기반의 metric이 수집되고 있는 것을 확인할 수 있습니다.

 

 

 

 

Istiod Metric 수집 설정

 

[ 1. istiod 적용 label 확인 ]

 

istiod가 설치되어 있는 service에 label 확인이 필요합니다.

 

생성된 istiod들 중 svc를 1개만 골라서 다음 형식으로 적용된 label을 확인해 봅니다.

 

$ kubectl get svc { istiod svc name } -n { namespace } --show-labels

 

 

저의 경우 다음과 같은 label 들이 조회되는 것을 볼 수 있습니다.

 

• app.kubernetes.io/instance=istio
• app.kubernetes.io/managed-by=Helm
• app.kubernetes.io/name=istiod
• app.kubernetes.io/part-of=istio
• app.kubernetes.io/version=1.27.1
• app=istiod

 

이 중 service monitor에 수집 대상을 정하는 데 사용하고 싶은 label을 자유롭게 선택해 주시면 됩니다.

 

 

 

[ 2. istiod service monitor 리소스 작성 ]

 

kube-prometheus-stack을 이용하여 설정하신 분들이라면 다음과 같이 yaml 파일을 구성할 수 있습니다.

 

// istiod-service-monitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: istiod-service-monitor
  namespace: monitoring # kube-prometheus-stack 설치할 때 사용한 namespace
  labels:
    release: kube-prometheus-stack # kube-prometheus-stack helm 설치할 때 사용한 helm name 작성
spec:
  selector:
    matchLabels:
      app: istiod # istiod label 설정 (istiod svc의 label값에 app 정보 확인)
  namespaceSelector:
    matchNames:
      - istio-system # istiod 설치할 때 사용한 namespace
  endpoints:
    - path: /metrics
      port: http-monitoring # istiod 사용되는 port 명 (15014 port)
      interval: 15s

 

 

 

[ 3. service monitor 리소스 적용 ]

 

$ kubectl apply -f istiod-service-monitor.yaml

 

 

 

[ 4. 설정 확인 ]

 

service monitor 설정이 올바르게 되었는지 확인하기 위해서 동일하게 prometheus에 접속해 봅니다.

 

{ prometheus 도메인 }/targets 경로로 이동하여 다음과 같이 service monitor에 의한 scrape 설정 상태가 올바르게 되어 있는지 확인하면 됩니다.

 

prometheus target 경로에 istiod service monitor 설정이 올바르게 되어 있는지 확인

 

 

여기까지 확인이 되었다면 대표적으로 pilot_ 기반의 metric이 수집되고 있는 것을 확인할 수 있습니다.

 

 

 

 

Ingress/Egress Gateway Metric 수집 설정

 

[ 1. gateway 적용 label 확인 ]

 

gateway가 설치되어 있는 pod에 label 확인이 필요합니다.

 

gateway들을 다음 형식으로 조회하여 적용된 label을 확인해 봅니다.

 

$ kubectl get pod { gateway name } -n { namespace } --show-labels

 

 

ingress gateway를 조회해보면 다음과 같은 label 들이 조회되는 것을 볼 수 있습니다.

 

• app=istio-ingressgateway
• chart=gateways,helm.sh/chart=istio-ingress-1.27.1
• heritage=Tiller
• install.operator.istio.io/owning-resource=unknown
• istio.io/dataplane-mode=none
• istio=ingressgateway

 

이 중 pod monitor에 수집 대상을 정하는 데 사용하고 싶은 label을 자유롭게 선택해 주시면 됩니다.

 

 

 

[ 2. istio gateway pod monitor 리소스 작성 ]

 

kube-prometheus-stack을 이용하여 설정하신 분들이라면 다음과 같이 yaml 파일을 구성할 수 있습니다.

 

// istio-gateways-pod-monitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: istio-gateways-pod-monitor
  namespace: monitoring # kube-prometheus-stack 설치할 때 사용한 namespace
  labels:
    release: kube-prometheus-stack # kube-prometheus-stack helm 설치할 때 사용한 helm name 작성
spec:
  selector:
    matchExpressions:
      - key: istio
        operator: In
        values:
          - ingressgateway # ingress gateway label 설정
          # egress gateway도 사용하는 경우
          # - egressgateway # egress gateway label 설정
  namespaceSelector:
    matchNames:
      - istio-system # istio gateway 설치할 때 사용한 namespace
  podMetricsEndpoints:
    - path: /stats/prometheus
      port: http-envoy-prom # sidecar가 사용되는 port 명 (15090 port)
      interval: 15s

 

 

 

 

[ 3. pod monitor 리소스 적용 ]

 

$ kubectl apply -f istio-gateways-pod-monitor.yaml

 

 

 

[ 4. 설정 확인 ]

 

이 또한 pod monitor 설정이 올바르게 되었는지 확인하기 위해서는 prometheus에 접속해 봅니다.

 

{ prometheus 도메인 }/targets 경로로 이동하여 다음과 같이 pod monitor에 의한 scrape 설정 상태가 올바르게 되어 있는지 확인하면 됩니다.

 

prometheus target 경로에 ingress/egress pod monitor 설정이 올바르게 되어 있는지 확인

 

 

여기까지 확인이 되었다면 envoy sidecar와 동일하게 istio_ / envoy_ 기반의 metric이 수집되고 있는 것을 확인할 수 있습니다.

 

다만, 시계열 데이터는 envoy sidecar와 서로 구분되는 정보들이 수집됩니다.

 

 

 

 

 

 

 

이상으로 istio metric을 prometheus로 수집하는 방법에 대해 간단하게 알아보는 시간이었습니다.

 

읽어주셔서 감사합니다.