하얀잔디

OpenTelemetry + Tempo 분산 추적 검토

검토 배경 현재 API 응답 지연 발생 시 Gateway의 request_id와 API 로그의 trace.id를 기준으로 원인 분석 중임.다만 API 내부에서 DB 조회, Redis 처리, 외부 Interface 호출 중 어느 구간에서 시간이 많이 소요되는지 확인하려면 개별 로그를 분석해야 하는 불편함 있음.이를 개선하기 위해 OpenTelemetry + Tempo 기반 분산 추적 방식 확인함. OpenTelemetry / Tempo 역할 OpenTelemetry(OTel): API, DB, Redis, 외부 HTTP 호출 등의 실행 시간과 호출 관계를 수집하는 오픈소스 도구OTel Collector: 수집된 데이터를 중간에서 필터링, 배치 처리 후 저장소로 전달하는 역할 (필수 아님)Tempo: OT..

최근 운영 중인 파일 API에서 응답 지연이 발생해 NFS 상태를 확인했다. 기존엔 0.05초 이내로 서빙되던 파일이 0.5초 넘게 걸리는 현상이 발견되었다. 확인 과정에서 NFS 서버로 들어오는 TEST_STATEID 요청이 초당 약 200~300회 반복되는 현상을 발견했다. NFS 서버 자체의 문제인지, 클라이언트가 이전 상태를 계속 확인하는 것인지 살펴봤고, 개발 환경에서 먼저 NFS 클라이언트 강제 만료(Expire)를 테스트한 뒤 운영 환경에도 적용했다.이번에 사용한 명령어와 확인 과정을 정리해 둔다.1. NFS 서버와 클라이언트 확인먼저 어느 서버가 NFS 서버이고, 어디서 마운트해 사용하고 있는지 확인했다.NFS 클라이언트(WAS)에서 실행한다.findmnt -t nfs,nfs4실제 개발 환..

1. 작업 배경서비스를 운영하다 보면 CPU나 메모리 사용률은 정상인데 실제로는 API 오류가 발생하거나 응답이 느려지는 경우가 있다.기존에는 Prometheus와 Grafana를 통해 서버 상태를 모니터링하고, 장애가 발생하면 OpenSearch에서 로그를 직접 검색해 원인을 확인했다.그런데 장애가 발생할 때마다 로그를 조회하고, 어떤 API에서 오류가 발생했는지 확인하고, 파드 상태까지 하나씩 살펴보는 과정이 생각보다 번거로웠다.그래서 장애를 자동으로 감지하고, 관련 로그와 메트릭을 AI가 분석해 원인까지 알려주는 기능을 만들어봤다. 2. 장애 감지 및 텔레그램 알림먼저 장애를 빠르게 인지하기 위해 모니터링 항목을 추가했다. Gateway 모니터링NGINX Gateway 로그를 기반으로 5xx 오류..

요즘 AIOps 관련해서 이것저것 보다가 간단하게 PoC 해봄.목표는 자동 장애조치 같은 거창한 건 아니고, Prometheus 메트릭이랑 OpenSearch 로그를 AI가 읽고 분석하게 해서 장애 확인할 때 도움받는 정도임.기존에는 장애나 성능 이슈가 생기면 Grafana에서 메트릭 확인하고, OpenSearch 들어가서 같은 시간대 로그 찾고, 다시 비교하는 식으로 봤음.이걸 조금 편하게 해보려고 자연어로 질문하면 필요한 데이터를 조회해서 정리해주는 형태로 만들어봄.예를 들면 이런 식으로 물어볼 수 있음.최근 30분 동안 API 쪽에 이상 있었는지 확인해줘15시 이후 응답시간이 느려진 원인 찾아줘CPU 올라간 시간대에 에러 로그도 같이 증가했는지 봐줘 구성은 로컬 PC에서 Python으로 간단하게 만..

Kubernetes에서 여러 Pod를 운영하다 보면 특정 Pod만 CPU가 튀거나 응답이 느려지는 경우가 있음.Pod A → 50msPod B → 60msPod C → 3초기본 Kubernetes Service는 Pod C가 느리다고 해서 자동으로 해당 Pod를 제외해주지는 않음.HPA를 사용하면 CPU 증가에 따라 Pod를 추가할 수 있지만, 느린 Pod를 직접 피하는 방식은 아님.그래서 Service Mesh를 찾아봄. Linkerd Linkerd는 Pod에 Proxy를 붙여 서비스 간 통신을 관리함.특히 Latency-aware Load Balancing을 통해 최근 응답시간이 빠른 Endpoint를 선호하도록 트래픽을 분산할 수 있음. Pod A → 50msPod B → 60msPod C → 3..

