내 근황
이직을 했습니다...
즐겁게 다니던 회사를 떠나게 되어 참 아쉽지만, 개인적인 사정으로 인해 퇴직을하고 새로운 회사에서 DevOps로서 또 다시 근무하게 되었습니다.
그닥 궁금하실 내용은 아니라 패스하고 본론으로 가겠습니다...! ㅋㅋ
홈 서버 근황
솔직히 홈서버의 변화가 좀 많았습니다.
ELK, Vector, 신규 앱 등록까지 다양한 변화들이 있었죠.
그 중 가장 큰 변화는 오늘 진행한 BlackBox Exporter를 도입한 점 입니다.
그게 뭔데요?
엔드포인트 레벨에서의 Latency 체크 기능입니다.
https://github.com/prometheus/blackbox_exporter
GitHub - prometheus/blackbox_exporter: Blackbox prober exporter
Blackbox prober exporter. Contribute to prometheus/blackbox_exporter development by creating an account on GitHub.
github.com
Prometheus가 공식적으로 지원하는 익스텐션 기능이라고 생각하면 됩니다. 즉 그닥...메인이 되지는 못한 서자 포지션으로 보이더라고요..ㅋㅋ
근데 그와 동시에 Prometheus가 유명한 오픈소스인 만큼 나름 체급있는(?) 서브기능이라고 생각하면 나쁘지만은 않습니다.
가볍게 기능 디테일을 설명하면 해당 오픈소스는 대표적으로 아래 3개의 프로토콜 체킹을 지원합니다.
- HTTP/S
- DNS
- ICMP
프로토콜 3개가 각각의 역할이 너무 다르긴 합니다.
저는 대부분 서비스에서 REST API를 사용하기에 RSET API의 근간인 HTTP/S를 이용했습니다.
(물론 여기서 보여드린 예제는 FrontEnd긴 하지만요)
설정 법
현재 내 상황
저는 홈서버를 Proxmox를 통해 나누어 K8S를 구축해서 사용 중 입니다.
Application을 app-of-apps에 넣어두고 Application yaml파일, values파일, chart파일 3개를 통해서 오픈소스 Helm Chart를 사용하고 있습니다.
이렇게 구성한 이유는 제 DevOps 철학이랑 좀 연관되어 있기 때문에 모두에게 권장하는 설정은 아니긴 합니다.
3 Layer의 장점 및 관점적 이유
기본적으로 저는 Factor가 다른 Area에 대해서는 LifeCycle을 따로 따로 가져가는 것을 올바른 구성이라고 생각하곤 합니다.
인프라 레벨에서의 사이드 이펙트 방지가 가장 큰 이유가 될 수 있고 IaC의 가시성 확보도 이유에 포함되겠네요.
3Layer를 통해서 인프라를 구성하게 될 경우 다음과 같은 장점이 있겠네요.
- values의 life Cycle과 Application Manifest file의 life Cycle을 따로 가져갈 수 있습니다.
- Chart 주소 변경이 쉽습니다. bitnami같은 경우 인수되면서 기존 Helm Chart를 이젠 쓰기 어려운 문제가 생겼는데 이럴 경우 빠른 변경이 가능합니다.
Helm yaml 파일 설정
자! 본론으로 돌아가서 Application 파일을 작성해보면 다음과 같네요.
> Application 파일
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: prometheus-blackbox-exporter
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/<유저명 or 그룹명>/<레포명>'
targetRevision: HEAD
path: <차트경로>
helm:
valueFiles:
- <Values파일명>.yaml
destination:
server: '<K8S서버주소>'
namespace: <생성할_네임스페이스>
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
> Values 파일
prometheus-blackbox-exporter:
restartPolicy: Always
config:
modules:
http_2xx:
prober: http
timeout: 5s
http:
preferred_ip_protocol: "ip4"
serviceMonitor:
enabled: true
defaults:
labels:
release: <프로메테우스_레이블명>
interval: 30s
scrapeTimeout: 30s
module: http_2xx
targets:
- name: <타겟의_그룹이름>
url: <타겟_URL>
resources:
limits:
memory: 100Mi
requests:
cpu: 50m
memory: 50Mi
> Chart 파일
apiVersion: v2
name: blackbox-exporter-wrapper
description: A wrapper chart for Prometheus Blackbox Exporter
type: application
version: 1.0.0
appVersion: "v0.25.0"
dependencies:
- name: prometheus-blackbox-exporter
version: 9.1.0
repository: https://prometheus-community.github.io/helm-charts
데이터 확인 방법
1차 확인
다음과 같이 쿠버 클러스터로 API를 쏴서 포트포워딩을 해봅시다.
kubectl port-forward svc/prometheus-blackbox-exporter 9115:9115 -n <네임스페이스>접속해보면 다음과 같이 화면이 나오게 됩니다.
근데 위와 같이 보는건 1차적으로 잘 넘어왔나? 에 대한 여부이지 이 데이터가 시각화 툴에서 한번에 볼 수 있도록 잘 기록되는가? 와는 조금 다른 영역입니다.
시각화 해보기
그래서 저는 여기에 한술 더 떠서 Grafana를 통해 매트릭을 시각화 하였습니다.
귀찮게 다른 지표 이것저것 가져오는거에 부담은 아니지만 귀찮음을 느껴서 다음과 같이 기존 템플릿을 사용하는 쪽으로 진행했습니다.
1. 신규 대시보드를 생성
2. Template을 가져오기 위해 아래와 같은 "대시보드 가져오기"를 클릭 합니다.
3. 이제 '7587' 라고 입력 후 불러오기를 합니다.
4. 아래와 같이 변경되면 이름, 폴더, UID등을 수정하고 데이터 소스를 Prometheus로 지정합니다.
이후 Import를 하면 대시보드가 생깁니다. 들어가보면 다음과 같이 Health Check한 내용에 대해서 분석해서 말해줍니다.
간단 FAQ
이거로 뭘 할 수 있냐?
→ Alert Manager와 연동하여 Slack과 같은 협업 툴에 Latency가 높을때 알림을 쏴줄 수 있습니다.
그럼 이거로 어떤 인사이트를 얻을 수 있냐?
→ 기존에는 APM에 의존해서 애플리케이션 내부 레벨만 관측했다면 이제는 실 사용자 기준으로 확인이 가능합니다.
이게 그냥 curl cronjob 쏘는거랑 뭐가 다르냐?
→ 정확한 관점입니다. 다를게 없어요 ㅋㅋ 다만 수기로 curl 때린 값을 Metric화 해서 귀찮게 내부 모니터링 데이터 소스로 쏴줄 필요 없고, 레이턴시 등까지 모두 체킹하도록 도와주는 편의성 관점으로 보면 꽤 괜찮지 않나요?
마무리
사실 해당 글이 그렇게 까지 유익한 글은 아니지만 다들 큰 바운더리 내에서의 구성법만 있고 실질적인 프로덕트에서 사용할만한 Application, Chart 등의 설정을 적어둔 블로그를 못찾아서 직접하고 남기는 겁니다.....
별로 특별한 글은 아니니 궁금하신 점 있으면 댓글 마구마구 남겨주세요~!