Kubernetes에서 가시성 사례 구현
- DAY2 16:20-17:00 KST
- Youtube link
기존 모니터링 방식과 배경
-
Verda 라는 라인용 프라이빗 클라우드 서비스를 이용함. 쿠버, ES 서비스 및 오프젝트 스토리지 사용하고 있음.
-
애플리케이션 팀이 앱을 배포하기 위해 쿠버 클러스터에 배포하고자 함
- -> 모니터링에 필요한 요소가 몇가지 있는데 문제점이 있었음.
-
log sender 와 프로메테우스가 충분하지 않았음
-
컨테이너 로그를 수집하기 위해 빌트인 로그 센더는 fluendt 로 보내고 ES 로 보내는데 설정 변경이 안됨
-
프로메테우스 와 그라파나를 자체 호스팅하는 문제. 애플리케이션팀에 운영 비용이 발생
- (ex. 6개월 메트릭을 저장하면 스토리지를 장기간 저장해야하는 문제)
-
하나의 그라파나 대시보드에서 모든 팀을 서포트해야하는 문제.
-
ELK 스택을 셀프 호스팅하는데 애플리케이션이 많으므로 ELK 전문가가 필요했음.
-
데이터 관찰을 통해 문제의 근본을 찾고 더 나은 디버깅 제공을 경험하는 것이 목표.
-
모두 동일 도구, 대시보드를 사용하는것. 모든 프로젝트에서 공유 가능한 그라파나 인스턴스 제공. 프로젝트마다 다른 데이터 소스가 있는 경우 그라파나를 통해 대시보드를 만들 수 있음.
-
애플리케이션 지표와 경험을 공유할 수 있음.
멀티테넌시 지원.
-
다른 프로젝트에 속한 여러 클러스터에서 데이터를 수집.
-
사용자마다 서로 다른 프로젝트에 대해 접근 권한을 관리
- -> 자기가 속한 프로젝트 내용만 볼 수 있음.
-
클러스터에 Promtail 데몬 셋을 설치하여 클러스터에 격리된 로그에 쿼리
-
멀티테넌시를 위해 프롬테일을 통해 로그 키에 보낼 테넌트 키를 받아 쿼리
-
프로메테우스 고가용성 및 장기간 저장을 위해 오픈소스 프로젝트인 Thanos 를 사용. 다운샘플링 기능을 이용
-
모든 앱 서비스에 대해 가용성을 알기 위해 모든 클러스터 메트릭에 대해 글로벌 대시보드를 사용. -> 글로벌 타노스를 설정.
트레이싱 백엔드 아키텍처
-
스토리지 백엔드 사용하고 데이터 사전처리, 앱의 트레이싱 데이터가 open telemetry collector 로 전송 -> 프로젝트별 토픽으로 전송 -> 멀티 테넌시를 위한 키를 이용해 각 그라파타 스토리지로 이동.
-
각 쿠버 클러스터에 데몬 셋을 배포하고
-
로드밸런서에 데이터 수식되면 open telemetry collector 에 수신되고 데이터 파이프라인을 통과,
-
모든 요청이 observability cluster 내 open telemetry collector 를 통과하므로 통합 대시보드를 만들 수 있게 됨.
-
데이터 소스로는 프로메테우스, 그라파나 로키, ES 를 주로 사용
-
git, Argo CD 를 이용해 클러스터에 애플리케이션 배포.
유즈케이스 첫번째 사례
- alert -> metrics 확인 -> 로그 검사 -> 로그 메트릭 쿼리를 통해 경과시간 확인.
- 컨테이너에서 slack 으로 alert 를 보내는데 계속 확인이 안되어 확인하였을 때 프론트엔드에서 문제가 발생한 것을 확인함. 컨테이너 내부에서 cpu mem 사용량을 확인.
- 메트릭 쿼리에선 특정 시간에 피크가 발생한 것을 시각화로 확인 -> 쿼리 자체에 오류가 확인됨
두번째 사례
- 각 프로젝트에 제공하고 있는 컨트롤러 대시보드가 있는데, 여기서 QPS 지연시간을 확인. 특정 시점에 에러율이 급증한 것을 확인.
- LogQL 을 필터링하여 에러 로그를 찾고 상세 내역 확인. 앱 및 Trace ID 확인.TraceView에서 에러의 스택 트레이스 체크하여 에러 트래킹.
