Thomas의 Cloud Engineering

https://ganeshvernekar.com/blog/prometheus-tsdb-the-head-block/ Prometheus TSDB (Part 1): The Head Block | Ganesh Vernekar Walk-through on how the in-memory part of Prometheus TSDB works ganeshvernekar.com 위 블로그를 바탕으로 좀 더 이해가 될수 있도록 추가 분석한 내용을 정리한다. 프로메테우스는 자체 TSDB(TimeSeries DataBase)를 가지고 있다. DB의 기본적인 특성을 가지고 있으면서도 시계열에 특화된 구조로 되어있다. TSDB의 기본적인 구조는 다음과 같다. Sample (t,v): (timestamp, value) 이 하나..

nvidia 에서 제공하는 공식 gpu exporter인 dcgm-exporter에 대해 알아본다. DCGM 이란? DCGM은 DataCenter GPU Manager의 약자로, nvidia gpu 를 위한 종합 관리 및 모니터링 도구다. 이 도구는 데이터 센터 내의 nvidia gpu의 상태를 모니터링하고, 관리하는 데 사용된다. 여기서는 여러 기능 중 하나인 모니터링에 대해서 알아본다. DCGM 은 자체적으로 메트릭을 내보내지 않기 때문에 nvidia 이와 통신해서 메트릭을 만들어서 출력해주는 exporter를 별도로 제공하고 있다. DCGM exporter 동작방식 그림에서와 같이 dcgm exporter는 Kubelet/node-exporter/DCGM과 통신하여 메트릭을 수집한다. Service..

DevOps 에서는 개발자가 운영자가 된다. 물론 24시간 대응하는 티어그룹이 따로 있을 수는 있지만 결국에 원인을 분석해서 이슈를 수정하는 책임은 보통 개발자가 된다. 이슈가 많아지면 개발자는 고통받는다. 심지어 개발팀이 정상적인 개발업무를 수행하기 어려워진다. 보통은 온콜(oncall) 프로세스를 도입하여 당번제 처럼 돌아가면서 한두명의 개발자가 들어오는 CS나 이슈를 모두 처리하도록 하여 다른 개발자들이 개발에 집중할수 있도록 한다. 하지만, 빈번히 발생하는 이슈를 계속해서 온콜로만 대응하다가는 개발팀의 효율이 개선되지 않는다. 그러므로 운영에 있어서 자동화와 최적화는 지속적으로 이루어져야 한다. 자동화의 범위 어느정도 게으른 개발자가 되라는 얘기가 있듯이, 개발자는 항상 개선을 고민해야 한다. 그..

그 동안 여러 그룹 스터디를 해보면서 효율적인 방법에는 어떤 것들이 있는지 개인적인 의견을 얘기해보고자 한다. 스터디 빈도나 시간 등은 별로 상관이 없는거 같고, 스터디 진행 방식, 발표 준비/방식에 대해서만 말하고자 한다. 진행 방식 스터디 동기부여가 중요하다. 그냥 보겠다 라기보다는 왜 해야하는지를 스터디 멤버들이 잘 이해하고 있어야 한다. 가장 좋은 동기부여는 업무와 관련된 것이다. 그리고 그 업무내용을 공유해 볼수 있어야 한다. 스터디 시간의 절반은 발표를, 나머지 절반은 자신들의 업무에 관해 토론을 해보는 것이다. 인원이 10명이 넘어가면 스터디 효과가 떨어진다. 이럴 때는 과감히 그룹을 두개 이상으로 나눠야 한다. 다만 이렇게 하면 그룹별로 사일로가 생기기 때문에 그룹을 계속 섞어줘야 한다. ..

쿠버네티스 모니터링에서 중요한 담당을 하고 있는 kube-state-metrics의 스케일아웃에 대해서 얘기해보자 한다. kube-state-metrics는 쿠버네티스 리소스들의 메타 및 상태정보를 메트릭으로 export해주는 컴포넌트다. 프로메테우스에서는 이 메트릭들을 수집하고, 더불어 cpu/memory 등 실제 다른 메트릭과 룰을 통해 새로운 메트릭을 생성한다. 예를 들어 파드 상태 및 재시작/재시작 이유 등을 알수 있으며, 노드 또는 파드의 자원정보를 IP가 아닌 이름으로 표시해줄수도 있다. kube-state-metrics는 보통 Deployment 1개로만 배포되기 때문에 노드 또는 파드가 많이 늘어났을때 성능을 뒷받침하기 위해 스케일업을 하게 된다. 필요한 경우 노드 크기에 따른 auto s..

