하얀잔디

텔레그램 장애 알림에 AI 로그 분석 붙여보기

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. 컨..

쿠버네티스로 이것저것 하다 보니 Docker 명령어를 잠깐 까먹을 뻔함.특히 Docker 환경에서 장애 상황을 확인할 때는 아래 4개 정도만 기억해두면 편함. 명령어 보는 것 질문docker ps -a컨테이너 상태뭐가 죽었지?docker inspect상세 상태/설정왜 이런 상태지?docker logs애플리케이션 로그앱에서 무슨 에러가 났지?docker eventsDocker 이벤트언제 죽고 다시 시작됐지? 장애 발생 시 대략적인 순서docker ps -a→ 죽거나 재시작하는 컨테이너 확인docker inspect → OOMKilled, Rest..

왜 했냐최근 prod 쪽 채팅 읽기 관련 캐싱 로직을 손봤음. 근데 dev 환경은 Redis 샤딩 구성이 prod랑 달라서(dev는 샤딩 안 됨) 배포했을 때 사이드 이펙트가 터질지 확신이 안 섰음. 한 번에 100% 밀어넣긴 쫄려서 트래픽 조금만 먼저 태워보려고 canary 세팅을 해봄.​​배경 파악k3s 클러스터 보니까 dev 네임스페이스에 linkerd가 이미 떠 있길래 레포를 뒤져봄. 확인해보니 linkerd 설치랑 dev 네임스페이스 linkerd.io/inject 어노테이션이 레포엔 없고, 예전에 서버에서 수동으로 kubectl apply / annotate 때려둔 흔적이었음. GitOps 안 붙은 순수 kustomize 레포라 이런 드리프트가 종종 생김. 온 김에 canary 배포 환경까지..