Successfully reported this slideshow.
Your SlideShare is downloading. ×

Service mesh(istio) monitoring

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 41 Ad

More Related Content

Slideshows for you (20)

Similar to Service mesh(istio) monitoring (20)

Advertisement

Recently uploaded (20)

Service mesh(istio) monitoring

  1. 1. Service Mesh(Istio) Monitoring
  2. 2. Contents Service Mesh Monitoring Istio Tracing Logging Visualizing Mixer
  3. 3. Service Mesh Service1 POD Container Sidecar Proxy Service2 POD Container Sidecar Proxy Service3 POD Container Sidecar Proxy § Microservice간 통신 및 트래픽을 제어하는 Mesh 형태의 Service Network • Microservice간 통신은 추상적인 Service Network Layer의 Proxy를 통해 수행 • 개별 Proxy는 Service Workload의 내부가 아닌 Workload와 분리된 Sidecar 형태로 구성 • Sidecar Proxy는 연결된 Workload(Container) 대신 타 Service로의 통신 및 트래픽 제어 • Sidecar Proxy간 Mesh Network를 형성 → Service Mesh Service4 POD Container Sidecar Proxy Service5 POD Container Sidecar Proxy
  4. 4. Istio TelemetryTraffic Security • mTLS (양방향 트래픽 암호화) • Auth (서비스 접근 인증) • RBAC (권한 제어) – Namespace – Service – Method • 서비스 Discovery • Load Balancing • 트래픽 라우팅 • Failure Handling • Fault Injection • HTTP/gRPC/TCP 트래픽 처리 • Monitoring (Metrics 기반) • Logging • Tracing • Telemetry 항목 시각화 • Service Topology 제공 § Service Mesh 구성 및 관리를 위한 Platform
  5. 5. Istio Data Plane Istio Control Plane Istio 컴포넌트 § Istio Control Plane : Service Mesh Controller 구성 § Mixer : Telemetry 연동 및 수집, Policy 관리 § Pilot : Envoy 제어를 통한 서비스 및 트래픽 관리 § Galley : Istio의 구성 및 설정 검증, 배포 관리 § Citadel : 보안 관리 및 트래픽 암호화(mTLS) 적용 § Istio Data Plane : Service Mesh 구성 § Envoy : 서비스 간 통신 및 트래픽 처리
  6. 6. Service Mesh 테스트용 오픈소스 Hipster Shop Microservice Demo https://github.com/GoogleCloudPlatform/microservices-demo
  7. 7. Service Mesh Architecture Cloud Z Kubernetes (ZCP) Users Internet Load Balancer Istio Control Plane Istio Data Plane Pilot Mixer Citadel Recommendation Frontend LoadGenerator Advertise ProductCatalog EmailCurrency Payment Shipping Redis-Cart Cart Checkout Ingress Gateway Galley
  8. 8. Mixer § Mixer는 Telemetry 연동 및 수집, Policy 관리하는 Istio 컴포넌트
  9. 9. Mixer Adapter § Adapter는 Istio가 Metric/Log/Trace 관리를 위한 Infra Backend에 있는 Telemetry들을 쉽게 연동하기 위한 추상적인 Interface로, Provider별 Template을 제공
  10. 10. Mixer Attribute § Attribute는 Istio의 Telemetry 연동을 위한 특정 서비스의 Request 또는 Request 환경을 명시하는 속성 정보 (특정 Request의 크기, HTTP 응답 코드, Request Source의 IP 주소 등) § 각 Attribute는 Name과 Type이 있으며, Type은 Attribute가 보유하는 데이터의 종류를 정의 request.path: xyz/abc request.size: 234 request.time: 12:34:56.789 04/17/2017 source.ip: [192 168 0 1] destination.service.name: example
  11. 11. Mixer - Attribute 관계 § Mixer는 본질적으로 Attribute 처리 시스템 § Envoy Sidecar Proxy는 모든 요청에 대해 Mixer를 호출하여 Request와 연관된 서비스 정보 및 Request 자 체를 설명하는 Attribute를 Mixer에 전달 § Attribute 정보 기반으로 Mixer는 Telemetry가 있는 다양한 Infra Backend에 대한 호출을 생성
  12. 12. Mixer Config 요소 § Mixer의 Telemetry 기능을 설정하는 3가지 요소 요소 설명 코드 적용 형태 Instance Attribute를 Adapter에 Mapping 설정 apiVersion: config.istio.io/v1alpha2 kind: instance metadata: name: requestduration namespace: istio-system spec: compiledTemplate: metric params: value: response.duration | "0ms" dimensions: destination_service: destination.service.host | "unknown" destination_version: destination.labels["version"] | "unknown" response_code: response.code | 200 monitored_resource_type: '"UNSPECIFIED"' Handler Adapter에 대한 연동 방식을 설정 apiVersion: config.istio.io/v1alpha2 kind: handler metadata: name: staticversion namespace: istio-system spec: compiledAdapter: listchecker params: providerUrl: http://white_list_registry/ blacklist: false Rule 특정 Adapter로 반영되는 되는 시기 및 Handler에 반영될 Instance를 설정 apiVersion: config.istio.io/v1alpha2 kind: rule metadata: name: promhttp namespace: istio-system spec: match: destination.service.host == "service1.ns.svc.cluster.local" && request.headers["x- user"] == "user1" actions: - handler: promhandler instances: [ requestduration ]
  13. 13. Monitoring Metric 쿼리Metric 수집 Metric 시각화 • Grafana를 사용하여 Service Mesh 트래픽 모니터링 시각화 • Istio Metric 수집 및 처리방식 을 Mixer에서 설정 • Prometheus를 사용하여 저장된 Istio Metric을 쿼리 § Service Mesh Monitoring을 위한 Istio의 Envoy Proxy Metric은 Mixer에서 수집 및 처리
  14. 14. Metric 수집 § Istio Mixer가 Service Mesh에 대한 Monitoring 설정을 통해 자동으로 Metric을 수집 할 수 있도록 설정 § Metric 수집이 끝나면 Mixer에서 관리되는 Metric을 Prometheus에 전달되어 조회 가능
  15. 15. Monitoring을 위한 Mixer 설정 1 - Instance § Instance : Envoy가 전달한 Attribute를 기반으로 생성되는 Metric Entry apiVersion: config.istio.io/v1alpha2 kind: instance metadata: name: quadruplerequestcount namespace: istio-system spec: compiledTemplate: metric params: value: "4" # Envoy에서 수신된 request 마다 4씩 값이 카운트 된다. dimensions: # outbound, client, server중 속성 값과 일치한 정보를 출력 reporter: conditional((context.reporter.kind | "inbound") == "outbound", "client", "server") source: source.workload.name | "unknown" # ~.workload.name에 속성값이 없을 경우 Unknown을 출력 destination: destination.workload.name | "unknown" message: '"quadruple the fun!"' # 모든 Instance에 Message 출력 monitored_resource_type: '"UNSPECIFIED"'
  16. 16. Monitoring을 위한 Mixer 설정 2 - Handler § Handler : Prometheus Adapter가 받은 Metric Entry Instance를 Prometheus Backend에서 처리 할 수 있 는 Prometheus 형식의 값으로 변환하는 부분을 설정 apiVersion: config.istio.io/v1alpha2 kind: handler metadata: name: quadruplehandler namespace: istio-system spec: compiledAdapter: prometheus params: metrics: - name: quadruple_request_count # Prometheus metric명 instance_name: quadruplerequestcount.instance.istio-system # Mixer instance명 kind: COUNTER label_names: # Instance에 구성된 demension 항목과 동일하게 Label 명시 - reporter - source - destination - message
  17. 17. Monitoring을 위한 Mixer 설정 3 – Rule § Rule : Mixer가 관리하는 Metric Entry Instance를 특정 Handler에서 사용할 수 있도록 설정 apiVersion: config.istio.io/v1alpha2 kind: rule metadata: name: quadrupleprom namespace: istio-system spec: actions: - handler: quadruplehandler instances: [ quadruplerequestcount ] • Adapter는 istio_ 의 String을 모든 Metric명 앞에 추가하여 Backend에 있는 Telemetry로 전달 • 쿼리 : istio_quadruple_request_count
  18. 18. Metric 쿼리 Demo (Prometheus) 2. Productcatalog 서비스의 모든 Metric Entry Instance에 대한 최근 5분 동안의 Request 비율 1. Productcatalog 서비스 버전 v1에 대한 모든 Request 수 • 쿼리 : istio_requests_total{destination_service="productcatalogservice.hipster-shop.svc.cluster.local", destination_version="v1"} • 쿼리 : rate(istio_requests_total{destination_service=~"productcatalogservice.*", response_code="200"}[5m])
  19. 19. Metric 시각화 (Grafana) § Istio Mixer에서 관리하는 Metric을 시각화하여 모니터링 할 수 있는 Dashboard를 Grafana를 통해 제공
  20. 20. Mesh Dashboard § Mesh Dashboard에서는 Service Mesh 모니터링 수행 § Service Mesh내의 각 서비스에 대한 Request, Latency, Success Rate에 대한 값을 출력
  21. 21. Service Dashboard § Service Dashboard에서는 Mesh 내의 개별 Service 대상 Request/Response에 대한 Metric 제공 § 특정 Service를 Request하는 Client Workload에 대한 Metric 제공 § Service를 제공하는 Server Workload에 대한 Metric 제공
  22. 22. Workload Dashboard § Workload Dashboard에서는 Mesh 내의 개별 Workload Request/Response에 대한 Metric 제공 § 특정 Workload로 Request하는 Inbound 서비스에 대한 Metric 제공 § Workload가 타 Workload로 Request하는 Outbound 서비스에 대한 Metric 제공
  23. 23. Logging Envoy 접근 LogLog 수집 Fluentd Logging • Fluentd 연동 및 Logging 설정• Mixer에서 Istio Log 수집 및 처리 • Envoy Proxy 접근 Log 수집 § Service Mesh Logging을 위한 Istio Mixer에서의 Log 설정 및 수집, 처리
  24. 24. Log 수집 Demo § Service Mesh에서 서비스 Request에 대한 Log를 자동으로 수집하도록 설정 • istio-telemetry POD의 mixer 컨테이너를 통한 Log 검색 • 명령어 : kubectl logs -n istio-system -l istio-mixer-type=telemetry -c mixer | grep "newlog" | grep -v '"destination":"telemetry"' | grep -v '"destination":"pilot"' | grep -v '"destination":"policy"' | grep -v '"destination":"unknown"'
  25. 25. Logging을 위한 Mixer 설정 1 - Instance § Instance : Envoy Sidecar Proxy에서 수집된 Attribute를 기반으로 생성된 Log Entry apiVersion: config.istio.io/v1alpha2 kind: instance metadata: name: newlog namespace: istio-system spec: compiledTemplate: logentry params: severity: '"warning"' # Log 레벨 timestamp: request.time # Log에 Envoy가 제공하는 Request 기반으로 시간 출력 variables: source: source.labels["app"] | source.workload.name | "unknown" user: source.user | "unknown" destination: destination.labels["app"] | destination.workload.name | "unknown" responseCode: response.code | 0 responseSize: response.size | 0 latency: response.duration | "0ms" # Log 출력에 대한 대기시간 지정 monitored_resource_type: '"UNSPECIFIED"'
  26. 26. Logging을 위한 Mixer 설정 2 - Handler § Handler : Standard I/O Adapter에 전달될 Log Entry Instance 처리 방식을 설정 apiVersion: config.istio.io/v1alpha2 kind: handler metadata: name: newloghandler namespace: istio-system spec: compiledAdapter: stdio params: severity_levels: # Logging 레벨 설정 warning: 1 outputAsJson: true # JSON 형식으로 Log행 생성
  27. 27. Logging을 위한 Mixer 설정 3 – Rule § Rule : Log Entry Instance를 Handler로 전달되도록 Mixer에 적용 apiVersion: config.istio.io/v1alpha2 kind: rule metadata: name: newlogstdio namespace: istio-system spec: match: "true" # Rule은 모든 요청에 대해 실행, 정규표현식을 사용하여 변경 가능 actions: - handler: newloghandler instances: - newlog
  28. 28. Envoy 접근 Log Demo § Envoy Proxy는 접근 Log를 kubectl logs명령으로 출력 할 수 있음 • Productcatalog 서비스 Log • 명령어 : kubectl logs -f <productcatalogservice의 POD명> -c istio-proxy
  29. 29. EFK Logging Demo § Log Entry를 Fluentd로 전달하여 EFK에서 Logging이 될 수 있도록 설정
  30. 30. Fluentd 설정 § Istio의 Mixer는 Forward 로그를 Listen하는 Fluentd 데몬과 연결할 수 있음 § Mixer가 실행중인 Fluentd 데몬에 연결하려면 Fluentd로 연동되는 Adapter 생성 및 Template 설정 kind: ConfigMap apiVersion: v1 data: forward.input.conf: |- # TCP를 통한 Message 전송 <source> type forward </source> output.conf: |- <match **> type elasticsearch log_level info include_tag_key true host elasticsearch port 9200 logstash_format true # Chunk limits 설정 buffer_chunk_limit 2M buffer_queue_limit 8 flush_interval 5s # Retry 대기시간은 5분 이하로 지정 max_retry_wait 30 # 영구적으로 Retry 수행 disable_retry_limit # 2개의 쓰레드로 처리 num_threads 2 </match> metadata: name: fluentd-es-config namespace: logging Forward 로그를 Listen하는 Fluentd 설정
  31. 31. EFK Logging 설정 apiVersion: config.istio.io/v1alpha2 kind: handler metadata: name: handler namespace: istio-system spec: compiledAdapter: fluentd params: address: "fluentd-es.logging:24224" § Logging을 위한 Mixer 설정 중 Handler의 일부 Spec을 변경
  32. 32. Tracing (Zipkin) Tracing Dashboard § Istio는 기본적으로 모든 Request에 대한 Tracing 가능한 데이터를 생성 § Zipkin을 사용하여 서비스 트래픽에 대한 Tracing 수행 가능 상세 Trace View • Tracing은 서비스 간 연동정보의 집합인 Span별로 수행 • Tracing 가능한 데이터는 서비스 Request 실행중 발생한 값이나 Istio 컴포넌트 대상으로 수집 (istio-ingressgateway, istio-mixer, istio-policy)
  33. 33. Tracing Span 상세내역
  34. 34. Tracing Dependencies
  35. 35. Zipkin API § Zipkin API를 사용하여 서비스 트래픽 Tracing 정보를 JSON 형태로 접근, 제어 가능 • 웹 브라우저에서 $Zipkin_URL/api/v2/spans?serviceName=productcatalogservice.hipster-shop 를 주소창에 입력하여 Application 목록을 JSON 형태로 출력 • Zipkin API 참고 링크 : https://zipkin.io/zipkin-api/
  36. 36. Visualizing (Kiali) Dashboard § Kiali는 Service Mesh 및 Istio 컴포넌트의 트래픽 데이터들을 Visualizing(시각화)하여 제공 Graph
  37. 37. Kiali 구성요소 1 서비스 요소(Application, Workload, Service) 목록 트래픽 Metric
  38. 38. Kiali 구성요소 2 Istio Config(Policy) 목록 Istio Config(Policy) 코드
  39. 39. Kiali API § Kiali API를 사용하여 그래프 및 기타 Metric, 상태값 등 구성 정보를 JSON 형태로 접근, 제어 가능 • 웹 브라우저에서 $KIALI_URL/kiali/api/namespaces/hipster-shop/apps를 주소창에 입력하여 Application 목록 을 JSON 형태로 출력 https://www.kiali.io/api/• Kiali API 참고 링크 :
  40. 40. Q & A
  41. 41. End Of Document (skwjdgh1@gmail.com)

×