그동안은 쿠버네티스 환경을 구성할 때 강사님께서 주시는 vagrantfile을 그저 받아서 vagrant up을 하여 설치환경을 구성하였는데, 이제는 단순한 실습 환경을 넘어서,인프라 관리자의 관점에서 쿠버네티스를 어떻게 설치해야 하는지를공식 문서를 기준으로 하나씩 확

컨테이너가 등장하기 전의 배포 방식은 비교적 단순한 구조였다.애플리케이션을 빌드해서 나온 실행 파일을 서버에 복사하고 실행하는 방식이다.개발자는 IntelliJ 같은 IDE를 사용해 코드를 작성한다.개발이 완료되면 Gradle 같은 빌드 도구를 통해 빌드를 수행한다.빌

리눅스는 크게 Debian 계열과 Red Hat 계열로 나눌 수 있다.이 구분은 무료/유료의 문제가 아니라, 패키지 관리 방식과 배포 정책의 계열 차이이다.Debian 계열은 apt, dpkg 기반의 패키지 관리 방식을 사용한다.Red Hat 계열은 rpm, dnf(y

이번 게시물에서는 Grafana 대시보드에서 Dashboard > New panel을 통해 Histogram 시각화를 직접 만들어보는 과정을 정리해본다.목표는 Kubernetes API Server 요청 처리 시간의 분포를 히스토그램으로 확인하는 것이다.우선, 데이터가

이번 게시물에서는 그라파나 대시보드에서 apiserver 요청에 대한 응답시간 (시간 흐름)을 heatmap을 만들어보려고 한다.우선 를 쿼리하여 데이터가 나오는지 확인해본다.이제 여기에 sum을하고 1m에 대해 less then equal로 group by하여 쿼리한

이번 포스팅에는 그라파나 대시보드에서 pie chart 및 state timeline, heatmap 등 대시보드를 다양하게 만들어보려고 한다.이렇게 대시보드에 처음 들어가면 아무것도 없다.여기서 패널을 추가하고, 워커노드별 cpu 사용율을 pie chart로 보기 위

11월에는 구름 판교 본사로 취업 콘서트를 다녀오게 되었습니다. 무려 구글과 애플 본사에서 직접 근무하시는 분들의 인터뷰를 들어볼 수 있는 흔치 않은 기회라 조금 먼 거리임에도 다녀오게 되었습니다. (애플 현직자분께서는 직접 현장에서 강의해주셨는데, 미국에서 오셨다

현재 이렇게 pods와 service는 모두 올라온 상태이다.따라서http://192.168.1.12 에 접속하게 되면 다음과 같이 확인할 수 있다.Grafana의 역할은 다음과 같다.혼자서는 아무것도 못 한다반드시 데이터 소스(Data Source) 가 필요

vagrant로 실습 환경을 구축하다가 vagrant error : E1229 00:04:06.250593 5712 memcache.go:265] couldn't get current server API group list: Get "http://localho

왜 이 글을 쓰게 되었는지 쿠버네티스 실습 중 Prometheus를 사용해 외부 서비스의 메트릭을 수집하는 구조를 이해하기 위해 이 실습을 진행했다. 특히, 쿠버네티스 클러스터 내부가 아닌 외부 VM에서 동작하는 Harbor의 메트릭을 Prometheus가 수집하는

모종의 사유로 인해 Helm으로 Prometheus를 다시 구축하게 되었다.그 후 Prometheus UI에 접속하기 위해 Node IP + Prometheus 서버 포트로 접속을 시도했는데, 접속이 전혀 되지 않았다.포트 포워딩까지 해보며 http://loc

공부하다보니 service monitor와 pod monitor에 대한 개념이 빈약하다고 느껴 정리를 해야겠다는 생각이 들었다. 각 개념을 설명하고 두 모니터의 차이를 비교해서 적을 것이다.PodMonitor는 “파드 자체를 직접 선택해서(PodSelector)” 메트

Prometheus로 메트릭을 수집하는 방법이 여러 가지가 있다 보니 프로메테우스 설정을 하면서 순간적으로 헷갈리는 부분이 많았다.특히, Exporter를 직접 구성해서 ServiceMonitor로 연결하는 방식과 Helm Chart로 자동 구성하는 방식의 차이가 명확

컴퓨터가 절전상태가 되거나 가상머신을 껐다 킬 때마다 노드의 상태가 매우 불안정해졌다.심지어 오늘은 Ready,SchedulingDisabled상태로 떠서대체 왜 그런지 이해하고 해결하고자 마음먹었다.(이전에 찍어놨던 스냅샷으로 복원하고 싶었지만 해결해보기로 했다.)문

Blackbox Exporter는 애플리케이션 내부 메트릭을 수집하는 방식이 아니라,외부에서 특정 엔드포인트에 실제 요청을 보내어 정상 동작 여부를 확인하는 모니터링 도구이다.즉, 시스템 내부 상태가 아니라 “외부에서 바라본 서비스의 응답 상태”를 측정한다.Blackb

MySQL + mysqld-exporter 구성하기 쿠버네티스 환경에서 MySQL을 모니터링하려면 Prometheus가 읽을 수 있는 형태의 메트릭을 노출해야 한다. MySQL 자체는 메트릭을 제공하지 않기 때문에 mysqld-exporter를 추가로 배포해야 한다

이번 포스팅에서는 Kubernetes 환경에서 Redis 메트릭을 Prometheus로 수집하는 방법을 정리한다.Prometheus는 기본적으로 애플리케이션 내부 상태는 알 수 없기 때문에,Redis 내부 정보를 가져오려면 Redis Exporter가 필요하다.이번 실

Recording Rule은 Prometheus에서 자주 사용하는 계산식(PromQL) 을미리 계산해 새로운 메트릭으로 저장해두는 기능이다.이렇게 해두면,무거운 쿼리 계산이 빨라지고UI에서도 즉시 조회가 가능하며자주 쓰는 식을 “메트릭처럼” 편하게 사용할 수 있다.예를

PromQL에서 메트릭을 선택하거나 매칭할 때 사용됨.PromQL은 함수를 많이 제공한다.자주 쓰는 함수:ex)

PromQL에서도 숫자끼리 더하고 빼고 비교 가능하다.메트릭을 합치거나 평균내는 기능이며,PromQL에서 제일 많이 쓰는 기능이다.ex: 파드 개수 세기→ 현재 시점의 값 한 개업로드중..→ 시간 구간을 포함한 여러 샘플