DevOps/Monitoring

recording rule 이란 자주 필요한 표현식이나 계산 비용이 큰 표현식을 미리 계산해서, 그 결과를 별도 시계열 셋으로 저장해 둘 수 있는 기능이다. 즉 성능과 재사용성을 높이기 위해서 사용할 수 있다. 예를 들어보자. 원하는 시계열 데이터를 만들기 위해서 5개의 시계열 데이터가 들어가고, 하나의 프롬 쿼리당 1의 리소스가 든다고 가정해 보자. -> 데이터를 요청할 때마다 5의 리소스가 들어가게 된다. 반면에 recording rule을 사용하면, 처음에 5의 리소스가 들어가게 되고, 해당 값을 저장하는 시계열 데이터가 만들어진다. -> 데이터를 요청할 때마다 1의 리소스가 들어가게 된다. 여기서 프롬 쿼리가 복잡하다면 더 많은 차이가 나타나게 된다. 물론 별도의 시계열 데이터로 저장해서, 저장 ..

프로메테우스로 지표를 수집했으면, 해당 지표를 사용하기 위해서는 PromQL을 사용해야 한다. mysql에서 query를 사용하는 것과 비슷한데, 문법과 값들이 조금씩 다르다. 하나씩 알아보자. PromQL 타입 mysql에서 int, string 같은 자료형이 있듯이 PromQL에도 guage, counter, summary, histogram 4가지의 자료형이 존재한다. 예와 함께 살펴보자. Gauge 특정 시점의 값을 표현하는 타입이고, 예시로는 cpu, 메모리 사용량의 현재 시점이 있다. 말했듯이 검색 시점에서 값들을 의미한다. Counter 현재 시점까지의 누적된 값을 표현하는 타입이고, 예시로는 gc를 수행하는데, 걸린 시간을 누적값을 가지고 있는 것을 볼 수 있다. Summary 구간 내에 ..

이제 EKS를 Terraform으로 간편하게 만들고, Prometheus와 Grafana를 적용해 보자. EKS 생성 (With Terraform) Github에서 볼 수 있고 사용 방법은 README를 보기 바란다. 시간이 약 10분 정도 걸리고, 완성된 것을 볼 수 있다. EKS 세팅 (kubectl 설치 가정) 이제 로컬에서 kubectl을 사용할 수 있도록 kubeconfig를 업데이트해줘야 한다. aws eks update-kubeconfig --region region-code --name my-cluster # 서울의 경우 ap-northeast-2 사용하면 ~/. kube로 이동하면 config파일이 업데이트된 것을 볼 수 있다. 이제 EKS를 cli로 다룰 수 있게 도와주는 eksctl을..

EC2 기반 애플리케이션의 프로메테우스 지표를 수집하고, 그라파나로 시각화해볼 예정이다. 프로메테우스, 그라파나 서버 인스턴스 생성 프로메테우스와 그라파나를 docker 컨테이너로 돌릴 예정이다. EC2 인스턴스 하나를 준비하자. 이름을 지정해준다. 이때 이름은 자동으로 Name 태그로 들어간다. 보안 그룹은 다음과 같이 해준다. 3000 포트: 그라파나 대시보드 접근 포트 9090 포트: 프로메테우스 접근 포트 (테스트가 끝나면 닫아도 됨) 8080 포트: 애플리케이션 포트 (같은 인스턴스 내에서 애플리케이션을 돌릴 예정) 22 포트: 해당 cidr은 AWS instance connect를 사용할 때 AWS 측의 IP range다. (key pair 없이 사용할 수 있음) 서버 인스턴스 설정 EC2 연..

SpringBoot 모니터링으로 개념 설명과 로컬에서 띄워본 적이 있다. 1년 반 만에 작성하게 됐는데, 회사 생활과 AWS 인프라가 우선순위가 높았다. 현재는 조금 여유로워져서 이어서 포스팅하려고 한다. 아래의 순서대로 목차를 진행할 예정이다. 1. 다양한 환경 메트릭 수집 - 단일 EC2 기반 - EKS 파드 2. Prometheus 심화 - Promql - 알람, 레코딩 - 고가용성 3. Grafana 심화 - 필요한 부분 추가할 예정 기본적으로 애플리케이션은 SpringBoot고, 각자의 환경에 맞게 구성하면 된다.