뭉게구름 엔지니어 되는 과정

이전 글에서 Thanos 사용하여 Prometheus가 수집한 데이터를 s3 버킷으로 백업을 시켯습니다.[https://ksh-cloud.tistory.com/184](Prometheus 가 수집한 메트릭 장기간 보관하기 — s3, Thanos)그런데, 이 백업 시킨 과거의 데이터는 그냥 쿼리를 해서 사용을 할 수가 없습니다.이러한 문제를 해결하기 위해, 아래 과정을 거칩니다.Thanos Store Gateway가 S3 블록을 읽어들이도록 설정Querier가 Store Gateway(+Sidecar) 를 “store API”로 붙도록 설정Grafana 데이터 소스를 Querier 로 교체Thanos Store Gateway 란?🎯 “과거 데이터를 다시 쿼리하기 위한 리더(reader)”Thanos St..

Prometheus로 수집한 데이터를 s3로 전송시키려면 Thanos 라는 사이드카를 사용해야 합니다.저는 kube-prometheus-stack Helm 차트를 사용해서 설치를 했기 때문에,Thanos 사이드카를 사용하기 위해 values.yaml 파일에서 내용을 수정해주도록 하겠습니다.사전 준비먼저 prometheus와 연결 시킬 pv가 필요하기 때문에 저는 EKS 클러스터에 ebs-csi-driver를 추가하여 스토리지 클래스를 생성해주었습니다.Prometheus가 수집한 데이터를 저장하기 위한 s3 버킷 생성설정Thanos 사이드카를 포함하도록 values.yaml 설정 변경prometheus: prometheusSpec: disableCompaction: true storage..

Tempo로 서비스 간 호출 관계(Service Graph)를 시각화 하려면 단순히 Tempo 하나만 설치하면 끝이 아닙니다.Trace → Metric 변환 → Grafana 시각화 의 전체 파이프라인을 이해해야 합니다.아키텍처를 살펴보면 아래와 같습니다.Tempo가 하는 일Tempo는 Trace 저장소 입니다.각 서비스(ex: API 서버, 프론트 등) 에서 발생한 Trace / Span 데이터를 OLTP 포맷으로 받아 저장합니다.Trace = 한 요청의 전체 호출 흐름 (예: Front → API → DB)Span = 각각의 단계 (예: API → DB 호출)Tempo는 이 데이터들을 시계열로 저장하고,Grafana에서 TraceQL로 검색하거나 트리뷰로 볼 수 있습니다.👉 이것이 “분산 트레이싱..

이전 글에서 분산 트레이싱 을 확인하기 위해 OpenTelemetry, Tempo 를 사용해서 구성을 했었습니다.그런데 샘플링 비율을 10%로 설정을 해서 Trace 를 확인하다 보니, 실제로 제가 원하는 Trace 가 보이질 않아서 방법을 찾아보았더니, OpenTelemetry-Collector 에서 원하는 정보는 무조건 Trace 가 찍히도록 하는게 있어서 적용 해보았습니다.이제 실제로 제가 했던 적용 했던 내용을 설명드리겠습니다.원하는 Trace 조건저 같은 경우, 아래와 같은 경우 무조건 Trace가 찍히도록 설정하였습니다.ERROR400, 500 번대 ERROR 발생11초 이상 걸린 작업개발자의 도움 없이 분산 Trace 추적:OpenTelemetry Auto-Instrumentation과 Te..

분산 트레이싱이 필요해진 계기일을 하다보니, K8s 클러스터에서 파드끼리 통신도 하고, 파드 Kafka, SQS에서 message를 받아서 처리하기도 하는데, 실제로 어디서 지연이 발생했는지 파악하기 힘들어서 분산 트레이싱을 통해 원인 파악이 필요하게 되었습니다.아키텍처주요 컴포넌트들을 소개 하자면,OpenTelemetry OperatorKubernetes Operator로서, Collector와 auto-instrumentation(자동 계측)을 관리 합니다.이는 Custom Resource(CRD)를 통해 다양한 언어(Java, Python, Go, Node.js, .NET 등)에 자동 계측을 주입할 수 있습니다.현재 아키텍처에서는 Instrumentation CRD를 이용해 계측 설정을 정의하고,..

기본적으로 Alertmanager는 기본적으로 Google-chat으로 알림을 보낼 수 없습니다.그러나 현재 회사에서 Google-chat을 사용하고 있어서, Alertmanager에서 발생하는 alert 페이로드를 받아서 설정된 Google-chat 웹훅 엔드포인트로 메시지를 전달해주는 애플리케이션을 생성하였습니다.이제 제가 했던 방법을 설명드리겠습니다.사전 준비k8s 클러스터kube-prometheus-stack 설치Google-chat 스페이스의 webhook 주소1. 코드 clone먼저 calert git clone 해줍니다.git clone https://github.com/mr-karan/calert.git2. go build 실행clone한 디렉터리로 이동 한 후 go build 명령어 실행..

AWS ALB와 istio의 ingressgateway와 연결해서 사용할 수 있도록 해주겠습니다.방법은 간단합니다. 저 같은 경우에는 istio-ingressgateway를 helm 차트에서 설치를 해주었습니다.helm repo add istio-official https://istio-release.storage.googleapis.com/chartshelm install my-gateway istio-official/gateway -f values.yaml다만, values.yaml 에서 서비스 타입을 기본 LoadBalancer가 아닌 ClusterIP로 설정을 해주었습니다.values.yaml--- service: # Type of service. Set to "None" to disabl..

Istio는 수 많은 파드와 파드 사이의 트래픽을 관찰 할 수 있는 서비스 메쉬 툴 입니다.https://istio.io/latest/docs/setup/install/helm/https://kiali.io/docs/installation/installation-guide/install-with-helm/Helm 설치 (Mac 사용자)brew install helmhelm 저장소 구성helm repo add istio-official https://istio-release.storage.googleapis.com/charts helm repo updateistio-base 설치helm install my-base istio-official/base --version 1.26.0istiod 설치helm i..

이번엔 트래픽을 조절하면서 Canary 배포를 해보겠습니다.왜 Canary 배포 + 헤더 기반 트래픽 분기를 도입했는가?기존 방식 (RollingUpdate)의 한계기존 배포 방식(RollingUpdate)은 새 버전의 파드를 조금씩 올리면서 기존 파드를 내림이 과정에서 사용자가 기존 파드에 연결되어 작업 중이면, 세션 끊김/진행 중인 요청 실패/예상치 못한 오류가 발생할 수 있음Canary 배포 전략 도입이러한 문제를 최소화하기 위해, 새 버전의 파드를 일부 트래픽에만 점진적으로 적용초기에 적은 비율만 새 버전으로 넘기고, 문제가 없는지 충분히 관찰→ 장애/버그가 발생해도 전체 서비스에는 영향이 최소화헤더 기반 트래픽 분기 활용추가로, 트래픽에 특정 조건(예: 헤더)을 걸어내부 테스트, 운영자, 베타 ..

Prometheus - Grafana 설치했던 링크2024.11.15 - [Monitoring] - Prometheus - Grafana 설치 (Helm 차트) Prometheus - Grafana 설치 (Helm 차트)이번에는 Helm 을 사용하여 Prometheus와 Grafana를 설치해보도록 하겠습니다. https://artifacthub.io/먼저 helm 차트 홈페이지에 들어가서 kube-prometheus-stack 검색 해줍니다. Helm repo 추가를 해줍니다.# helm reksh-cloud.tistory.com  앞선 링크의 글에선, Prometheus와 Grafana를 설치해보았습니다. 이제 어떻게 활용이 되는지 알아보도록 하겠습니다. 구성은 아래의 이미지와 같이 할 예정 입니다...