예전에 전 회사에서 로깅시스템을 관리할 때 강진우님의 블로그를 많이 참고 했었는데, 최근 다시 로깅시스템을 자세히 봐야하는 상황이 됐고 그 사이에 책을 내셨다는걸 알았다. 책에 담긴 내용은 역시나 매우 유용한 정보였고(7버전 정도까지만 언급한다는 점이 살짝 아쉽지만, 21년도 판이니..), 책에 대해서 간단히 리뷰해보고자 한다. 말이 리뷰지, 모든 내용을 담아도 문제고, 나같은 초보자가 평가를 할수도 없기에 업무하면서 참고할만한 내용들을 간단히 정리하고자 한다. 노드 타입 - 마스터: 클러스터 상태 관리. 매우 중요 - 데이터: 데이터 저장 담당 - 인제스트(ingest): 데이터 인입 전담 - 코디네이트(coordinate): 모든 서버 기본값이며 검색 요청 담당 그 밖에도 세부적으로 나뉘기도 하는거..

그라파나를 통해서 사용자에게 메트릭을 제공하려고 할때 가끔가다가 사용자별 테넌트 분리를 해야하는 경우가 있다. 또는 동적으로 변하는 특정 타겟별로 각 메트릭을 얻어오는 사이드카를 만들려고 할때 고정된 쿼리를 사용할수 없는 경우도 있다. 이럴 때는 base prometheus 쿼리를 기반으로 동적으로 레이블을 넣어줄 수 있다. 여기서는 golang client를 이용하는 방법을 설명한다. package main import ( "fmt" "github.com/prometheus/prometheus/promql/parser" ) // addLabelToQuery는 주어진 PromQL 쿼리에 새로운 레이블을 추가합니다. func addLabelToQuery(query, labelName, labelValue ..

k8s가 계속 새로운 버전이 릴리즈 되면서 리소스 버전도 계속 업데이트가 된다. alpha -> beta -> stable 순으로 업데이트가 되며, alpha일때는 default false이고 beta부터 default true로 해당 리소스를 사용할수 있다. 이러한 버전이 변화되면서 필요한 버전 Convert에 관해 얘기해보고자 한다. 사실, 한우형님이 정말 친절하게 내부 구조에 대해서 친절히 설명한 자료가 있다. https://www.youtube.com/watch?v=sfv7YpxgK20 출처: [KCD KOREA 2021] 쿠버네티스 인터널스: 코드 레벨에서 보는 쿠버네티스 이야기 | 한우형 필자는 추가적으로 CRD의 버전 컨버팅 과정이 궁금하여 controller-runtime(kubebuild..

Prometheus Query(이하 PromQL)는 SQL과는 달라 처음 접하게 되면 이해하는데 조금 어려움을 겪을 수 있다. 하지만 제대로 이해하고 나면 정말 잘 만들어진 언어라는 것을 알 수 있다. 여기서는 PromQL의 기본 문법과 Metric Join(Vector matching)에 관해 설명하고자 한다. Data Model 먼저 Prometheus 에서 metric을 출력하는 형태를 살펴보면, 다음과 같다. http_requests_total{container="A"} 1037 {=, = ...} [] Metric 이름이 제일 먼저 나오고, metric의 특징을 표현하는 레이블(label)들이 있다. 그리고 가장 마지막으로는 metric 값(value)이 있다. 필요에 따라 timestamp도 ..

사실 요즘에 기출문제들이 대부분 공개되었고, 후기들도 많아서 굳이 도움이 될만한 정보는 따로 없을 듯 싶다. 그냥 필자가 CKA를 준비하면서 느낀 점. 다소 힘들었던 점을 위주로 정리한다. udemy 최근 udemy cka과정의 모의 테스트가 새롭게 바뀌었다. 아직 베타 단계라서 모든 테스트가 신규 환경은 아니지만, 신규환경은 훨씬 빨라지고, UI가 실제 시험과 비슷하다. 다만 실제 시험에서는 키워드 복사(예를 들면, 앱 이름 이라든지 autocompletion으로 되지 않는 내용상 키워드)가 된다. 그리고 udemy는 문제를 요약해주기도 하는데 실제 시험은 그런거 없다. udemy 테스트를 너무 많이 풀어도 너무 udemy 스타일에 익숙해 지기 때문에 좀 더 상황이 다른 실제환경에서는 애를 좀 먹을 수..