Node JS 에서 나타났던 상황이지만 Java 등 모든 WAS서버에서 나올수 있는 상황 상황 DB 커넥션 풀이 꽉 차서 API가 504 뜨고, 완전 가벼운 API도 덩달아 느려지고, SequelizeConnectionAcquireTimeoutError까지 터짐. 원인 파보니 트랜잭션 하나를 안 닫고 있었음.문제 코드이미 있으면 그거 리턴, 없으면 새로 생성 패턴에서 나왔던 실수임.const findOrCreateRoom = async (userId: string) => { const transaction = await sequelize.transaction() // 커넥션 하나 확보 try { const existing = await Room.findOne({ where: { u..

Pod별 CPU / Memory 사용량을 확인하기 위해 Kubernetes의 kubelet cAdvisor metric을 활용함. cAdvisor는 각 Node의 10250 포트를 통해 metric을 제공하고 있어서, 해당 endpoint를 Prometheus에서 조회하도록 구성함. 다만 kubelet API이기 때문에 그냥 접근하지 않고 ServiceAccount + RBAC을 구성해서 인증/권한을 설정함.Prometheus ↓RBAC 인증 ↓kubelet :10250 ↓/metrics/cadvisor ↓Pod별 CPU / Memory 이후 Prometheus에서 cAdvisor metric을 수집하고 Grafana에서 namespace, pod 기준으로 조회하도록 구성함. CPU..

운영 서버 로그를 보다 보면 Vite 관련 요청이나 /.env, /.git, /admin 같은 이상한 외부 요청이 들어오는 경우가 있음.이런 요청이 들어왔다고 무조건 서버가 공격받았다고 볼 필요는 없음. 중요한 건 무엇을 요청했는가보다 서버가 무엇을 응답했는가임.1. 외부에서 불필요한 파일이 노출되지 않는지 확인특히 아래 파일들은 외부 접근이 불가능해야 함..env.git/.git/configvite.config.jspackage.jsondocker-compose.yml/.env → 200 OK처럼 실제 파일 내용이 반환된다면 바로 확인 필요.2. 개발 서버를 운영에 그대로 노출하지 않기Vite 개발 서버나 각종 개발용 포트를 외부에 그대로 열어두지 않는 게 중요함.운영에서는 보통Vite ↓npm bui..

쿠버네티스 노드 디스크 꽉 차면 Kubelet이 DiskPressure 걸어버리고 Pod 강제 퇴출 시작함 ㄷㄷ. 당황하지 말고 아래 순서로 빠르게 원인 잡고 용량 확보하면 됨. 1. 장애 노드 및 상태 확인어느 노드가 찌들어있는지, 튕겨 나간 Pod 있는지 먼저 확인. # 1. DiskPressure 발생 노드 확인kubectl get nodes -o custom-columns=NAME:.metadata.name,DISK_PRESS:.status.conditions[?(@.type=="DiskPressure")].status# 2. Evicted 상태 Pod 목록 확인kubectl get pods -A | grep Evicted 2. Root Cause 탐색 (노드 디렉터리 스캔) 해당 노드 SSH 접..

운영 중 디스크 사용량 증가하면 아래 순서로 확인하면 됨. 1. 전체 디스크 확인 df -h / 사용률 확인함. 보통 Use%가 80~90% 이상이면 원인 확인 필요함. 2. Docker가 얼마나 사용하는지 확인 docker system df 이미지, 컨테이너, 볼륨, 빌드 캐시별 사용량 확인 가능함. 상세 확인: docker system df -v 3. Docker 내부에서 어디가 큰지 확인 sudo du -xhd1 /var/lib/docker 2>/dev/null | sort -h 주로 확인할 디렉터리:overlay2 → 이미지/컨테이너 레이어containers → 컨테이너 로그volumes → Docker Volumeimage → Docker 이미지 메타데이터 4. 컨..